PLC - PLC comms (ML 1400)

Hi,

I have two PLCs in a system where they need to talk to each other - sharing maybe 20 bits and 20 integers. The obvious way to do it would be with MSG for a range of integers and another MSG for a range of bits. However having used MSG in other scenarios I've found them to be somewhat unreliable and sometimes just stop working for no reason*. Is there a better way to share data between the two PLCs?

It's possible a third PLC will be added to future systems which is likely to complicate whatever method we end up with.

Many thanks,

*'bad parameter in message function' or something like that. Generally fixed by just deleting the rung, and copying it in from an older version of the code. Doesn't seem logical that this should fix it, but it does!

ControlLogix and CompactLogix controllers support a cyclic data exchange method that's similar to the way they handle I/O on Ethernet.

It's called "Produced/Consumed Tags", but the MicroLogix and SLC-500 and PLC-5 controllers don't support that feature.

MSG instructions can be made to work very reliably, but they're only as reliable as the network they run on and the code that underlies them.

I have seen 'corrupted' MSG instructions in applications where the same control block was re-used, over-lapped, or over-written in the PLC program. Re-entering the message in the editing software wrote usable settings back into the control block. I'm not saying that's necessarily what you experienced, but it's what I've seen and it matches the symptoms you describe.

MicroLogix 1400 controllers don't allow online editing of rungs that contain MSG instructions, so I can understand your hesitation given your experience. But if you're careful to program the instructions cleanly, there's no reason they can't run reliably.

Working for a company that makes industrial modems (with a primary market place being Allen Bradley applications) I’ve written literally hundreds (if not thousands) of PLC programs using message instructions and have found AB messaging to be very reliable. As Ken states it does however rely on a reliable medium and proper programming. If you’re running into “unreliable messaging” I’d say it has something to do with the medium between the PLC’s and/or the programming (no criticism meant to the programmer). I can also say that being self taught (with some help from Ken) sometimes it’s easy to miss something in the program that causes all kinds of weird and erratic behavior. However, once found and corrected, again, AB messaging can be very reliable.

Thanks for the tips. I'll have to review the code which triggers the MSGs. I have recently added timers so that the dozen or more MSGs don't all get triggered on the same program scan - they're spaced out by a few tenths of seconds now but it's not made a big difference to the random failures.

Mowgli86 said:

...I've found them to be somewhat unreliable and sometimes just stop working for no reason*...

...*'bad parameter in message function' or something like that...

Click to expand...

You haven't mentioned any details about the MSG instructions and their specific setup. I assume you are using the Ethernet Channel 1 on both MicroLogix 1400 controllers? Which type of "Communication Command" are you using, etc.? All Read or all Write from one controller to the other, or a mixture?

I would prefer to see the MSG parameters before assuming too much else.

But while I'm here...

What Firmware Revision Number (FRN) are the MicroLogix 1400 controllers at?

The latest FRN is 15.2, but you could be running a much older FRN on one or both of these controllers? There have been many small bug fixes over the years, including communication and messaging errors.

For instance, FRN 15.2 addresses an issue where a user receives MicroLogix 1400 error 21h:

"Bad MSG file parameter for building message"

This is in relation to using a "Communication Command" of type "CIP Generic" in the MSG setup. You would probably not be using this type of MSG command when messaging between two MicroLogix 1400 controllers, but either way it would not hurt to flash to that FRN if not already using it. You never know what else it might fix or improve.

Mowgli86 said:

...I'll have to review the code which triggers the MSGs. I have recently added timers so that the dozen or more MSGs don't all get triggered on the same program scan - they're spaced out by a few tenths of seconds now but it's not made a big difference to the random failures...

Click to expand...

With regard to multiple message execution, you should be cascading your MSG instructions so the first is done, or in error, before enabling the second MSG, and so on. This prevents the communication buffers from filling up quickly and overflowing into the messaging FIFO queue. If the execution of multiple message instructions is not handled correctly, some of the messages held in the FIFO queue may next to never be processed.

From the sounds of things, I reckon your multiple messages are either not being processed all the time, are faulting on error 21h, or similar, or a mixture of both.

I would use the latest FRN and cascade the message instructions. If that does not improve things, then yes, I would also look at the physical network for potential issues.

Again, this is all assuming that the MSG instructions are setup correctly?

Regards,
George

Thanks for the pointers chaps. So far my MSGs have been for comms with a Control Techniques Unidrive, for which we've used CIP Generic with Get/Set Attribute Single for each parameter we want to read/write. The firmware fault seems to be responsible for the problems we've had so far, and apart from that it seems to work just fine. I have also used MSG to send out email alerts and reports through the smtp service.

EDIT:

I have found that using 500CPU Read/Write seems to work for PLC - PLC comms.