Sign in to follow this  
Followers 0
waterboy

PLC5's and ETH/IP compatibility

13 posts in this topic

Using RSLinx on my collection of PLC5's I have 10 PLC5/20E's that will respond to ETH/IP and 2 PLC5/40E's that will not. On these that do not I have to use ETH (Ethernet Devices). Browsing to one of the 5/40E's (Revision E.2) will bring up the Rockwell Ethernet Module Web page as expected, and the other (Revision D.2) will not. Controller Channel config is different between them as well. The firmware difference explains some of this but I suspect there is more to it than that since neither one will respond to the newer ETH/IP protocol. Is there anything else different about the 5/40E's? Or can I fix this with a "simple" firmware update (if that is even possible) ? In addition to the current desire to stop using ETH, I am concerned that this incompatibility will become an issue when I convert to Kepware and use OPC exclusively on these processors. I would be grateful for some clarification on this.

Share this post


Link to post
Share on other sites
The original PLC-5E used an A-B specific protocol that we now call "CSPv4". It uses TCP Port 2222 and was only ever implemented in the PLC-5E, the PLC-5/250, and the SLC-5/05. About 10 years ago the PLC-5E and SLC-5/05 were both upgraded to support both CSPv4 and EtherNet/IP. No ControlLogix family or MicroLogix family controller ever supported the old protocol. RSLinx Classic's "Ethernet Devices" driver does support both protocols. It tries to connect on TCP Port 2222 first, and if it received three "Port Closed" replies it switches to trying TCP Port 44818 (EtherNet/IP). The RSLinx Classic "EtherNet/IP" driver and the RSLinx Enterprise Ethernet driver both support only EtherNet/IP and rely (mostly) on a broadcast packet to browse the network. Almost all SLC-5/05 controllers can be firmware upgraded to support both CSPv4 and EtherNet/IP (maybe some very old Series A's cannot) and many PLC-5E and 1785-ENET can be upgraded. From RA Knowledgebase article 61405, the following Series and Revisions of PLC-5E controller support EtherNet/IP: All Series F controllers Series E revision D.1 and later Series D revision E.1 and later Series C revision N.1 and later Support for the 1785-ENET sidecar is a different topic. A-B recently made a major change to how they handle PLC-5 upgrades; they don't sell the upgrade kits anymore, but rather just offer to put the controller through the remanufacturing loop and it will be returned with all the systems checked out and the firmware upgraded. While this is more expensive than the firmware upgrade kits were, it also leads to fewer incidences of "I upgraded the firmware but the controller still faults" by addressing failing or aging hardware components.

Share this post


Link to post
Share on other sites
Thanks Ken, I just received a quote for this "service". $1300 for what equates to a chip change! I know they do more than that and warranty the PLC for a year, but I don't need or want all that. I just want to update the firmware so it communicates like the others. When it starts faulting I'll toss it, I wouldn't spend that much money on a PLC5 and I sure I don't appreciate Rockwell deciding what I need. I suppose that's how they force the stuff out of circulation. But I do appreciate your information. Thanks Ken

Share this post


Link to post
Share on other sites
There's a subtle issue involving the EtherNet/IP driver in RSLinx Classic that might (that's a maybe) explain the apparent difference between my records and your observations. When you create a new EtherNet/IP driver and browse the subnet, all your EtherNet/IP devices should populate the RSWho browse almost immediately. That's because RSLinx sends out a broadcast packet with the CIP "List Identity" command, and everything that supports EtherNet/IP is supposed to respond. Here's the thing; a handful of early devices do support EtherNet/IP but omitted the support for this crucial browsing command. The 1756-ENET is notorious; it can even run I/O over EtherNet/IP but it doesn't respond to the List Identity command. Try using the Ethernet Devices driver and appending ":EIP" to the IP address or host name. In RSLinx 2.51 and later, the :EIP suffix forces the software to skip the detection of CSPv4 and start immediately with EtherNet/IP on Port 44818. There's another trick I like, using the free utility TCPing. http://www.elifulkerson.com/projects/tcping.php You can TCPing 44818 and see if the device responds on that TCP port number. An original PLC-5E that doesn't support EtherNet/IP will not respond on that port but will respond on Port 2222.

Share this post


Link to post
Share on other sites
Thats a helpful little tool. 44818 is functional on both PLCs in question but not on a different one that a CLX MSG will not reach. (thats a different problem but is that actual basis of this line of questioning) Edited by waterboy

Share this post


Link to post
Share on other sites
Actually, there are even more protocols. CSP is another variant. PCCC is the original PLC-5 protocol which is supported at least for MSG'ing between nearly everything. CIP even supports a "PCCC over CIP" encapsulation mode that you probably know as the "PLC-5 compatibility" feature in Logix 5000. From experience, PCCC is much more stable on a PLC-5 (and even relative to Logix 5000 when using RS-Linx for an OPC driver) than CIP and there's a real disadvantage to going to Ethernet/IP for PLC-5's. At least as of a couple years ago, they still gave away upgrade kits for free. You have to have a local rep that knows how to find the secret AB ordering code to get one. When you get it, you first do a firmware flash to the PLC, then you shut it down and split the PLC in half to access the communications daughterboard, change the EPROM's on the daughterboard, and then put everything back together again and reload. It's somewhat complicated but works like a charm once done. The major difference between the older PLC's once the firmware has been upgraded and the newer ones as far as I can tell is that the older ones still have crappy (10 Mbps half duplex only) Ethernet support while the newer processors have full Ethernet support (100 Mbps, full duplex). The other thing I noticed is that although RS-Linx "recognizes" those PLC-5's over the Ethernet/IP driver (using the "list identity" broadcast function), quite often, Logix 5, etc., won't work correctly over this interface. As a result I gave up entirely on using the Ethernet/IP driver in Linx and simply used the "generic Ethernet" driver which is more stable and can auto-detect/support either protocol, without any issues with Logix-5/500/5000.

Share this post


Link to post
Share on other sites
Where is this "Generic Ethernet" driver located?

Share this post


Link to post
Share on other sites
I'm sure he means the "Ethernet Devices" driver. It's the one that you configure by entering a table of IP addresses for it to browse.

Share this post


Link to post
Share on other sites
So is there a possibility that I am imagining things when I perceive that the CLX boxes seem to prefer the ETH/IP driver over the Ethernet Devices Driver?

Share this post


Link to post
Share on other sites
I can't asnwer that last question, but want to add (just in case) that you can have multiple drivers of each type. We do this with the Ethernet Devices driver and give them useful names to segregate the way they show up in RSLinx. The Ethernet I/P driver can happily co-exist along side several Ethernet Devices drivers, and you can use it with your newer stuff, or as an alternate method to reach the same device. The big advantage to the Ethernet I/P driver (for me) is that it will find and list everything on the sub net sorted by IP address. The big advantage to the Ethernet Devices driver is that it lets you pick and choose (and exclude) what you want to browse. I think I have six or seven Ethernet Devices drivers configured on this machine, one for each area of our plant, and I have one Ethernet I/P driver...all of them running all the time. Forgive me if I am stating the obvious, and you are way past this simple stuff. Paul Edited by OkiePC

Share this post


Link to post
Share on other sites
No problem Paul, I appreciate ALL input. I also have multiple drivers running but I find the CLX are happier with ETH/IP. Makes a little sense that the PLC5's might be too. Like I said it may just be my wish that they are happier but it really seems that way. I'm going to move everything to OPC at some future point and hopefully negate the entire point of this thread (removing RSLinx completely except for programming nodes) , but until than I would like to optimize as best I can.

Share this post


Link to post
Share on other sites
I've had FEWER problems. The major beef I have with Linx is that for instance Logix doesn't always work well with the ETH/IP driver but works every time with the Ethernet Devices driver. And this extends beyond the simple "auto browsing" function of the ETH/IP driver. And yes, I've seen my fair share of instances where PLC's mysteriously disappear and then reappear magically, even if connections to other stuff in the area (like HMI's) maintains communication continuously while the ETH/IP driver flounders around doing whatever it likes to do when it's not working. Here's an example of the problem with either one and Linx in general. If you use it for NetDDE (no idea why you would do that these days), about once every 2-4 weeks at a plant I worked at, NetDDE just simply stopped collecting data on an InSQL historian. It would just inexplicably quit unless I shut down and restarted Linx. Under OPC, things are "better". It now only randomly locks up whenever a PLC has been offline for "some time" and this only happens with ControlLogix processors. If I create two connections and on one connection, I only monitor implicit tags (@tags, not real ones), nothing goes wrong. If I use a connection and monitor real tags, then occasionally whenever the processor loses communication for a period of time (somewhat random but at least in one situation I could get this to "work" after 4.5 hours), the connection again locks up. So with some scripting using the @tags, I can close and restart the connection to the real tags, and then everything works without a hitch. Now this works fine on the "Ethernet Devices" driver. On ETH/IP, I don't have as many options and also, that one seems to crash within 1 hour. In the same scenario if I use the ETH/IP driver with a PLC-5, I get the same crashes. If I use the "Ethernet Devices" driver, I don't get any OPC crashes at all! Either way, if I switch over to <insert your favorite name here> OPC (or OPC-UA) drivers, these inexplicable crashes go away. Rockwell by the way claims that first this is due to the fact that I don't like HMI's that crash on a regular basis like FTView SE and use more stable HMI's, and if you press them on it, then claim that this is due to a Microsoft bug. Either way, the fact that XYZ OPC vendor never has this problem (with any XYZ except Rockwell), sort of makes you go "hmm".

Share this post


Link to post
Share on other sites
OMG don't get me started on that train! I have had that same issue with Linx. I have had multiple cases with Rockwell for almost 3 years now and they (rockwell support) have consistently stopped replying to my email responses once they have tried all the same stuff that the last guy tried and then they close the case without solving it. Every time! It is narrowed down to the way linx handles comm errors (or rather doesn't handle them) from newer hardware. As far as the details, they are not consistent but these comm errors are always at the same time as the dropouts though not every comm error generates a dropout. It has nothing to do with connections, hardware, configuration, versions, other applications running... nothing else anything except the interaction between Linx and CLX hardware. So I have given up on Linx and will go to Kepware when I can do so. Rockwell recommended moving to RSLinx Enterprise. But that version is crippled Kepware so I am staying away from it in favor of the real thing. Would not surprise me at all to have Rockwell follow the Microsoft practice of modifying the standard just enough ( i.e. JavaVM, HTML) to cause problems with non-Rockwell versions of OPC software. but that's for another thread. I'm hoping to someday only RSLinx for programming and I wish I didn't need it for that!

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
Sign in to follow this  
Followers 0