adccommunitymod (AutomationDirect) asked a question.

Opinions on Machine Communication

Created Date: December 08,2008

Created By: a agnone

**** This post has been imported from our legacy forum. Information in this post may be outdated and links contained in the post may no longer work.****

More and more we have machines on the plant floor talking to each other. I would like "rules " on how to lay this out. My question is does each machine to a TX, or each machine do a RX? Or each do a RX. Obviously each machine should not do a TX & RX. For example if C0 through C17 are used between two machines and both are TX & RX this could be a problem because both would try to update. It is really easy to have one of them do the TX & RX and the other do nothing. One machine would TX and RX the status of each bit. Is there a safe or reliable or proper way of doing this? I would like to hear from others.


  • adccommunitymod (AutomationDirect)

    Created Date: December 08,2008

    Created by: franji1

    If this is on a serial multi-drop network, then there can only be one master(what you call TX), the the rest must be slaves (what you call RX).

    If this is on an Ethernet network, which supports "peers ", then you technically could have everybody sharing with everybody. However, in this situation with N nodes, there would need to be N * (N - 1) requests for a "full " sharing of data across all nodes on the network. However, if you do master/slave topology (like serial), then you would have (N - 1) "reads " and (N - 1) writes.

    Peer: N * (N - 1)

    vs.

    Master/Slave: 2 * (N - 1)

    If N is "large ", say 4, that would be

    Peer: 4 * (4 - 1) = 12 comms

    vs.

    Master/Slave: 2 * (4 - 1) = 6 comms

    that must be done, and so the Master/Slave topology ends up being more efficient.

    If N is 10, the Master/Slave gets even better:

    Peer: 10 * (10 - 1) = 90 comms

    vs.

    Master/Slave: 2 * (10 - 1) = 18 comms

    Unless it is just 2 or 3 nodes, you are best off running a single "master " that collects all of the "common " data, then have the master "disperse " the data across all the nodes.

    One draw back to the Master/Slave topology is that there must be enough room in the Master to contain ALL the COMMON/SHARED data from ALL the slaves.

    If speed or memory is an issue, buy one extra 06 as "the master " that does no control logic, only the "master " comm logic, and use all its memory for all the slave data, and its logic is only doing RW/WX work (no other control logic). I guess it could be a 260 with no I/O - whatever works.

    Expand Post
  • adccommunitymod (AutomationDirect)

    Created Date: December 08,2008

    Created by: a agnone

    There will be ecom cards in each machine. The bits will be used for request or information. For example, a machine needs to be filled with liquid. It will set a bit to tell the filling machine hey pump to my tank. Or one machine may set a bit signaling I have stopped. This will be read or received by a connecting machine and it will in turn know to stop. So my question was more like do I make one machine the boss and do both the TX and RX ladder or each just do a RX ladder rung each machine to see what the status of a bit is? To clarify there is one machine filling serveral tanks. It just needs to know when to fill them. It can only do one at a time. So I was just thinking to do a RX ladder and just look for the status of bits.

    Expand Post
  • adccommunitymod (AutomationDirect)

    Created Date: December 08,2008

    Created by: franji1

    I take back my statement, then. These sound like "event based " signals, not "global data " being shared across a bunch of PLCs. I would then recommend the peer-to-peer, and just set bits (or command buffers)as needed.

    You could easily do WX's from PLC A to PLC B to set a command bit (or command Buffer in V memory) in PLC B. You could even do it with positive feedback, that is PLC B could then write a bit back in PLC A that it "got the event ", to "close the loop ". Sometimes you want to know in PLC A whether PLC B got the request or not (e.g. cut Ethernet cable, PLC B is not in run mode, etc.).

    Expand Post
  • adccommunitymod (AutomationDirect)

    Created Date: December 08,2008

    Created by: a agnone

    So basically each plc does a WX. PLC A sets C0 and sends a WX and PLC B will see it. Then if I want to confirm PLC got it, it in return does a WX and PLC A sees it. Remember to do peer to peer in each plc to cut down on traffic. Is it correct to say I can have more than one peer to peer entry in the ECOM card? There is one center machine that will be writing to 3 machines. So the ecom card will have 3 peer to peer entries. The other machines will only be writing to 1 plc, so they will have only one peer to peer entry. So far I only have had to enter one peer to peer entry and never dealt with more than one. I can not remember someone telling me it was better or more reliable to use WX or RX.

    Expand Post
  • adccommunitymod (AutomationDirect)

    Created Date: December 08,2008

    Created by: franji1

    RX would imply constant polling, WX would imply event driven. Either works, but WX is "cleaner " since you only get notifications when needed. If you are using a polling mechanism to one common, central, supervisory PLC, that is better than everybody polling everybody.

  • adccommunitymod (AutomationDirect)

    Created Date: December 09,2008

    Created by: a agnone

    Thanks franji1. I will go that route using WX on each plc.

  • adccommunitymod (AutomationDirect)

    Created Date: December 09,2008

    Created by: franji1

    I like that implementation. PLC A tells PLC B "do this ", then PLC B acknowledges PLC A "I got your message ". You could put a timer on the sending of the PLC A message and if you don't get a response from PLC B in 1 second (or 1 minute or whatever), then you have built-in "protocol error checking ".

    Similarly, PLC B can tell PLC C "do that ", then PLC C can acknowledge PLC B "I got your message ".

    This peer-to-peer, event driven messaging, could only be done with Ethernet. Serial cannot support multiple masters. Also, with peer-to-peer Ethernet, you can have everybody talking to everybody "at the same time ", i.e. that scenario above could be occuring "at the same time " (A talking to B and B talking to C). If, by chance, the requests did occur EXACTLY at the same time, the Ethernet chip in the ECOM module has built-in collision detection.

    What's critical with THIS peer-to-peer network, is that this is "event driven " and NOT "polling ". As I said earlier, if EVERYBODY was polling EVERYBODY as fast as possible, you could saturate your network (e.g. 90 "comms " with 10 nodes). But since this is "event driven ", the number of comms go WAY down. And, if you add in the response message and timeout timer, you could even know if the network or "the other " CPU was down! :D

    Expand Post
  • adccommunitymod (AutomationDirect)

    Created Date: December 09,2008

    Created by: a agnone

    Thanks, it sound and looks clean.

  • adccommunitymod (AutomationDirect)

    Created Date: December 08,2008

    Created by: a agnone

    More and more we have machines on the plant floor talking to each other. I would like "rules " on how to lay this out. My question is does each machine to a TX, or each machine do a RX? Or each do a RX. Obviously each machine should not do a TX & RX. For example if C0 through C17 are used between two machines and both are TX & RX this could be a problem because both would try to update. It is really easy to have one of them do the TX & RX and the other do nothing. One machine would TX and RX the status of each bit. Is there a safe or reliable or proper way of doing this? I would like to hear from others.

    Expand Post