Peer to Peer communication among PLCs

J

Thread Starter

Jamil, Babar

Hi All...

I need some help/guideline in designing a system supporting peer to peer PLC communications. The system is running on a Fiber Optic, TCP/IP, Ethernet based Telecomm System. Can someone answer a few concerns in that regard?

1) Is communication among the PLCs totally independent or the packets go via a server containing the ARP tables?
2) Is there a way of keeping track of the communication that goes on among the PLCs i.e. keeping track of the stuff like # of times a certain PLC tried to communicate, # of successful tries, # of no responses etc...


If you have previous experience in this subject, please share pros and cons of peer to peer communication with me either via the board or by sending a personal message on my E-Mail address.


Regards,

Babar Jamil
 
R
Basic PLC communications often do not contain a formal transport layer equivalent to IP. Also, they are never standard, or perhaps we should say they are all standard, as every manufacturer defines his own 'standard' and then claims that they are using an open protocol, and it is usually very difficult/expensive to get your hands on such protocol definitions. They are
also an egoistic bunch, each thinks their own standard is the best thing since sliced bread, but in reality they are all trash. If you are used to the ease of use and quality of the RPC and CORBA networks in the telecomms industry, you are going to get a big shock when you come into automation!

To be fair, the grudge is really against the big names, the smaller companies and a few larger ones tend to be a lot more open and sensible.

Anyway, back to the point.Many of these protocols are put onto ethernet/TCP/IP simply by fitting the messages into TCP/IP messages, but the basic message structure is the same so you do not inheret TCP/IP from an endpoint point of view. Some are quite interesting, for example PROFIBUS (a synchronous tocken network where each master emits a fixed packet of name value pairs each time it gets the ticket) exists in an ethernet version. Sound like a contradiction in terms? Well, actually they call it industrial ethernet. I think that is a work around for saying you need a lot of extra rules to make it work properly.

If you have any comms programming experience, you are probably best off rolling your own protocoll to your specific requirements, it would be just as standard as anything else that is out there.

Contrarywise ( Language* English->Old[1800] ) you will need to supply a lot more information such as which PC's, what protocol/comms modules you had in mind, type of information to be passed etc etc before we can give suggestions.
 
G

Gary C. Workman General Motors

I'm curious what you mean by peer to peer communication. What is the application need driving the communication? What sort of timing delays or jitter can be tolerated?

I've been conducting and monitoring a variety of machine controller (PLC and PC-based controllers) peer to peer ethernet communication performance tests on a part time basis for the past couple of years. The simple, direct answer to both of your questions is that it depends upon the equipment supplier for the PLC you are using.

In the PLC tests I've run, the communication has been totally independent of any server and the vendor allowed you to have program access to communication monitoring counters.

I'm hoping to use an ethernet link for sending control interlock signals between machine controllers. I am concerned that the error recovery mechanisms of the TCP protocol are inappropriate (they introduce too great of
a timing delay) for our application. If the information you are exchanging can afford a time delay on the order of 100 msec in the extremely rare event of a corrupted frame, using the TCP protocol shouldn't be a problem.

The other performance concerns we've experienced involve how well the supplier has implemented the ethernet interface. For example, can the
interface support the number of simultaneous communications you want your PLC application to maintain?

I'm expecting that for cost reasons a single PLC ethernet interface will have to support PLC to peer PLC communication in addition to PLC to management information system traffic. There certainly is available bandwidth on our ethernet networks to support both forms of traffic. However, doing this intelligently will require the PLC ethernet interface to distinguish between
the different types of communication and to handle each appropriately.

Lastly, I'm curious, what is the requirement your application has that led you to choose fiber optic ethernet?

Gary Workman
GM CRW
 
Top