SLC 5/05 Ethernet

[Guest cj]

Someone told me that the SLC 5/05 Ethernet is DF1 over ethernet similar to the concept of MODBUS TCP(MODBUS RTU over ethernet). Is this true? Or is it more of a derivative of Ethernet/IP?

[Guest Bowen]

The SLC5/05 is a true Ethernet connection. The 1761-NET-ENI which is a DF1 to Ethernet convertor is similar to the Modbus TCP. Basically it encapsulates the DF1 into TCP packets. It's less than a 19.2K to the device and then 10MB out, so in effect it is not a true 10Mb throughput. Whereas the 5/05 is a true 10MB connection. As for the EtherNet IP, the 5/05 doesn't support I/O cotrol over EtherNet so it's not true EtherNet/IP (although it will still communicate with EtherNet/IP devices)

[Guest cj]

So you should be able to communicate to the SLC 5/05 through ethernet if you were to get the Ethernet/IP protocol from the ODVA, correct? What exactly do you mean that you can't perform I/O control with the SLC 5/05? I understand that I/O control is a function of the CIP protocol but does that mean you can't turn on internal bits as well (example: B3:0, etc...)?

[Guest cj]

.....Or is this similar to the DeviceNet methods of I/O polling versus explicit messaging? Meaning that the SLC 5/05 can do the explicit messaging portion of Ethernet/IP but not the I/O polling?

[Guest Bowen]

Basically EtherNet/IP is broken down to the three c's - Configure, Collect, Control You can do two of the three with the 5/05 (Configure, Collect) You can't do the control (at least as of yet) with the 5/05. It's based on the previous EtherNet system (PCCC I believe was it's acronym). There is no protocol available from ODVA for the EtherNet/IP for SLC5/05. As for the DeviceNet it's not the same, as it's mapped into a scanner's memory. You can send messages to other AB Ethernet devices, but cannot have for example a remote rack of I/O with an EtherNet connection.

[Guest PhilipW]

Further to Bowen's comments: (which being concise and to the point may be of more help than the following ramble:-) All AB PLC's from the PLC2, 3, 5 , SLC and MicroLogix 1000, 1200 and 1500 use a messaging scheme based on PCCC (Programable Controller Command and Control) at the message level. This is the set of commands that are common to all the legacy networks (DF1, DH+, DH-485) AND the implementation of Ethernet in the SLC5/05 and the PLC5/E's. The main limitations of this set is that every message was explicitly defined (ie the header has to include all the source and destination info) , point to point only ( or peer to peer as per the imposed network protocol) and was non-deterministic. Due to these limitations I/O had to be done on a separate network Remote I/O, which although electricaly identical to DH+, used an implicitly defined messages, a Master/Slave connection scheme and was deterministic. All ControlLogix comms ( backplane or cable) is done using CIP (Control and Information Protocol) at the message level. This protocol uses a Producer/Consumer connection scheme and allows for routable massages, ie data can be "hopped" though multiple devices in a system. The other key feature is that both unscheduled (ie RSLinx and MSG commands) and scheduled (ie I/O connections) can co-exist on the same "wire " or backplane. All up CIP is the way of the future for automation comms. CIP is however only one layer in the comms picture, above it will be a network layer such as the serial ports, CLX backplane, DeviceNet, ControlNet, or Ethernet. Each of these imposes its own character on the comms picure (ie bandwidth, distance, number of nodes) but can all in essence perform the same tasks with a common set of instructions that the CIP set carries. Bundled together with object definitions (ie DeviceNet EDS files) the whole concept is labelled by Rockwell as "NetLinx". When CIP is run over TCP/IP it is called by Rockwell "Ethernet/IP". When PCCC is run over TCP/IP is has no specific name, but is analogous to the MODBUS TCP protocol. ( AB's DF1 protocol is of a similar nature to Modbus RTU, but AB made the mistake of keeping it proprietary far too long and allowed Modbus to become the de-facto RTU standard by default. A lesson they have subsequently learned, witness their strong support of ODVA and "Open Protocols.") Coming back to the original question...the 1761-NET-ENI. The original Series A version did exactly as Bowen describes.... it "encapsulates" a serial message, usually from a Ch0 DF1 PCCC port and bundles it up into TCP/IP packets to be "unbundled" by another NET-ENI at the other end. MOST important..the Series A module could ONLY handle PCCC messages. This meant that you could only use DF1 protocol to drive it. It was also as slow as several wet weeks. The Series A could only do what a PCCC port could do, and in particular could not talk directly to a CLX Ethernet port enabled with CIP. The Series B ( I have yet to use one) now handles CIP directly and removes a big limitation... and is I also hope a lot faster. In summary the key thing to try and understand is the difference between the legacy PCCC protocol and the newer CIP protocol. All up this is a non-trivial discussion and there is plenty of room for confusion, and I don't suggest that the above is even a half-decent primer on the topic. Plus I am still finding out new things myself.

[Guest Bowen]

You obviously know your stuff Phillip, and I again apolgize for my outburst. If I could offer the following though. CIP is the application layer for the 3 open networks of AB. Take EtherNet and it's 7 layers. The bottom layer is the physical layer which lays out how it connects to the wire, and the top layer is the application. Everything from the TCP/IP down is generic in the terms that all EtherNet devices can connect together. What determines if they can talk to each other is the application. ie someone who is using a windows explorer to try and connect to an IBM mainframe. They both can connect together on the EtherNet network, but they do not speak the same language. CIP is the new application layer for EtherNet/IP (The IP stands for Industrial Protocol not InterNet protocol) , which is also the same layer for ControlNet and for DeviceNet. This is how NetLinx works, and how you can go from EtherNet, down through ControlNet, and configure a device on DeviceNet. Even though the wire connection is different (Cat5, Coax, etc) , the main language (CIP) is the same throughout. Contrary to belief, EtherNet/IP doesn't use TCP/IP, it uses UDP/IP (User Datagram Protocol). The difference between TCP and UDP is that TCP sends the message and then gets a message back saying that its been recieved, where as UDP just sends the message out as fast as it can with no message back. Now for I/O control this doesn't make sense, as you would want to make sure the message got to the I/O; and in fact it does do a check. Go a little higher up to the application layer (CIP) and this is where the confirmation takes place. There is no need for both the TCP and the CIP to ensure the message to to it's intended destination, so why not let one take care of it (CIP) and then use the UDP to send the info out as fast as possible. I could go on and I know that someone else could go beyond what I know, but it gives you the jist of how the grand scheme works.

[Guest cj]

Thanks. This was very educational. This concept was always vague in all the documentation to me. This discussion cleared things up for me very much.