Joe E.

It looks like you want to operate at 2 preset frequencies, with reversing. Check out the installation instructions, page 32: https://literature.rockwellautomation.com/idc/groups/literature/documents/in/20a-in009_-en-p.pdf 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: https://literature.rockwellautomation.com/idc/groups/literature/documents/um/20a-um001_-en-p.pdf  

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.

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.

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.

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.  

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.  

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.

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.

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.  

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.  

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.

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".

As a starting point, look at parameters A051-054. They select what the digital inputs do. It looks like Digital Input 3 defaults to "Local", which sets the local keypad (or your HIM) as the start command source. Your selector switch would then turn on digital input 3. If the switch is not closed (DI3 is off), then other starting means would take precedence. I've never done this, so you'll want to test whatever you do to make sure it works. There's also a flow chart in the user manual that may help you out.

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.

What HMI is it? There are some that can handle a few I/O points, but most of them don't have physical I/O and need to be connected to a PLC to interact with the real world. If your PLC controls a  relay, and your HMI controls another relay, your selector switch can control which one controls the drive:  

Is the HMI connected to the PLC? If so, have the PLC handle it all. Either in "manual" based on inputs from the HMI or in "auto" based on whatever you're thinking of having the PLC do it. The switch can be either a software switch or selector on the HMI or a physical switch wired to a PLC input.  

I've never used it, but there is a "data preserved download tool" (or something like that). I think you have to select it to install when you install the software, but you may also be able to download/install it separately.  

So... Ethernet/IP (industrial protocol)  is an implementation of CIP over Ethernet. It's managed by ODVA. I opened up Crimson 3.0 (Red Lion) and picked an Omron driver. It has 2 available: G9SP-Series via FINS and Master via FINS. I don't know which (if either) will work with the NJ/NX. I did find a thread on another board from 2015 asking if anyone had done it. They said that Red Lion support hadn't heard of anyone doing it. My Google search also turned up a manual for the NJ/NX: https://assets.omron.eu/downloads/manual/en/w501_nx_nj-series_cpu_unit_software_users_manual_en.pdf The diagram on page 10-9 seems to imply that it does talk CIP. I sometimes get suspicious when I see "Ethernet/IP" listed and wonder if they really mean "Industrial Protocol" or "Internet Protocol", but I would expect Omron's use of the term to be proper, especially since they mention CIP. I don't have any experience with any Omron hardware, so I can't tell you how to make it work (or if it's possible).

Our PLC-5s are on the upgrade list, but at the bottom behind the PLC-2s and SLC100/150s.

If you're comfortable with RSLogix 500, transitioning to RSLogix 5 will not be a big deal at all. They look and function almost identically. The biggest complication I've found is with the I/O addressing since the rack can be configured for multiple addressing schemes and the processor doesn't care what's in each slot. The I/O table is fully populated with registers for all of the I/O that the CPU can handle, regardless of what physically exists. Be prepared for major sticker shock, however, if you need to buy a license for RSLogix 5. In typical AB fashion, they're pricing it to force people to stop using it. List price is about $11,000 per seat.  

I've had to use a couple of them years ago. They needed a special laptop dual-booting to WIndows NT to work. And getting online only worked very intermittently. I was glad to upgrade them to MIcroLogix PLCs.

There's another thread on here talking about the Overload contacts on motor starters interrupting the neutral side of the coil. That's one of the only instances I've ever seen using contacts to interrupt the neutral side. We have one machine built by an integrator that did that with 24VDC valve coils and PLC contact outputs. It's a royal pain to troubleshoot if you forget (or don't know) that they're switching the 0V side. It's the only thing I know of in our facility that does it that way. Did your customer explain why they would prefer you do that?

Another platform that's popular on here is the Red Lion G3 series of HMIs. I think that at least some of their HMIs are actually manufactured by Maple Systems (may be only their Kadet line...). They have drivers for a LOT of protocols from a LOT of manufacturers and have solid tech support with free programming software. What PLCs do you need to communicate with?

I've done a few migrations from PLC-5 to Logix 5000.  A couple of them were pretty small machines with only about 50-70 rungs of pretty simple code so transcription was simple and easy. One was a much bigger system, though, with multiple chassis on an RIO network. It was also a very old system that had evolved a lot, so there was a lot of defunct code that had to be removed and several of the chassis were being removed with the remaining ones being replaced. For all of my migrations, I've simply transcribed the code manually from RSLogix 5 to RSLogix (or, later, Studio) 5000. The smaller systems were a couple hours of work. The larger one was a few days to a week but none of them were particularly difficult once I got a rhythm going. I've heard horror stories of the results of the migration tool, so I avoided using it on our migrations. From what I've heard, I would probably have spent almost as much time correcting and debugging the migrated code as I spent transcribing it. It looks like you're using the older DOS software for the PLC-5s, which I've never used. I would be strongly tempted to just transcribe the code manually, either from a current printout or by having the software or PCs open side-by-side. Like Michael said, though, transcribing/migrating/etc. the code will be of no use to you unless you also replace the PLC-5 hardware. If you do that, you may also need to upgrade your copy of 5000. What versions do you have installed? You can see that by looking at the splash screen as RSLogix 5000 opens or by going to Help -> About -> More Info. If it's an older version, you may have a hard time finding new hardware to work with it.

In general, I also try to put the high-heat stuff at the top of the cabinet and the PLC at the bottom. Our cable entries are also usually at the bottom. Since our disconnect switch is on the top right corner, we try to route the 480V wiring up along the right side of the enclosure and keep the low voltage stuff to the left. As a side note, and another reason to keep the PLC nearer the bottom, we had one application where we replaced a PLC-5 chassis with a CompactLogix. The PLC-5 was at the top of the cabinet, right next to the disconnect switch, so that's where the CompactLogix had to go too. After the upgrade was mostly done, we got permission and funds to also replace the old mechanical cam switch with a resolver & in-chassis module. The resolver module ended up right next to the disconnect switch because it was on the end of the chassis and we started having intermittent noise issues. We ended up having to move the resolver module to the left end of the chassis, which messed up all of the I/O wire numbers and addressing. Since it was a quick-turnaround upgrade, we didn't have time to re-label all of the wires, so we just had to put notes on each page of the drawings highlighting the discrepancy. I really dislike leaving stuff like that, but we didn't have much choice in that instance. The AC in/output modules are not nearly as sensitive to the noise, so they work fine being right next to the disconnect. If we ever get a chance to re-do that cabinet, the PLC will move to the bottom, but since that one has a CompactLogix in it, it's not even on the upgrade list right now. It may stay that way until the machine is decommissioned next millennium (it's a Minster press so it will probably keep running until the heat death of the universe...).