AB PLC/SLC messaging opinions

When communicating between different PLCs using the messaging instruction, is it better to have PLC 'A' read from PLC 'B', or have PLC 'B' write to PLC 'A'?

I am in the process of trying to eliminate all of our old DH+ comms (via global status words) and put all the messaging on ethernet. I was just wondering what you guys thought, and if anyone has experienced problems going one way or the other. Its probably just stylistic, but I would still like to hear you views on the subject.

Mark Snodgrass said:

When communicating between different PLCs using the messaging instruction, is it better to have PLC 'A' read from PLC 'B', or have PLC 'B' write to PLC 'A'?

I am in the process of trying to eliminate all of our old DH+ comms (via global status words) and put all the messaging on ethernet. I was just wondering what you guys thought, and if anyone has experienced problems going one way or the other. Its probably just stylistic, but I would still like to hear you views on the subject.

Click to expand...

Write messages are what I have seen most of the time. One reason would be that you could use a bit in the source PLC to turn a bit on and then off in the destination PLC. If the bit in the destination PLC stays in one state for too long, then you have a comms error

I personally use a combination of both. I usually use a read from the "main" PLC so that it can control when and what information it gets. This also allows the "main" PLC to react accordingly if there is a problem with communicating with the "client" PLC.

I will use a write message for sending alert information from the "client" PLC to the "main" PLC. This also allows the "client" to react accordingly if there is an error with communication.

Circumstances dictate which PLC will be the "main" and which one will be the "client". I have had no problems with either a read or a write message so I feel the setup is determined by the particular situation and personal preferences.