SLC 5/05 Ethernet link to control computer

[star_watcher 0]

A simple problem but is there a solution? I have a VME based control computer running linux that I need to connect to a SLC 5/05 PLC via an ethernet link. The problem is that I am told that the data protocol used by the SLC5/05 (MSG command) over TCP/IP is proprietory. It is not available to third parties. The Ethernet interface on the SLC5/05 is not intended to be used by third party CPUs (such as the VME) to communicate with Rockwell Automation SLCs via TCP/IP. Does anyone have details of the MSG protocol format to allow TCP/IP connections from third party computers over Ethernet?

[paulengr 44]

The protocol is proprietary but AB has MOSTLY not made it a deep, dark secret. They have closely guarded the physical media details of the DH+ system but they have been more or less "open" with the bits and bytes of their protocols. The documentation is erroneous in some places and it is about as lucid as an old IBM mainframe manual (in other words, almost totally unreadable), but if you spend the time, you can get it done. Look in the downloads section of this site for the "DF1" manual. AB's "Ethernet" protocol is a modified version of DF-1 for SLC 5/05. It will also support CIP over Ethernet (aka Ethernet/IP), but this is a much more complicated protocol to implement. In addition it appears that some of the so-called "Ethernet/IP" commands are actually DF-1 commands encapsulated in CIP packets...AB is claiming that Ethernet/IP is supposed to be nonproprietary when clearly it is not when they are pulling undocumented shenanigans. AB documents both of them in their tech notes (including how to encapsulate DF1 inside CIP) if you don't mind searching for a while. See also this site: http://iatips.com/ Lynn is the author of the code inside the Digi One IAP which is a protocol bridge which works for most PLC's. It's a hardware solution to the problem but works extremely well. See also this site: http://www.rongage.org/ ...contains complete, working C++ code implementing the older AB-Ethernet protocol as well as others. All you have to do to implement what you are trying to do is to implement some of the DF1 protocol commands over PCCC on top of a TCP/IP protocol stack. You first have to open the connection, send a "hello" type packet, and then start sending/receiving at will. The protocol even tags the packets with sequence numbers so you can use a threaded implementation if you want to (you can send out another request before receiving a response to the first request). I have implemented this stuff myself once in Python a few years ago by simply following Ron and Lynn's hints and with the AB documentation in hand. You won't see a shred of mention of the word "MSG" in any of this. With the possible exception of CIP "unsolicited messages", all AB protocols are 2-way request/response, similar to most remote procedure calls in other languages. The "MSG" command is a generic command in AB PLC's that implements several different procedure calls depending on the parameters you set. The MSG command more or less hides all the ugly details from the ladder logic programmer. For whatever reason every time AB came out with a different PLC line, they added 2 or more additional procedure call formats to the list. Each PLC line also implements one or more of them (backward as well as forward compatibility), all the way back to the PLC-2. And if you use an unimplemented one, the PLC generally will fault and frequently will dump the ladder (go blank). So watch out!

[Stephane Leicht 0]

Hi See this site: http://www.tuxplc.net

[star_watcher 0]

A quick update on progress. We have made our first sucessful read from the SLC5/05 across ethernet using the TuxEIP library from http://tuxplc.net. Thanks for the assistance.

[wgugl 0]

Hi I am using the tuxplc - Library as well, and reading/writing Data from the PLC actively ist working well. I need to update a system, which used the Rockwell - Interchange - Library. On this system, the SLC 5/05 did send update - messages on itself, which were received as unsolicited messages (so the PC - system did never openly request the data). Is it possible with the tuxplc - Library or on the Ehternet/IP Protocoll, do register somehow to receive unsolicited messages instead of polling all the time ? thanks in advance.

[paulengr 44]

On the old protocol (SLC, PLC-5), "unsolicited" messages aren't really "unsolicited". They work identical to the "polling" messages. The protocol is 100% bidirectional, and in this case, you are simply using it in the reverse direction. The read command (what is being used to poll) uses 2 packets. The corresponding write command (which is being used in "unsolicited mode") requires 3 packets. So if it wasn't for whatever event-oriented work you are doing in the SLC, there is actually a performance disadvantage. The Ethernet/IP protocol is designed with some additional features. "Unconnected" messaging works almost identical. There is however a "connected" system, aka, Ethernet/IP for IO, which actually first sets up all the parameters for regular data updates, and then the transmitter continuously streams packets at the required update rate (or from change-of-state and a very minimal update rate) with NO acknowledgements...making it effectively a "1 packet" solution. The Ethernet/IP protocol also supports "PCCC over Ethernet/IP" so you can encapsulate the old AB Ethernet protocol messages inside Ethernet/IP ones. However, sadly, the tuxplc library wasn't explicitly designed for this usage. I haven't ever looked closely at their source code so I don't know how hard it would be to implement this but since the same functions (processing requests and replies) are necessary to implement unsolicited messaging, I'm reasonably sure that if you understand the protocol, you could modify it to do this. If you want an off-the-shelf solution, I suggest buying an OPC driver. If you look closely, many of them do support unsolicited messaging. Remember though that implementing this is a real challenge since the code base has to take on some characteristics of a "server". An interesting one that is available out there is the OPC-UA driver from Inductive Automation which is programmed in Java (and thus can run on any platform that you can get Java to run on) and is completely free. Don't know if it supports unsolicited messages, only that the price is very nice and it appears to be a really good OPC server.