Posted 3 Jan 2017 Good Evening, Plant Configuration: Micrologix1100 (Filler) / CompactLogix L43 (Cooler) / CompactLogix L35E (Packaging) under the same network. Mission: Filler need to comunicate with the Filler and the Packaging using the MESSAGE protocol (DONE) Cooler and Packaging need to communicate eachother using the PRODUCER/CONSUMER Protocol (DONE) Question: I tryied to perform a physical connection failure for see how P/C and MESSAGE protocols set variables after the failure. And I noticed that they keep the last state. For the MESSAGE protocol i used a wiping timer that every 200ms set the INT sent by the Filler to 0 and it works. But for Cooler and Packaging I'm trying to do things in a better way because they exchange bigger User Data Types. Is it good to COP an empty DataType in the consumed tag every X ms, or there is a better way to wipe the tag in case of disconnection? Thanks in advice, Teo. Share this post Link to post Share on other sites
Posted 4 Jan 2017 The way we do it is if you do not have communications, (Monitor the heartbeat status bit) then write a 0 into whatever data you want. Or if a 1 is a safer state, then enter a 1 instead. You will need to have the status on a timer so you do not get nuisance errors. But we do not clear the data at an interval. Share this post Link to post Share on other sites
Posted 8 Jan 2017 TecTeo, I would not "wipe" the data received, but simply would not "use" it if the Produce/Consume connection wasn't valid. Whatever data you need to Produce and Consume, wrap it up into a new UDT that contains, as the first element, the CONNECTION_STATUS (it is a pre-defined data-type). That Connection_Status element contains two bits, which are maintained at system-level... The Producing Controller is in a "Run" mode. The "Connection" is healthy. If both bits are on in the consumer controller, then the data in that consumed tag is 100% valid, and can be used, otherwise discard whatever data is in the consumed tag, or simply ignore it as "invalid". Once you have done this once, and verified that it does actually work, you probably won't be messing around with handshakes or comms watchdogs again. 1 person likes this Share this post Link to post Share on other sites
Posted 9 Jan 2017 Thanks for the reply daba and armadillo As you said i implemented the connection status tag Consider this post SOLVED. cya Share this post Link to post Share on other sites