I am in the unfortunate position of trying to pass TCP/IP messages (from a number of external sources) between two AB ControlLogix PLCs.

The client is providing a serial communication link (Modbus, Profibus, etc.) between the two PLCs and I need to pass TCP/IP messages over the link via the PLCs. The plan is to send the TCP/IP message to the PLC. The PLC then sends the message content over the serial link to the other PLC which then spits the message out with the correct TCP/IP header.

Has anyone tried this? A Prosoft card exists for the ControlLogix that accepts ASCII messages over TCP/IP but does not look at the TCP/IP header and requires a end character to indicate the end of the message. I know this sounds backwards but the restrictions are enforced for various reasons. The serial protocol is used for other messaging over which we have no control.

Has anyone else been forced to send TCP/IP messages encapsulated in Modbus, etc?

 

Sounds like Rube Goldberg contraption to me. What exactly is the desired end result? I'm sure that this list can provide a number of alternative
answers to get the same result with the possibility of less strange things going on.

Alex Pavloff - [email protected]
Eason Technology -- www.eason.com

 

Prosoft Technology does make a card for that exact purpose. The MVI56-MNET Modbus TCP/IP Communication Module should do the trick! Also you may want to check www.modbus.org

 

You took the words out of my mouth. I can't even imagine what they are hoping to accomplish here. In its simplest form you can't simply send a TCP header across to a different machine and think your just going to "Send it out" the ethernet port. While we may be getting close to calling Ethernet the "New Serial Port", its far from the simple bytes out the door of your average serial port. Besides I would like to see a "Proprietary PLC AKA AB,GE,Modicon" that exposes the TCP/IP header to the ladder software. That would be interesting.

Please tell us you haven't placed a bid to do this job yet.

 

Yes, it is not the best way of doing this but we are forced into it.

The communications between the our two PLCs are routed through a third party device which only allows serial interfaces.

Unfortunately, the Prosoft MNET card is for a ControlLogix PLC communicating with another device using Modbus TCP/IP and is not serial. The closest thing they have (which may work) is the MVI56-GEC ASCII Ethernet module.

Our layout is.....

3rd party device -> Ethernet TCP/IP to
Our ControlLogix PLC -> serial to
other 3rd party device -> proprietary (serial encaps) to
other 3rd party device -> serial to
Our ControlLogix PLC -> Ethernet TCP/IP to
3rd party device

You are right...Rube Goldberg would have had fun with this one!!!

 

If both are on the same network, it seems kinda pointless. If they are on the same network, send the messages directly. If not, route, and send the messages directly. It is much easier to deal with sending to both on an intelligent host than to play all these games. I can't see the reason for the serial link with this little information. Or to do TCP/IP magic with PLC tools.

Regards

cww

 

The problem is that the third party system which sits inbetween our PLCs communicates using proprietary modems/protocols over an underwater cable which has a limited number of lines. There is no way we could have Ethernet over these lines even if there were sufficient lines available for use! The 3rd party system inbetween uses 1980s technology but we can't get rid of it!

Believe me - I don't want to do it this way but "needs must when the devil drives" - which is appropriate if you have ever met my client.

 

Now that's the piece of info that at least lets us know your not crazy for even venturing the question.

> The problem is that the third party system which sits inbetween our PLCs communicates using proprietary modems/protocols over an underwater cable which has a limited number of lines. There is no way we could have Ethernet over these lines even if there were sufficient lines available for use! The 3rd party system inbetween uses 1980s technology but we can't get rid of it!
>
> Believe me - I don't want to do it this way but "needs must when the devil drives" - which is appropriate if you have ever met my client.

 

<P>Assuming your are doing this to "piggy-back" on an existing serial link, you'll find far better solution as follows:
<PRE>
3rd party device -> ENet -> local PPP (or remote access server or router) = serial data #1
CLgx -> Existing local serial device = serial data #2
CLgx -> Existing remote serial device = serial data #3
3rd party device -> ENet -> remote PPP (or remote access server or router) = serial data #4
</PRE>
<P>Then buy a simple serial MUX, so the higher-level view would be:
<PRE>serial #1 > MUX\_existing serial link_/MUX > serial #3
serial #2 > MUX/ \MUX > serial #4
</PRE>
<P>Or better yet, use device-server/terminal server technology to get ALL of your serial data onto the Ethernet TCP/IP, then buy a pair of low-cost remote-access-servers ( our common IA protocol aware DIN-rail unit also supports PPP & simple RIP <a href="http://www.digi.com/products/device servers/digiOneIaRealport.jsp">http://www.digi.com/products/device servers/digiOneIaRealport.jsp</a> ) to create a serial link. It will allow any TCP/IP device on either end to route thru that serial cable. Performance won't be super, but then no connection at all is slower yet ;^)

<P>Best Regards

<P>Lynn August Linse IA Firmware Specialist, Digi Int'l (www.digi.com)

 

Let me make sure I understand correctly. You want to communicate between a 3rd-party device at location A and a 3rd-party device at location B. The devices typically communicate over TCP/IP, but the only communication link between A and B is a serial connection between two AB ControlLogix PLCs. The serial connection passes through some proprietary equipment, and cannot be made to support any new comm connections, such as SLIP (serial link internet protocol). No additional comm links (microwave, radio-modem, etc) can be added to the system.

If your PLC solution absolutely must implement transparent pass-through of actual TCP/IP packets, I think you're going to have a tough time. If, on the other hand, you have the spec for the ethernet application protocol the 3rd-party devices use, and the messages are pretty simple command/response, then you may be able to implement software proxies at each end.

That is, deploy a PC at each location A and B. Each PC is connected to its local 3rd-party device by ethernet, and to its local PLC by whatever PC-PLC comm link you typically use. The fun part is implementing a proxy program on the PC.

dev -> TCP/IP -> proxy -> PLC -> serial -> PLC -> proxy -> TCP/IP -> dev

The proxy takes ethernet messages from the device, extracts the minimum amount of relevant info required to recreate the message, and writes the data to some registers in the local PLC. The local PLC passes the data to the remote PLC. The PC program on the other end monitors the PLC registers, looking for an incoming message. When it gets a message (in the form of register data), it formulates a corresponding TCP/IP message and sends it to its 3rd-party device.

Depending on the nature of the ethernet protocol used to communicate between devices, identical (or nearly identical) proxies run on both PCs.

It's not necessarily the simplest system, but it does have a few things in its favor. It has a reasonably low impact on the PLCs; they're just passing some register contents back and forth, and responding to some additional data polls. All the extra logic is external to your PLC processing, and the logic can be modified, tested and debugged without interfering with your PLC operations. The proxy is a largely autonomous module, so it can easily be expanded with new features down the road, or scrapped without major impact when the client is ready to fork out for a dedicated comm line.

Good luck. Let me know if you need any help.

Greg Goodman
Chiron Consulting

 

Could ppp help in any way? It would let you establish a quasi Ethernet link across a serial connection. It would require a capable host at each end, but you can buy a lot of PC hardware for the cost of most of the other solutions I can think of.

Regards

cww

 

> Could ppp help in any way? <

It might be an option. I haven't looked into it in much depth.

One option may be to have the PLC and 3rd party device on a network at each end (both communicating using TCP/IP) with the network hubs/routers communicating over the proprietary serial link using PPP. Can this be done?

I haven't tried anything like it before and I'm pretty new to PPP. A concern I have is with timings due to all this extra work but I'm hoping that we can take care of that in the software.

 

I support what Lynn at Alist says. Get it all onto TCP/IP then use a device server get it serial and pipe in down the cable. The device server should handle the addressing redirection. Be careful about which one you use as some are more transparent than others.

 

I may be on the wrong site for this, but I'm curious: Have you ever heard of Crestron or AMX control systems.
Currently you are able to send/receive serial over a TCP/IP client. These control systems usually are open architecture in the sense that you can write your own logic. They are not cheap but in the long run it could pay off.

http://www.crestron.com

Alex Cuervo

 

Try the Red Lion Controls Data Station Plus. The software, called Crimson 3.0, is free and available as a download.

> I am in the unfortunate position of trying to pass TCP/IP messages (from a
> number of external sources) between two AB ControlLogix PLCs.

> The client is providing a serial communication link (Modbus, Profibus,
> etc.) between the two PLCs

---- snip ----