Posted 4 Dec 2015 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
Posted 7 Dec 2015 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
Posted 7 Dec 2015 5/20 e. Using ch 02 with transceiver. Share this post Link to post Share on other sites
Posted 7 Dec 2015 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
Posted 7 Dec 2015 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
Posted 7 Dec 2015 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
Posted 8 Dec 2015 Ken, Thanks - appreciate it. Robert Share this post Link to post Share on other sites
Posted 10 Dec 2015 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
Posted 10 Dec 2015 (edited) 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 10 Dec 2015 by Ken Roach Share this post Link to post Share on other sites
Posted 10 Dec 2015 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
Posted 10 Dec 2015 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
Posted 10 Dec 2015 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
Posted 10 Dec 2015 (edited) 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 10 Dec 2015 by Mark- Share this post Link to post Share on other sites
Posted 11 Dec 2015 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
Posted 11 Dec 2015 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
Posted 11 Dec 2015 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
Posted 11 Dec 2015 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
Posted 11 Dec 2015 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