rdarling3599

CiP Path for PLC 5/20E

18 posts in this topic

Does anyone know the path if I need to use a 3rd party HMI with a PLC5?  RA tech support doesn't know and I couldn't find what I was looking for the RA KB or Lit   Library.  I know how to do the CiP path from the HMI to a CLX and it works.  The 3rd party HMI has an AB PLC5 and EiP selection for the driver/data server type and so that is EiP/PCCC I presume.  It also is asking for the CiP path for this PLC5 and EiP selection (as well as IP address).  Can anyone offer any fdbk?   

Share this post


Link to post
Share on other sites
3rd party HMIs can be used with PLC-5 processors.  The design constraint will be how to communicate with it.  There are a number of serial (DF1) HMIs that communicate with the PLC-5 platform (Red Lion, Maple Systems, ProFace, etc.). Which PLC-5 CPU are you using?  The CPU will dictate which comm ports you have to work with. With PLC-5 comm ports are in use? http://www.maplesystems.com/1036/10360002.pdf https://www.hmisource.com/otasuke/files/manual/plc_connection/v70/roc/erocdhp.pdf

Share this post


Link to post
Share on other sites
PCCC is the command set for reading and writing PLC-5 data tables, and dates back to the DF1 and DH485 and DH+ protocols. It can be transported in Ethernet systems both over the older proprietary A-B "CSPv4" protocol, or via EtherNet/IP.   Your software might support both, and name the CSPv4 driver "AB PLC5". The EtherNet/IP protocol was added to PLC-5E controllers around 2000;  you'll have to check the RA Knowledgebase to be sure that its firmware supports EtherNet/IP if that's the driver you wish to use.    Controllers to which EtherNet/IP was added will support both CSPv4 and EIP simultaneously. In general, the PLC-5 controller is the endpoint of the CIP Path, rather than needing a "1, Slot#" at the end like the ControlLogix does.     If I saw separate fields for the IP address and the CIP path, I would try leaving the CIP path blank, or trying the default "1,0" path that most CIP devices will accept and ignore if they don't have or don't use a backplane object.

Share this post


Link to post
Share on other sites
Ken, Thanks for the reply.  The PLC 5/20E is a Ser D, Rev A.  Ethernet is ch 02 using transceiver.  I didn't see on RA site for PLC5 functionality info based upon series and rev (do see everything for Logix).  Also tried on the KB but didn't see info either.   RA tech support couldn't advise when I asked them last week.      I will check again to see if I can find if its PCCC or EIP.  

Share this post


Link to post
Share on other sites
EtherNet/IP support for PLC-5E controllers and 1785-ENET "Sidecar" modules is summarized in RA Knowledgebase article # 61405 .   The PLC-5/20E Series D got EtherNet/IP support in Revision E.1, so your Revision A controller will only have the classic CSPv4 protocol support. If your third party software did implement CSPv4 and called it "AB PLC5", then that's the configuration you should choose. As far as I know, PLC-5 controllers are only eligible for firmware upgrades when they are being remanufactured by RA;   they don't sell the field upgrade kits anymore.  

Share this post


Link to post
Share on other sites
Ken, Thanks for the reply.  Does the 3rd party HMI need to open a port to go to ch 2 Ethernet port on the PLC5/20E?  For the side car I believe it is port "2222".  Please advise if you can.  Thank you. 

Share this post


Link to post
Share on other sites
The A-B proprietary CSPv4 protocol uses TCP Port 2222, so if there's a TCP Port number field in their software, use that TCP Port number.   It's the same protocol for the built-in Ethernet on the PLC-5E and for the 1785-ENET Sidecar and for the older SLC-5/05 controllers. EtherNet/IP uses TCP Port 44818 for HMI messaging. Edited by Ken Roach

Share this post


Link to post
Share on other sites
Because you're dealing with two different protocols that both use the term "Port", I want to clarify: TCP Ports are a well-known aspect of TCP/IP networking, and are not the same as Port numbers in the CIP protocol.   In CIP, the Port number is 1 for the backplane, 2 for the first network port, and 3 for the second network port.     Most modules like the 1756-ENBT have just Ports 1 and 2, while the 1756-DHRIO has 1, 2, 3. Because you'll be using the old CSPv4 protocol, there are no CIP aspects to it, so when you fill out a "Port" field the software must mean TCP Ports.  

Share this post


Link to post
Share on other sites
Ken, Thanks.  Hopefully last question.  Is there info available on the structure of what the read n7 integer frame needs to look like to the PLC 5 in order for it to be able to understand it?  Port # set to 2222.   Robert

Share this post


Link to post
Share on other sites
The content and syntax of the PCCC command is the same no matter what network transport it travels over;  DF1 serial, DH+ over twisted-pair, ControlNet, Ethernet, etc.   Generally the reference for that is the classic DF1 command set reference, publication 1770-6.5.16, available from the RA Literature website. But the transport protocols are either simple and published (like DF1) or moderately complex and proprietary and unpublished (DH+, CSPv4 over Ethernet, etc.) When you started this thread, I thought you were just trying to configure a third-party software package to communicate with your PLC-5. Now it sounds like you're trying to write a driver from scratch, or explain to a driver author how the PLC-5 communications works. And that's where my expertise comes to an end.   RA only licenses its CSPv4 protocol to a small handful of partner companies, so many of the successful implementations of it over the years (like Wonderware's ABPLC5) are reverse-engineered.    That's not what I do, so I can't really advise on how to do it.

Share this post


Link to post
Share on other sites
Hello, This might help Byte Hex Dec Name Data 0 1 1 Request   1 7 7 PCCC command   2 0 0 Length   3 11 17     4 0 0 Session Handle   5 0 0     6 1 1     7 0 0     8 0 0 Status   9 0 0     10 0 0     11 0 0     12 0 0 Sender Context   13 0 0     14 0 0     15 0 0     16 0 0     17 0 0     18 0 0     19 0 0     20 0 0 Options   21 0 0     22 0 0     23 0 0     24 0 0 Handle   25 0 0     26 0 0     27 0 0     28 0 0 Target node   29 5 5 ?????   30 0 0 Our node   31 0 0 ???   32 0F 15   CMD - Command byte; typically 0x0F 33 0 0   STS - 0x00 in request 34 0 0   TNS - Increment per read 35 2 2     36 1 1 Function Code protected typed logical read with three address fields 37 0 0 Byte count to read   38 0 0 File number   39 1 1 File Type   40 0 0 Element number   41 6 6 Sub element   42 7       43 5       44 2         Regards, Mark http://www.peakhmi.com/   Edited by Mark-

Share this post


Link to post
Share on other sites
Wow, neat !     That's more detail than I've ever seen. It illustrates the problem with reverse-engineering, though;   if you don't know what some of the fields do, or if you just set them to zero because that's all you've seen other devices do, then you can't be very confident that they'll continue to work correctly or work with all the devices you expect them to. For various reasons, I generally bow out of threads that involve writing drivers.     I'm so impressed by guys like John Rinaldi and Lynn Linse that I don't even try to do what they do.

Share this post


Link to post
Share on other sites
Hello, If you are referring to the ????. A lot of time it is an application defined value. By that I mean the protocol allows the application to use that space for any purpose. Like an incrementing value to track the message. I do not recall in the this case but, it could have been that the two fields were actually a word and not a byte. But, the protocol only supports 0-255 for the field. That happens sometimes. >you can't be very confident It may seem that way but, most protocols do not contain information about the devices using the protocol and protocols are not created with fields that are specific to a device type/model.  The thing to do is to create messages with all the possible values for an unknown field and see it anything fails/changes. Not all fields in a protocol are "breaking" fields. At other times the fields report status at some layer level that have nothing to do with a proper "message" and can contain any value. My2c. Mark  

Share this post


Link to post
Share on other sites
Gentlemen,   Thank you.  I appreciate the screen capture Mark as that is what I need to do.  I also now have the AB docs 1756-PM020 and EIPEXP1_2_PCCCtoPLC5.  My goal is to figure out the frame that the PLC5 needs to see to understand it to be able to respond to the request of the 3rd party HMI (specifically a N7 read). Robert

Share this post


Link to post
Share on other sites
Both of those documents are specific to the EtherNet/IP protocol and as far as I can tell include no information about CSPv4. That's the difference I was trying to point out:  the older PLC-5E controllers support only the proprietary A-B Ethernet CSPv4 protocol, not the modern EtherNet/IP protocol used by ControlLogix and by the newer PLC-5E controllers.    You will not find official documentation available to the public about CSPv4, because it is proprietary to Rockwell Automation. The documents might help you understand the PCCC payload, but they will not address the application-specific or unknown-purpose fields in Mark's CSPv4 description. My preferred PCCC reference is 1770-6.5.16, the DF1 Protocol Reference.   It's old, but it's good.  

Share this post


Link to post
Share on other sites
Hello, You might find Delivery of CIP Over RA Serial DF1 Links to be of help. IIRC, a few other documents exist that have snippets of useful data. Mark  

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now