ControlLogix5000: V20.04.00 (CPR 9 SR 5) - TCP/IP Comms

Colt Hero

Member
Join Date
Apr 2015
Location
USA - Southeast (but from Northeast)
Posts
109
Can a ControlLogix PLC communicate over Ethernet using TCP/IP?

I need to interface to an existing (proprietary) system, sending TCP/IP 'frames' or buffers to request return data. I have the format of the frames for the data.

So I'm thinking I would create some template buffers (UDTs?) and some logic that would go into an AOI (or custom function block of some kind)?

There would have to be logic to read other Controllers (by IP Address) in the proprietary system, AND also to respond to requests for data from the proprietary Controllers.

If this cannot be done, then it's going to require hard-wiring, which I'd like to avoid.
 
Last edited:
Newer communication cards such as 1756-EN2T support open sockets over TCP.
I have never done the open socket logic, seemed like to much engineering time.
There may be a better way.
Are these other controllers something off the shelf? If they are a RedLion Data station would be easiest path, as long as they have a driver for the controller.
 
An older controller like that probably uses a 1756-ENBT, not a modern 1756-EN2T or the older specialized -EWEB.

So it won't support "open sockets", to send raw frames over TCP/IP.

Even if it did... I really dislike that method. If I had the choice to write a program in a Red Lion DataStation or an HMS Communicator and spend $700 or so on hardware, just to make the labor easier, I would do it.

Tell us more about those other controllers and their protocols.
 
These (45) Controllers are PowerBridge CH1915's. They're PowerPC-based, VME, dual CPU, running a Unix variant (Microware OS9), with Ethernet connectivity. We also have a Windows-based tool running on multiple desktop PCs that can communicate with these Controllers (for debug purposes). The TCP/IP code in the PLC would be using the same protocol that the desktops use. It is a proprietary frame protocol, but I have that. It's nothing too difficult to implement.

As far as the TCP/IP stuff ... I haven't written any of that in *years*, but from what I recall, it's pretty simple (not sure of this order, but): Listen on a well-known port#, open a socket, Bind (?), Read input buffer ... then Write buffer going the other way. That's about it.

The hard-wiring way is obviously doable, but it's clunky because the wires would come off *one* Controller on the Proprietary side (going to the PLC), and the other Proprietary Controllers would have to send their data through that Controller.
 
Last edited:
Rockwell really needs to get with the times. But I guess why do the engineering from free when you can get license fee's from 3rd party vendors?

With a compatible card you'd need like 5 or 6 MSG blocks to handle the connection. Then a few more to transfer the data. Once you got the connection thing set up and working, the data should be easy.
 
Rockwell really needs to get with the times. But I guess why do the engineering from free when you can get license fee's from 3rd party vendors?

With a compatible card you'd need like 5 or 6 MSG blocks to handle the connection. Then a few more to transfer the data. Once you got the connection thing set up and working, the data should be easy.

Oh my gosh! Really?? That sounds horrific! I was thinking I could do this with Structured Text?
 
Wait until the end of your Friday shift before cracking open that manual.

Have limes and salt handy. Tequila has always been my "you can do it !" elixir.

Is this a complex binary protocol with checksums and such, or just ASCII strings ?
 
Can you write an intermediate system to get the data to/from the PLC then send it to your proprietary system? I write large middleware systems and do this type of thing quite a bit. One of the places I worked had QNX boxes, Linux boxes, Controllogix, etc. We moved data to/from SQL to all those platforms.

There is also something called an unsolicited message listener where you configure a message instruction in the controllogix to send data to a server. I've used it once and it worked really well. It worked with a web plus card and I'm pretty sure it worked with the old ENBT also.

Forgot to mention I used Ingear for the unsolicited message.
 
Last edited:
There are many implementations of socket comms in the knowledgebase. This is a really simple one I use for writing and reading a socket server. Creating you own server to receive connections is going to be more difficult.

It is difficult to make something pretty because the message control structures need to be in the controller scope.

Edit:
Another thing to be wary of is that by default, closing a socket sends a RST instead of doing a full handshake. You can muck about with the message configuration to make it close the socket gracefully. I only noticed because the test server I was using didn't handle it gracefully. The real thing didn't mind.
 
Last edited:
About 10 yrs ago we implemented similar communications from B&R to both Rockwell and Siemens in order to not have extra hw cost in series production, where we would have B&R and either of the others.

Issues with Rockwell were changes to their network module not mentioned in release notes when a new revision was sent.

General issues that the data order in the stream when transmitting udt was .. interesting.
 

Ken Moore:

Thank you for that! I already sifted through it all ... doesn't look too daunting, just a little "different".

Ken Roach:

LOL! No alcohol here. And, if I remember correctly (it's been a while), I don't think the protocol is very sophisticated. It's just requesting and writing the equivalent of tag data, and I don't remember any checksums on the buffers, just block IDs, and a particular buffer structure, of course ... gotta find that information again. Hope I still have it.

SD_Scott:

I really don't want any "intermediate system". Doesn't seem like it's needed. But if I can't get this to work, I might be asking you for help with your solution.

Geoff White:

Hmmm ... this thing is gonna have to receive connections, too. What do you mean by: "It is difficult to make something pretty because the message control structures need to be in the controller scope"??

Thanks for the heads up on the 'close socket' issue.

Spaderkung:

Ugh! I hadn't thought of *that*! So Rockwell could break this thing down the road with their updates ...? I guess that's *always* a possibility with any update, though.

What do you mean by ..."General issues that the data order in the stream when transmitting udt was .. interesting" ??
 
When transmitting a udt, you must look at the transmitted bytes because padding is inserted depending on the order in udt. I don't recall what the specific issues when the fw revision changed.

Nowadays I would buy my way out of these situations by hw. Theres a reason that fancy gizmos exist. Although a current project is to use the free opc ua server from opc foundation together with snap7 in my own c# code for a client that in series production do not want the hw/license cost for a Siemens opc server for older plcs.
 

Similar Topics

Good day everyone. if you have a logic for 3 pumps (lead/lag/off), would you please email it to me? I really appreciate it!
Replies
7
Views
157
Looking to see if anyone has setup a ControlLogix Via Ethernet to a Omega Temperature controller CNi16D33-EIT-AL. Omega sent me an i-Server users...
Replies
0
Views
955
OK, (some of) you guys know by now that I'm not a PLC programmer, so I'm not really familiar with how a well-structured PLC program is typically...
Replies
2
Views
1,451
Sorry for these very basic questions, but I'm not a PLC programmer (per se): It appears that timers always seem to appear at the very end of a...
Replies
28
Views
10,272
If I define an INT or DINT for, say ... a BitFlag word ... is there any way to name each bit in that flagword with a unique name? It would seem...
Replies
17
Views
3,862
Back
Top Bottom