Change Compact Logic Ethernet Port

Here is me again with a question that I am suspecting the answer is NO


I have a 1769-L33ER that already has some Ethernet/IP devices attached, but then there is this device that needs TCP/Sockets and messaging to operate, this device acts as a TCP Server and I can connect with a TCP client with my computer but not with the PLC, the problem is that the device uses port 2222 and there is no way to change that, but the PLC is refusing to open a socket on this port because is already used, and according to documents this port is used for Ethernet/IP communication and the processor would not open it for TCP


Can I change this port number in the PLC?

What is the name of the said TCP device ?

Even device server operates on port 2222, Logix controller local port does not have to be 2222. It can be anything and preferably you leave local port =0 to let controller to assign it automatically when you use Create message.

Saying this, port 2222 is very suspicious, iTCP port usually used by legacy PCCC comma, and UDP port used by class 1 logix comms.

Remember Sockets/TCP needs certain hardware to run this type of communications. Not all devices have the firmware required to run socket comms.

That processor can communicate sockets but has to have firmware of rev 20.011 or later.

Can you get it to run with sample application from Rockwell?
32962 - Sample Application for Ethernet module Sockets Feature

That processor can communicate sockets but has to have firmware of rev 20.011 or later.

Click to expand...

All versions of L33ER support sockets. 20.011 was the first revision.

There is a ton of documentation out there on sockets. I had to do a project last year on it and here is a pile of documents from Rockwell. They even have a webinar on it. So I had to read a lot and made a lot of progress by using the examples to build code that I could use.

passwordg said:

What is the name of the said TCP device ?

Click to expand...

I have a BTG Labs XA Surface Analyzer

https://www.btglabs.com/surface-analyst/xa-automated-surface-inspection

The guys were kind enough to send me documentation and some already testes VIs for LabView and I confirm those work in my side

Contr_Conn said:

Even device server operates on port 2222, Logix controller local port does not have to be 2222. It can be anything and preferably you leave local port =0 to let controller to assign it automatically when you use Create message.

Saying this, port 2222 is very suspicious, iTCP port usually used by legacy PCCC comma, and UDP port used by class 1 logix comms.

Click to expand...

I know that port 2222 is suspicious but is what they used and already confirmed with them that is hard coded

I also used your suggestion to leave in the PLC port = 0 but then I got a new error message "16#00ff extended 16#0000_0016"
Documentation says:
Open Sockets (TCP Client) is unable to connect to a third party device (Slave). The device reports WIN=0 and the 1756-EN2T module immediately closes the connection.For more information, search the Knowledgebase for Answer
ID522458 - Open Sockets: Open connection fails with error 16#0000_0046,16#0000_0016 or 16#0000_0033. << But I can't find this document!!



My original error was: 16#00ff16#0000_0030The address is already in use. This error can occur when multiple Socket Create requests are issued to the same port address.

So some extra details
The PLC is a L33 with firmware 30, I have no PC in the machine
My device is a BTG Labs Surface Analyzer that runs on android and has TCP server communication


I have already used LabView and LabWindows to open TCP communication with either the BTG or the PLC so I am sure that the devices uses port 2222 and only that and I am sure that my PLC is TCP enabled correcttly


I think I will have to create a bridge or a Man in the Middle with a RPI or something like that

1) IIRC*, UDP port 2222 is part of the Ethernet/IP protocol. So TCP port 2222 should not interfere with Ethernet/IP, which would be the only reason the PLC should refuse to use port 2222.

2) The JPEG displayed a couple of posts back appears to claim that the SA both

• Receives data on TCP port 2222**

AND

• Sends data to TCP port 2222***.

It is almost certainly not the case that both of those statements, about TCP port 2222 being used on both ends/nodes of the dialog, are true. I suggest using tcpdump or wireshark to view LabView's successful connection to determine what is actually going on.



* Somebody please correct me if I am wrong.
** "receives TCP commands on port 2222" - probably mistated, should be "receives commands on [TCP port 2222]"
*** "The SA will send TCP reply packets [...] to port 2222"

more about CSPv4

Classic A-B controllers like the SLC-5/05 and PLC-5E that run the 1990's-era Allen-Bradley Client-Server Protocol (CSPv4) use TCP Port 2222 as the incoming port.

Some software products (including RSLinx Classic) probe TCP Port 2222 with TCP Opens just to see if it's an A-B device and whether it supports CSPv4 on TCP Port 2222, EtherNet/IP on TCP Port 44818, or both (later-generation PLC-5E and SLC-5/05).

If you monitor RSLinx with Wireshark when it's first examining a station listed in the Ethernet Devices driver (the legacy one, not EtherNet/IP), you will see it attempt to connect using TCP Port 2222 three times. Once it has seen a "connection refused" three times, it switches to trying TCP Port 44818. It won't switch protocols unless it sees "connection refuse"; timeouts don't work.

So if there were just one TCP Port that a ControlLogix would specifically exclude even using raw sockets, it's Port 2222.

I don't know for certain that it does so; I haven't dug into the details of this particular application.

A-B has been using that TCP port number for so long, the designers of a device that was intended to be integrated into factory control systems would very probably be aware of this, and they made a bad choice if they ignored that fact.

This interface may need some sort of middleware.

well in the end I solved this with something I didnt knew that could solve it so simple


I used a raspberry pi 3 running raspbian as OS and a programming platform called node-red, it has a node extension (add on) for ethernet IP communication with AB Logix PLCs (supports INT, DINT, SINT and bool) and also has TCP nodes (functions) to comunicate with my other device


I made it this way, PLC sends to the raspberry an Integer with the command I want to run and a boolean saying that the command should be proccesed, the RPI reads this and inside node-red a "switch-case" function prepares the TCP command and sends it to my device, waits for answer and process the incoming TCP answer, parse the data and send back to the PLC



So basically, I made an etnernet-ip to TCP translator


I hope in the future someone can use this too

Outstanding ! Node-Red is such a neat tool for this sort of automation task.

Thank you for posting the update, and congratulations on your successful application. Make sure you document it well for the next engineer who works on it !

@QvixoteRoux: nice work! Can you post the code, or perhaps submit it to the node-red repository?


Did it turn out to be the case that both sides of the SA client/server interface needed to use port 2222?


I did not understand the problem in my previous post, so I hope I did not add too much to the confusion. I expect your solution was probably the simplest i.e. handle the most complicated part, the SA TCP client, in node-red, and abstract the PLC side to be Ethernet/IP, which is already available, and much simpler than writing a custom TCP client, on the PLC.


That said, another approach may be to again use a RPI in the middle and tunnel a non-2222 server port on the RPI to server port 2222 on the SA, using SSH:


Once that command was running on the RPI, the PLC could connect to port 3333 on the RPI, and the SSH connection would "tunnel" all packets between the PLC to port 2222 on the SA. The disadvantage of this approach is that now the PLC-side client has to be written to handle the SA ASCII protocol, and PLCs are not the most adept at parsing strings. Also, if both sides of the SA interface do indeed need to be port 2222, then this SSH approach would not work as there is no control of the client port number of the remote side of the tunnel.