Messaging with PLC to CLX conversion

[RonJohn]

I have a PLC5/40 with 1785-ENET sidecar that's soon to be converted to a 1756-L71 processor. The 5/40 has block transfers to a few analog cards in a 1771 rack plus 20-COMM-R cards in two PowerFlex drives.

On top of that, the PLC has MSG reads/writes to five other PLC 5s over DH+. There are multiple read/write MSG instructions to some of the PLCs due to lack of contiguous data table registers, frequency of update required, etc.

In the conversion process, everything on RIO is staying put due to limited down time. We have a 1756-DHRIO for comms to the 1771 I/O & 20-COMM-R cards. All of the other PLC5s have Ethernet side cars, so DH+ won't be used for messaging or anything else with the CLX.

Now, I've read the programming manual on Logix5000 messaging, along with a few technotes, etc. and come up with a gameplan. None of my other PLC/CLX conversions involved all of these messages, so I'm a bit skittish. Here's the plan:

1. Increase Unconnected Buffers from 10 to 30.
2. Increase Overhead Time Slice from 10 to 20-25%.
3. Cache connections on the Block Transfers since they use a connection. Use logic to make sure BT read/write messages don't occur simultaneously.
4. My understanding is PLC5 MSG reads/writes don't use a connection, so they cannot be cached. Not sure if using a message manager is the way to go since I've got multiple messages to each PLC, or if I should attempt to combine messages into a single read/write to each PLC.
5. While MSG writes are typically discourged, I plan on doing so to avoid PLC tag mapping within the CLX program.

I'd appreciate some feedback from anybody who's been down this road before. My main concern is how to set up the CLX to PLC messages. Thanks in advance.

 

[Cody]

If you haven't purchased the ControlLogix yet, consider your migration path forward with SoftPLC instead. Less downtime, less cost as all your logic will import without needing any re-engineering. See http://softplc.com/products/migrations/

 

[RonJohn]

Thanks Cody. I'm sure there are some places where SoftPLC works well, but our plant is set up around Rockwell and I don't foresee that changing anytime soon.

So, regarding the CLX transition, is the MSG setup a big deal or am I making a big deal out of nothing?

 

[scarince]

I don't have exactly the answer you're looking for, but I just did something similar......except I'm using my CLX to talk to a bunch of SLC's, and I'm using the DH+, but it wasn't a big deal at all. I've attached my routine that does the comms (it has some debugging artifacts still in it).

I was lucky in that I could install the CLX first, then get everything talking, then construct all the mssgs and confirm it worked, then I pulled the plug on the old system and I was up and running. Is it possible for you to run the old and new plc's together so you can sort all that out as you run?

 

[RonJohn]

Thanks scarince. For some reason, I'm not able to import that routine. Not sure what I'm doing wrong. Would it be easy enough to post as a PDF?

I do have the luxury of running the CLX while the PLC5 program is still online. I'll be sure to give that a shot (except the MSG writes, of course).

 

[scarince]

I've copied it to a pdf and I also included some screen shots of the msg configuration.

I hope this is helpful.

You know, if you do run the clx and the plc5, just do your mssg writes to an unused register......you can prove out everything and you'll be all set. Also, since I think you were saying that you're going to migrate from the DH+ over to the ethernet, you be able to verify all of that stuff in advance while you run your current network. This should work out well for you.

Good luck.

 

[RonJohn]

Thanks for the PDF, scarince. You got me thinking about how I can test my messaging scheme before fully committing to the CLX.

I'm going to have to experiment to see what's the best method of getting my data to/from the other PLCs. My guess is the solution will involve some sort of message manager.

 

[JRoss]

I haven't done anything with quite the complexity, but I have done PLC5 to CompactLogix messaging over Ethernet. It's been a few years, so I can't remember all the ins and outs but I'm looking at the program, and I did all the messaging logic in the CompactLogix. I used the MSG instruction with a PLC5 Typed Read/Write message types. I was passing integers, so I created INT (not DINT) arrays in the CompactLogix as destination and source for the MSG instructions. I've attached screen shots of the setting screens for the Read instruction. The Write instruction is set up pretty much identically.

There's also a mapping function in RS Logix 5000 under the Logic menu that lets you map tag arrays to file numbers to mimic the data memory of a PLC5 or SLC. My program also has that set up to map my INT arrays to file numbers, but I don't remember if that was necessary or just a holdover from testing various methods. I want to say that you only need to do that if you are initiating the messaging from the PLC5, but I'm not sure.

Best way is to bench test... Manuals and even tech support only get you so far.

 

[RonJohn]

Best way is to bench test... Manuals and even tech support only get you so far.

Amen to that!!! I have performed some bench testing and this has taught me a few things that I thought I'd share with all of you.

I set up my message manager per Rockwell's recommendation of using the DN or ER bit of the first MSG to trigger the second MSG, etc. This worked well UNTIL there was a communication disruption with one of the PLCs. At that point, it took almost 20 seconds for the ER bit to appear, meaning all messages downstream of the one that failed got held up as well.

This issue is a concern in my present situation, so instead of using the DN/ER bits, I created a multiplexer to trigger each message on a timed basis provided the message is not currently enabled (XIO MSG.EN). This setup should allow the messages to keep rolling along in case comms to one of the PLCs goes down.

I realize that this may open up the door to filling the message buffer but I have to choose my battles in this case. Data between PLCs is updated on 2-60 second cycles, depending on priority, so I can space them out enough to hopefully avoid filling the buffer.

I'm also getting a 1756-RIO module in here to test whether this may speed up the block transfers to my many analog I/O modules compared to the DHRIO.