PLC to PLC Messaging Schemes

[BobLfoot 302]

Wound up working on an upgrade for our existing system of CLGX, PLC5 and SLC500 processors. Needed to send 16 Integers from CLGX to PLC5 and 5 Integers from PLC5 to CLGX. Solved it by Read and Write Messages in the CLGX code. Also added a heartbeat signal and timer to trip a fault in the CLGX. If this was PLC5 to PLC5 or PLC5 to SLC500 I'd use read messages only one in each processor. This has proven more efficient than using read/write all in 1 processor. Before you go there I know the CLGX can map tags to PLC/SLC file numbers. This did not appear to be an online edit available option on my Live CLGX system. How do others of you guru's handle processor to processor messaging.

[TimWilborne 108]

On your advice from the old Rockwell Forum I only do read messages. I recommended it HERE before quoting your comments there That is how I read and write between Controllogix and other Controllogix, Compactlogix, Micrologix 1200, 1100, and SLCs You might be right about not being able to creat PLC/SLC Messages. I know you can't delete them online but not sure. Another reason I like using reads on both sides is you don't need heartbeats. Just set the timeout realisticly and use the error codes of the message.

[Ken Moore 23]

I prefer reads because the next person working on the code, will know where the data is coming from.

[paulengr 44]

I agree with the performance differences with respect to reads vs. writes. You can implement either type of MSG on ControlLogix via mapping the registers as has been pointed out. In general, reads have higher performance than writes (it is not a 3-way message). However as with all things, there are exceptions and there are specific times when one is more appropriate than the other, other than performance. It is better to look at what the data is being used for than to simply transfer data blindly without consideration for what you are doing with it. Aside from performance, in general, I prefer reads to writes. The advantage of the reads is that data does not appear on the receiving PLC almost like mana from heaven. It is very clear to the casual reader where the data is coming from. BTW, I also always use MG blocks whenever possible and attach the actual transfer information (READ Nx:y on XXX PLC -> Nw:z) to the address comment so that it is clearly visible what is going on without inspecting the MSG block setup (this is especially important with multihop messages or other kinds of bridges which can take a while to decrypt). The following are real examples that I set up in my plant where I chose one vs. the other. I have a set of 5 PLC's where one has a scale and it transmits those weights back to the other 4 PLC's (4 production processes, one QC/inspection process after merging the process lines). In this particular case, the products take about one minute each to produce. We need to update the production machines as quickly as realistically possible (talking seconds here, not milliseconds) because this is a control loop for SPC reasons. If I did reads only, the QC/inspection PLC could store the weights in 2 locations: "PLC #", "last weight read". Each of the 4 PLC's could poll these two locations every second, for a total of 4 messages per second. Alternatively, I could trigger off getting a valid weight at the QC/inspection PLC and issue a single write to send a single weight to the corresponding production line as needed. In this case, the number of messages would drop down to 4 per MINUTE. In a second example, I have a set of 4 PLC's only one of which is Ethernetted. Previous to the Digi One IAP coming out, my only choices with regards to adding Ethernet capability to a non-Ethernet PLC were either to add a serial/Ethernet converter and only allow one PC or PLC to communicate at a time ($150 option), add an Ethernet sidecar (~$1500 option), upgrade to an ethernet processor (~$8K), use a Contrologix backplane as a DH+/Ethernet gateway (~$4500), or use the single Ethernet PLC as a DH+/Ethernet bridge at least for data transfer. I chose the last option. In this case I again have the scenario where the rate of change of the data is far lower than the rate that I would need to poll the data to get a decent response time. So again, a WRITE is called for. Each of the non-Ethernet processors WRITE's the information to the Ethernet processor. The HMI system in turn reads all 4 PLC's via the Ethernetted one. Aside from the difference in performance vs. bandwidth of polling vs. "on demand" data transfers, another reason for using a read vs. write has to do with communication failures. The PLC that initiates the communication (read or write) receives feedback about the communication link status based on the status bits (error or done). This can be very useful. For example, I have 2 PLC's where one operates a pair of valves which are fail safes for a cupola. There are two large dampers, a "spill" and a "blast" damper. The "spill" damper dumps superheated air out of the process. The "blast" damper directs the superheated air into the cupola producing up to 70 tons per hour of 2800 degree molten iron. If everything is working, the dampers are always operating as opposites (one or the other is open but not both). The actuators are also of the "fail safe" variety...in a power failure the spill damper opens and the blast damper closes to shut down the process. One of the two PLC's runs the environmental control system which processes the exhaust gases so that we don't pollute. The other one runs the rest of the process including the two dampers. The environmental control processor also monitors the emissions and has interlocks to shut down the system BEFORE we reach our permitted emission levels causing several thousand dollars in fines every time it happens. This means that the environmental control PLC has to be able to send a command to open the spill damper and close the blast damper. It is almost always a rare event for the environmental control system to initiate this action. So this suggests that a WRITE is the correct way to do it. BUT, remember...everything should be fail safe in this situation. If the environmental control system were to shut down without the rest of the system following suit, we could be closing the dampers on top and leaving the superheated blast air going into the bottom, causing carbon monoxide to come shooting out all the seals and into the building (a very bad thing). In this case, I wrote a READ on the spill/blast control PLC which polls the environmental control PLC one a second. If all reads fail for more than 30 seconds (communication failure), then it automatically opens the spill damper and closes the blast damper as a fail safe protection.