Joe E.

MrPLC Member
  • Content count

  • Joined

  • Last visited

Community Reputation

131 Excellent


About Joe E.

  • Rank

Contact Methods

  • Website URL http://

Profile Information

  • Gender Male
  • Location Blacksburg, VA
  • Country United States

Recent Profile Visitors

6140 profile views
  1. Keyence IV500CA and ML1400

    We have a few systems where a MicroLogix 1400 controls a PowerFlex 525 drive or an AMCI stepper motor via explicit messaging (MSG instructions). It's cumbersome and painful, but it does work. You'll have to build the MSG instructions based on information that's (hopefully) provided by Keyence. If their examples use MSG instructions, you may be able to duplicate those.
  2. The fear of FOR TO loops

    The biggest objection I have to loops in the PLC is that they're harder to diagnose later. I would say if you're using loops, be meticulous and over-zealous in your documentation. Explain every detail of what you're doing and why so a technician on 3rd shift won't have any issues figuring it out 5 years from now. Without having to call an engineer. From a programming standpoint, just be careful when designing your loops to properly limit check them so you don't run past the end of your array. Most production managers don't have much of a sense of humor when it comes to faulting processors. Writing the loop is often simpler to avoid typos and copy-paste errors than having a rung for each element. If you have 40 items, it may not be a huge deal to have a rung for each, but when your array is a couple hundred or a thousand items, you almost have to do a loop just to stay sane. As an end user (not an OEM) who has to support the code in the long term, I will sacrifice memory/performance every time for ease of troubleshooting except in a few limited scenarios where the loop is doing something that's not critical to the machine's operation and that's unlikely to require diagnostics later. Like looping through alarm messages to display on an HMI. War story: we had a contractor come in and create a very complex piece of code for us that has multiple nested loops that are almost impossible to untangle. It works great...until something goes wonky and we have to download an old copy of the program into the PLC to get it working again. Power-cycling the PLC doesn't fix it. There's some tag value somewhere that makes it not work. After several years of it happening every few months, we're no closer to identifying the pattern. I spent several days one time just going through the code and making a flowchart but wasn't able to reproduce the bug. Weirdly enough, we have the identical code running in 3 lines in 3 different processors. One of them (originally a ControlLogix -L55M12 at v16 and now an -L81E at v30) has never gone wonky, another one (ControlLogix -L71, v24) goes wonky every other month or so, and the third (CompactLogix -L33ER, v24) has only gone wonky twice in 1.5 years or so. I've run comparison after comparison between the systems and haven't been able to figure out why that would be. In my opinion, loops definitely have their place, but PLEASE document them so I don't get a phone call at 3AM.
  3. Powerflex 70

    It looks like you want to operate at 2 preset frequencies, with reversing. Check out the installation instructions, page 32: That page explains what each of the digital inputs does by default and lists the parameters you would use to change their default behavior. The user manual also has a lot of information:  
  4. Advice on choosing a PLC for a project

    The ML1400 I have sitting on my desk has a 9-pin d-sub port and their version of the round mini-DIN connector along with the RJ45 for Ethernet. It should be easy to find/make a serial cable to connect to it. If your ML1000 talks to it, the ML1400 should as well.
  5. PLC5 to Controllogix Tricks?

    By doing the remote panels first, do you mean have the PLC-5 control the 1756 I/O? If so, I'm pretty sure that won't work. It *may* be possible for the DHRIO module to have routing tables set up inside it so it emulates an -ASB module, but I don't know if that's going to gain you much. If you're ok with keeping the remote racks as-is, you can use a 1756-DHRIO in the home chassis to control the remotes via RIO. That would get you a quick upgrade of the CPU and its home chassis but would leave the existing 1771 I/O in place. We did an upgrade not too long ago (a couple of years) that's similar to yours. We had a PLC-5 in its home chassis with 6 remote chassis on RIO. We replaced the 6 remote 1771 racks with 3 1756 racks and a FLEX I/O rack, all on Ethernet/IP. We saw the wiring kits you're talking about and decided not to try them. It added some time to our conversion, but I don't remember it being excessive. The wiring conversion kits will introduce extra wiring points that will be inaccessible for diagnostics (can't probe them with a meter since they're behind the 1756 chassis). If time is that much of a premium, that may not matter as much.
  6. Advice on choosing a PLC for a project

    I used some C-More HMIs at a previous job and we had great results from them. They communicated with SLC 5/04 PLCs via RS232. The ML1400 has an RS232 port as well as Ethernet, so you should be able to use the C-More with it if you go that route. My previous experience was so good with them that I would have tried the newer C-More panels here too but we already had such a diverse installed base that I didn't want to add another platform into the mix. We've almost eliminated the old QuickPanel (TCP, Proface) HMIs and we're down to 1 Uticor Tough Panel (or maybe it's a Power Panel...). The rest are Red Lion G3, Siemens MP/Comfort, and A-B PV/PV+. I remember the C-More being easier to program than any of the ones we have here now and they were at least as reliable.
  7. Advice on choosing a PLC for a project

    Our experience with CCW is close to yours. We had fewer errors on installation, but programming the 800 series PLCs was very cumbersome. I can't speak to the Click PLCs. My (limited) experience with Automation Direct PLCs is with the DirectLOGIC line and it was NOT positive. It seemed to do ok for digital I/O but the analog I/O modules were unstable and unreliable. If you're going to graduate to a paid version of RSlogix 500, I would go with a MicroLogix 1400 instead. It supports Ethernet programming and HMIs so you don't need any "special" cables or adapters. It supports MicroLogix expansion I/O and some of the base units come with built-in analog I/O. Edited to add: I also strongly support the use of virtual machines. I've had a number of software packages not play well (with others and/or on their own) and cause problems with my laptop that were difficult to resolve. For example, RSView Studio crashed in such a way that I could neither re-install nor un-install it. I was left with either doing a clean install of Windows (a royal pain on a company laptop) or using VMs. I chose VMs and never went back.  
  8. Tag Data Update

    That clarifies what you're up to. You're using recipes stored in the PLC. I generally prefer this method, at least in AB PLCs. The values in your storage array should be safe through power cycles of the PLC and HMI. You can also go online with the PLC and save the file. You'll be prompted to upload data values. If you do, your ACD file will contain all of your current recipes. Here's how I've done recipes in the past. You already have an array of your UDT, so now create a new tag that's a single instance of it. So you'll have an array called "storage" of type UDT[x], where "x" is the number of elements. Now create a new tag called "display" of type UDT. The HMI will read/write only to the "display" tag. You can add buttons to increment/decrement an "index" register or just type in the number you want to look at. Or add some buttons that jump to the highest, lowest, by 5 or 10, or whatever. The PanelView+ also has a piloted list control that can be useful, but I found it a little cumbersome to use. You would then use a COP instruction in the PLC to transfer information from storage to display so the HMI will display the selected recipe. If you want to be able to edit the values, use data entry controls on the HMI. Then add a button to the HMI called "save" that will trigger another COP instruction to copy the information from "display" to "storage[index]". I threw together a quick example in a CompactLogix. I excluded code for controlling the "index" tag, but that should be pretty straightforward. Here's my UDT: Here are the tag declarations: Some mock values: Here are the COP instructions to read/save the selected recipe: As with any use of indirect addressing, you will DEFINITELY want to limit-check the value of "index" to make sure it's valid. Since my UDT array is 50 elements long, index must be between 0 and 49, inclusive.  
  9. Tag Data Update

    Hmmmm... His mention of a UDT array made me think the recipe information is stored in the PLC. The PV+ has a built-in recipe system, but I've never used it so if he's using that instead, my comments aren't useful.
  10. Tag Data Update

    When I handle recipes in the PLC, I have a storage array of UDTs. The HMI "recipe" screen scrolls through the array by indexing an integer register that the PLC uses to copy the data from the storage array tag into a "view" tag. Sometimes it's element 0 of the storage array, other times it's just a separate "view" tag. The HMI can do whatever it wants to those tag values, since they're not the actual storage tags. The PLC would transfer the data from the "view" tag into the storage array when the "save" button is pushed (password protected, of course). In my experience with AB PLCs, tag values are non-volatile and are retained through power cycles. When online with the PLC, you can save the project and it will prompt you to upload & save the tag values, which will give you an offline backup. Downloading from the PC file to the PLC will overwrite the tag values in the PLC unless you use the "data preserved download tool", which I've never used so I can't vouch for its reliability or usability.
  11. Micrologix 1400 recording off time of a DI

    You could also use the RTO instruction. Run the timer while the input is off. When the input turns on, grab the timer accumulator to do your math and then RES the timer.  
  12. Compactlogix L32e IP Address

    We've had a lot of trouble with the Ethernet/IP driver working. Something has been done by our IT department with our network and security settings that causes the Ethernet/IP driver to never find devices, even when directly connected to the laptop. We always use the Ethernet Devices driver where we manually enter the IP addresses of the devices.  
  13. Compactlogix L32e IP Address

    Ah, ok. If it's already set to static, I don't think you can change it using BOOTP. And DHCP is already disabled, so I think that request should fail. In  your screenshot, it looks like you can see the current IP address, which greatly simplifies things. You can change the IP address from RSLinx Classic or from within Studio 5000. Within RSLinx, right-click on the PLC and select "Module Configuration". On the "Port Configuration" tab, you can set/change the IP address and set it to static or dynamic. Within Studio 5000 (online with the PLC), at the top of the project tree, right-click on the CPU and select "Properties". Go to the "Internet Protocol" tab and set/change the IP address.
  14. Compactlogix L32e IP Address

    I've found it's not at all unusual for the BOOTP utility to set the IP address but fail to disable DHCP. What I normally do in that case is set the IP address, then find the device in RSLinx. Right-click on it and select "Module Configuration". On the"Port Configuration" tab, select "Manually configure IP Settings".
  15. Communicating between plc's with different IP's

    If this were our system, we would have to add a second network module since our IT folks lock down all devices more sophisticated than an unmanaged switch. We have a lot of 1756-ENBTs in service, but I know they're getting closer to end of life so we would probably use an -EN2T. That can support either MSG or produce-consume. We typically use MSG instructions since our PLCs span a wide range of versions and types (including MicroLogix, SLC 5/04, PLC-5s, and various Logix 5000s). The one time I tried to set up produce-consume, I couldn't because the two PLCs were such different firmware versions. One was a 1756-L55 that can only go up to v16 while the other was a 1769-L30ER that could only go back to v18 (I think...). I could add the -L55 to the -L30ER project, but not the other way around. I was going to try to add the -L30 as an older model PLC that was available just to see if it would work, but that project suddenly dropped off of the radar screen and became a lot less important. When I went back to it, I just used MSG instructions.