Controllogix MSG to RSLinx - Communication Path help!

[Blue78]

Hello all, Where I'm working we have a current solution using a SLC 5/05 sending messages over ethernet to a PC, where an interface program picks up data from RSLinx. The desire is to move to the Controllogix platform, and our friends at AB have changed a whole mess of things about the instruction set. The MSG instruction, in particular, is much more robust, but also confusing. At the moment, I'd like to forgo the network card and supply the same messages over DF1. I have tags set up to emulate the data files being transfered from the SLC, but for the life of me cannot figure out how the MSG communication path needs to be configured for CLX. We're going from the Logix5563 controller in slot 2 using a PLC2 unprotected write over DF1 to a PC Running Rs Linx. The message command type, tag definitions, etc are all appropriate, the missing piece is just the communication path. I've read the help files, various forum posts, a few tutorials, but none specify a communication string to a PC, let alone using DF-1. Let me know if you need any more info! Any insight would be greatly appreciated.

[dmargineau]

For any Logix MSG instruction the "comms path" uses numerals 1,2 and 3 to relate to Port 1, Port 2 and Port 3 communication protocol ports . Numerals 4 through 13 relate to the slot number of the communications module the message should be routed to. 1 is the logical Backplane of the CLX system. 2 is the CLX's DF1 Serial Port Channel 0 OR any ControlNet Netwok Scanner interface OR any Ethernet/IP Network Scanner Interface OR any DH+ Network Hub Interface (1756-DHRIO)Channel A 3 is the CLX's DF1 Serial Port Channel 1 OR any DH+ Hub Interface Channel B. Example: If you wish to MSG to ControlNet Node 25 and the ControlNet bridge resides in slot 10 of the local rack your path would look like "1, 10, 2 ,25" or more like "go to the backplane, stop at slot 10, get on ControlNet, go to Node 25". For your application, after "naming" the Linx running PC's serial port let's say "33" and using Channel 0 of CLX's onboard DF1 port, your MSG instruction should follow the path "2, 33".

[Blue78]

Thanks for the reply dmargineau! I figured out the messaging syntax with your help. The DF1 interface was less than ideal connectivity wise, so we've added an Ethernet/IP card to the rack, with no issues sending messages over the network. Now, we have different problems. I've configured the MSG instruction to successfully send packets to a PC running RsLinx OEM (ip addresses, command types, etc are all set up correctly). The PLC reports DN = true on each message with no errors, and a packetsniffer (WireShark) confirms sent packets and acknowledgments. The problem now is, our PC application does not see the communication from the Controllogix controller to RsLinx. I think the issue now lies in the use of Ethernet/IP, which uses the newer protocol of CIP messaging. Although our SLC solution works under nearly identical configuration, I've learned that the SLC ethernet port is technically "AB Ethernet" protocol, which sends TCP encapsulated data. The CIP method may not be registerring in RsLinx the same way, or there are other considerations I may be missing. It's important to note that there is not any "target" data element noted in the MSG instruction in either the working SLC solution or in my current configuration of the CLX instruction. Has anyone else had any issues with the different communication formats? I've looked into the AB knowledgebase, but haven't had much luck with an application like this. Any further insight would be appreciated. Let me know if there's anything else I can mention that would help get to the bottom of this, and thanks in advance!

[dmargineau]

I couldn't answer your question unless there is a little more info about your PC application. However, RSLinx OEM is a local OPC server. If browsing your newly implemented Ethernet/IP network you are able to "see" the CLX PAC which contains the data required by your PC application, you don't need to "forcefully" rout the information you need transferred via a MSG instruction. Open up RSLinx OEM and under DDE/OPC choose 'Topic Configuration', 'New' and then browse to your processor; 'Apply", 'OK'. Once the Topic is created, all "Program Scoped" tags (word level!) are simultaneously available and unrestricted to be processed by any Windows application containing script related to the communication links included in the newly created RSLinx OEM topic. I don't know if there is a limit for how many "clients" could "attach" to the Linx OPC server;we have quite a few VB and FoxPro developed applications which "pick" data from CLX PACs via RSLinx . Microsoft Excel is also a very efficient Linx topics "Data Logger".

[Blue78]

Thanks again dmargineau for the help. We're using the RsLinx SDK in a C++ application to obtain information from the PLC's messaging. In a previous configuration, the SLC sends a write command to the host PC's ip address, where the application opens the ethernet driver in RSLinx, and can read each sent data file. We're looking to use CLX over Ethernet to do the same, but are encountering problems. After doing some more research, it seems that the woes encountered in this messaging process lie in the differences in the communication protocols of the SLC Ethernet port and the CLX ENBT EtherNet/IP interface. The SLC has a standard ethernet connection, using TCP transported messages. EtherNet/IP uses CIP encapsulated messages, which requires a completely different protocol in the RsLinx SDK. What makes this whole thing confusing is that CIP is a type of message in addition to a protocol of messages. For example, over Rs-232 you can send PCCC (old) style messages or CIP (new) messages. EtherNet/IP and ControlNet are deterministic CIP transport networks, which primarily support CIP type messages. They can also contain a PCCC message within a CIP message, but are always using the CIP transport to deterministically transmit data. We can use the standard API to open the communication driver and pull out data directly, because of the TCP transport and interpretation of the program. CIP encapsulated messages need to be handled deterministically, and thus the interface is more "robust". We have another Controllogix solution talking to our RsLinx SDK application just fine, but it uses DH+, which doesn't go anywhere NEAR the CIP transport standard, regardless of the type of messages sent. To make things more confusing, the problem could have nothing to do with the protocol, and instead require the older message TYPE. EtherNet/IP does not support native PCCC messaging - only CIP. DH+ supports both PCCC and CIP messages. The common denominator is: EtherNet/IP is not working with our application, due to its lack of support for older message formats AND/OR requiring CIP transport messages. Data can be retrieved using the standard driver-driven API in the RsLinx API using any older form of communication, such as the traditional TCP based ethernet found on the SLC 500's, or in current systems using DH+, but not EtherNet/IP using an ENBT card. So at this point, because we'd like the Ethernet interface to be used, we need to modify our C++ application to support the CIP communication protocol (or messages, for that matter), using the new and more complicated set of functions int eh SDK. Does anyone have experience with the RsLinx SDK and CIP communication vs the older "Interchange" style function calls? Any help is appreciated, of course. Thanks!

[Blue78]

So how about it? Anyone ever have problems migrating from AB Ethernet to EtherNet/IP, especially with the RsLinx SDK functions?