Joe E.

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

My first thought isn't very sophisticated but is simple to follow and *should* work. You would use a counter, which could just be a memory or DB word declared as an integer. I would probably just use a memory/DB register for this. 1) Reset the counter so its accumulator is 0. Use a RES instruction for an actual counter, or MOV if you're just using a memory/DB word. This step is critical to make sure your count is accurate and that you don't overflow the register! 2) If DI1 = 1, add 1 to the counter. If not, leave the counter alone. 3) If DI2 = 1, add 1 to the counter. If not, leave the counter alone. ... 11) If DI10 = 1, add 1 to the counter. If not, leave the counter alone. 12) Look at the counter accumulator. With 10 digital inputs, you should have a count from 0 - 10. Use the final count result to figure out the VSD speed setpoint and set the analog output accordingly.

I've never heard of the MMC instruction, but it does look tailor-made for what you're doing. It's definitely worth a test.

Please remember that my post was pretty much just brainstorming. I've never done anything like that before, so I may have steered you down a deep rabbit hole.

So, here's the situation. We (controls engineers) are trying very hard to get out of the password business. Folks share them with other folks who aren't supposed to have them and within a month or so they're useless, so we have to change them again. I recently added some user administration screens to a Siemens HMI (an old MP277) that allow an admin user to add and delete users and set and change their passwords. We can download an updated project to the HMI without affecting the passwords. I'd like to add the same functionality to some of our machines with PanelView Plus HMIs. We have some that are the original PV+, some PV+6 standards, some PV+6 compacts, and some PV+7 standards. Our firmware versions run all the way from 5.0 to 9.0. Our View Studio for ME is v8.20, on a 32-bit VM. I can add controls to allow a properly logged-in user to change passwords, BUT...when I later download an updated *.mer file, it overwrites the users and passwords with whatever is in the project, which almost completely defeats the purpose of this whole exercise. On a lot of the machines, the password is stored in the PLC, but there are places where "they" don't want the passwords visible to anyone, including the maintenance staff who have access to the PLC program. So.... Is there an easy way to do the password management in the PV+ HMI without the passwords being overwritten by downloading an updated *.mer file? If possible, we would like to avoid having to muck about in the Windows desktop of the HMI.

Hmmm...this is interesting... Just thinking out loud here, and I don't know how to implement it, but could your temperature loop CV be a proportion of hot to cold water (like 50/50 or 60/40, etc.)? IOW, its output would be 0-100% hot water. The cold water percentage would then be the remainder (100-0%). Then you can increase/decrease both to get the desired flow rate.  Example: if both hot and cold have the same flow rate at 100% open, and your final flow needs to be 50% with a 50/50 ratio, you would have both hot and cold open to 25%. If you needed a 60/40 ratio, your temperature CV would be 60% and the valves would be 30% and 20% open. Could you multiply the two? So that CVt x CVf = 0.50 x 0.60 = 0.30 signal to the hot water valve.  

The first thing I always try when having trouble with RS-232 communications is a null modem adapter. If that doesn't work, then try a different virtual COM port. I've had very good service from the Keyspan USA-19HS.  The only serial devices that haven't worked with that one haven't worked with any adapter and require a native COM port.

Would it be better for you admins if we stopped reporting spam posts?

Hmmm....The -ARM is an "Address Reserve Module". Any chance you have an "extra" -IB8 to swap in there? You could power off the Point IO chassis, swap in the -IB8, and power it back up. I've never worked with the GuardLogix line, so I don't know about downloading. I would expect you to be able to do so without issue, but I could be wrong.

Do you have an older copy of the project from before you deleted it? If so, restore it with a different name, then open it in a 2nd instance of View Studio. You can copy-paste between the projects. If it's the built-in default alarm display, you can also create a new project and copy-paste it from there.

I just learned something. I didn't know you could do that. Cool!

Have you measured the signal at the AI module? You can disconnect the AI module and just use your meter in its place to rule out the AI module. If the device is too far away and the resistance of the wire is too high, the device may not be able to drive the current. The input impedance of that module is 250 Ohms, so add that to the cable resistance to see if your field device can drive through that much resistance. The 1769-IF8 technical specifications are in this manual, starting at page 24: https://literature.rockwellautomation.com/idc/groups/literature/documents/td/1769-td006_-en-p.pdf Verify the wiring is correct and that the module is configured correctly in the Logix project. There may also be some useful information in the installation instructions: https://literature.rockwellautomation.com/idc/groups/literature/documents/in/1769-in067_-en-p.pdf

That's what their support folks came back with too. That's not ideal, but may be where we end up with if we have to implement it (we'll resist it for a while). Another option we thought of is "encrypting" the passwords in the PLC by using a know-how protected block or AOI that does "something weird" with the password string so the visible tags in the tag database are gibberish (maybe something as simple as adding an offset to the ASCII code for each character or something). That would make the HMI side easier, but the PLC side harder.

Even if you can get the ProSoft module to work in the SLC rack, it would probably be simpler and easier to make it a local Compact I/O module. Probably simpler enough to justify the cost of replacing it.

I would definitely get online and start a chat session for activations support. I "followed the procedure" and couldn't get it to work either until they did "something magical" on their end to make it work. Their versioning system is weird...but Siemens' system is also weird in a worse way. In their scheme, newer versions of the software can't be installed at the same time as older versions. If you open a project in a newer version, it converts it to the newer version and you can't connect online with the hardware without downloading from the project to the PLC, which opens a whole slew of cans of worms. Also, a license for an older version will not activate a newer version, so every time we got a machine with a newer version of software, we would have to buy a new set of licenses, or subscribe to their update service, which we finally had to do last year when they started releasing a new version of Portal every year.

Hmmm, that's interesting. I'm surprised the license can't activate the older versions, that's not been our experience. We have some Logix 5k licenses that date back to v10 and have no problem activating up to v30 (the newest we've installed). Some licenses of Studio 5000 we bought at v24 also activate back to v10. There's an option in the Activation Manager when you're hosting the license to your PC where you can select how to host the license. One of the methods supports back to the old versions, the other doesn't. It doesn't work smoothly, though. The last time I had to re-host a license, I ended up having to contact their chat support (free for activation support) to get the license to activate both the older versions and the newer ones. We have machines in service right now ranging from v11 to v30, so I know it can be done.

There's a link at the top of the post, next to the post date/time. It's grayed out until you hover on the post. I've reported some of them, but they keep posting them.

It is a MAJOR violation of this forum's rules to ask for or discuss software piracy or any kind of password or license breaking.

We have a system with a Kinetix 6500 drive controlled by a CompactLogix -L33ERM. The local CompactLogix is the system time master. It's networked to a few other Logix 5k machines, but we've never had issues with them fighting each other to be time master. On the Date/Time tab of the controller properties, there's a button labelled "Advanced..." that lets you set the priority of each machine. You might tinker with those settings to make sure that each PLC is its own time master. Hmmm.... I checked that line again and we actually have time synchronization turned off on the other Logix 5000 processors, so this reply may or may not be good information...