A customer had a product which acted as an Ethernet/IP originator (client) and needed to talk through a Digi One IAP to feed DF1 into a DH+ gateway. The catch is the DH+ gateway used the DF1 destination byte as the DH+ node address - and so far they could only make the Digi One IAP spit out a destination = 1. This made for pretty boring and unprofitable DH+ design!
(Sorry: I cannot explain "How to write an Ethernet/IP stack" in a single blog entry, so this entry assumes you already have a product speaking Ethernet/IP and just want to tweak how you talk to remote DF1 devices.)
The PCCC object (code: hex 0x67) is not part of the ODVA spec - it is a vendor specific object used by Rockwell/Allen-Bradley to talk to SLC5, PLC5E and MicroLogix PLC. I won't fully explain it here ... not much to explain; do a wireshark trace of a ControlLogix talking to a SLC5/05 or MicroLogix 1100 and you'll see all you need to see about the simple object.
The default service code of 0x4B has this form:
| Exec PCCC Service | 4B |
| IOI to PCCC Object | 02 20 67 24 01 |
| Originator Info | 07 03 85 50 4d 41 41 |
| Example PCCC Message | 0f 00 5c 00 a2 14 07 89 00 00 |
The only mystery here should be the "Originator Info". The 07 means a total of 7 bytes (including the 07). 0385 is a unique sequence number which you should change between messages. The 504d4141 is a "CIP Serial Number" which must be unique to your vendor id - most vendors just use the last 4 octets of an Ethernet MAC address.
However, there is NO remote node or slave address info, so the Digi One IAP or 1761-NET-ENI will create a DF1 message for destination=1 and source=0. So back to the customer's question ... how to force a DF1 message with say destination=5 and source=2?
The easiest solution is to switch to service code 0x4C, which has this form:
| DH+Like Service | 4C |
| IOI to PCCC Object | 02 20 67 24 01 |
| DH+ Like Header | 00 00 02 00 00 00 05 00 |
| Example PCCC Message | 0f 00 5c 00 a2 14 07 89 00 00 |
So the "Originator Info" has been swapped with an 8 byte structure of the form AA AA BB XX CC CC DD XX. The "XX" are control bytes of some sort - just leave 0x00. "AA AA" is the Destination Link; "BB" is the Destination node; "CC CC" is the Source Link; "DD" is the Source node.
Voila - both the Digi One IAP and the Rockwell 1761-NET-ENI will now create a DF1 message with destination=5 and source=2. Not too painful, was it.
To my knowledge all Rockwell Ethernet/IP PLC accept either code, and if you'd like to see the service 0x4C in action just set your RSLogix5000 MSG block to use "CIP with Source ID" and the ControlLogix switches from using service 0x4B to using 0x4C.
For completeness, there is a final service code of 0x4D with this form:
| Local PCCC Service | 4D |
| IOI to PCCC Object | 02 20 67 24 01 |
| Example PCCC Message | 0f 00 5c 00 a2 14 07 89 00 00 |
It is documented in DeviceNet gateway manuals to reduce total byte count - but it also lacks any destination or source info so is of limited use in Ethernet-based systems.
2 comments:
Lynn,
I am curious at to whether the Rockwell Ethernet/IP can be passed over PPP connections on such devices as their 9300 RADES or the SIXNET MDM Switch? It was my understanding that PPP connections couldn't/wouldn't pass "multicast" traffic?
scottkrose@gmail.com
Ethernet/IP doesn't require multicast. You can setup the class 0/1 producer/consumers for unicast, which would work fine over PPP.
Now, if YOU or a DEVICE requires multicast, then you'd be out of luck :-)
Post a Comment