It is more efficient to READ than to WRITE. When a write is executed, the receiving PLC must acknowledge receipt of the MSG. When a read is executed, no other exchange of data (between the two PLC's) is required.
The problem arises when you want to update the distant PLC when changes take place in the source PLC. In order to do that in a timely manner with reads, you must read almost continuously. With a write, you can condition the write to execute only when the condition of interest actually changes. Some refer to this write technique as "report by exception". I do it when there is a noteworthy change at one of my field sites; report the change to the master.
In an ethernet environment where bandwidth is not an issue, it makes little difference whether you read or write. But in a radio environment, it can make a significant difference, especially with thirty or forty stations "on the air".
Best practice is to read whenever a read is adequate (if you intend to exchange info between PLC's every five seconds, for example,) you benefit from using the read type message. If you used a write message in that scenario, you increase the amount of data on the network (because the receiving PLC must acknowledge every message) with no gain.
Message instructions are also "non-deterministic" which, in general, means you have no guarantee that the data will get to it's destination immediately. The MSG can error, and require re-transmission. So, one must be aware of that and condition the MSG rung to retry in event of failure. Not a good situation if five thousand cans of beans will be trashed because a message instruction failed. ;-)
Bill
Thank you guys for the fast response. I now have a better understanding of MSG read and Write.
