Control logix PLC to Linux over Ethernet?

Hello all, I have to send and receive data to/from a Control logix PLC to a Linux based system. The Linux has a spare Ethernet port and the client wants to use this. What is required in the PLC rack? Is an Enet module ok, or will this require a driver (eg RSLinx) running on the Linux PC?
If there isn't a driver on the Linux, then do I need to use the Eweb card with its wonderful "new" socket technology using MSGs?

TIA

Yes,
You will need to use EWEB open socket interface or check with prosoft - thay may have a driver.

Hmm, I was afraid you'd say that.

I've been playing with the Eweb this week (after upgrading firmware). It's been a bit of a pain frankly, managed to send/receive data but its very longwinded and code hungry.
A few bugs/discrepencies in the documentation too. For instance, gotta luv the timeout. Rockwell documentation says timeout is in milliseconds, actually found out its in nanoseconds, multiplied by a register value. When the multiplying register contains 0, the timeout is multiplied by 4,when it contains 1 the multiply factor is 8, 2=16 etc!!!
Also, because there is no way of knowing that data has been sent from A.N.Other to the EWeb module, you have to poll the card with MSG reads to find out if anything's arrived. In addition, if A.N.Other closes the connection, the PLC doesn't know until it attempts a read/write. PLC-Host programming circa 1980's.

For instance, gotta luv the timeout. Rockwell documentation says timeout is in milliseconds, actually found out its in nanoseconds, multiplied by a register value. When the multiplying register contains 0, the timeout is multiplied by 4,when it contains 1 the multiply factor is 8, 2=16 etc!!!

Click to expand...

I think you are a little bit confused:
All TO values devined in SOCKET UDTs are in millisecondes.
The particular one you refered to is not for socket service - it is for connected MSG instruction timeout.
And this TO is in microseconds.
I would not touch this at all, leave it at 30 sec.

Just set read instruction TOs to 1 sec.
It will give you DN bit every 1 sec.
Check: if LEN>0 you got data.

I agree, it is not user friendly to check if connection still open. Also you can't send RD and WR over the same socket at the same time. So I am doing very short repeatable reads, if I need a write, I block read and insert write instead.

I don't agree about 1980s - all programming languages still do this if you don't have nice API.

I've spend last 3 months doing mostly logix for EWEB sockets - they are friendly now

Contr_Conn said:

Just set read instruction TOs to 1 sec.
It will give you DN bit every 1 sec.
Check: if LEN>0 you got data.

Click to expand...

I bow to your greater knowledge (beats my 3 days). If I read, and there is no data available, I don't get the DN bit. I just time out and get the ERR. If data is then sent via the Host PC to the EWeb (whilst my read MSG is errored), then when I re-enable the MSG block, I don't receive the data, just sit there again with the EN bit on until I time out again. Surely the data should be in the EWeb buffer?

My customers use ENBT cards for the Control Logix ethernet connection. They use Ron Gages CEL library for the ethernet connections. I don't know why one would want to use a EWEB card.
RSLinx is not required. RSLinx can't run on Linux anyway unless someone has found a way to run it using a PC emulator.

There are many installations like this although most have modified Ron Gage's library to work on Windoze instead.

rongage.org offers the Allen-Bradley Ethernet libraries for Linux.

Pyramid Solutions (www.pyrasol.com) also has some Unix and Linux libraries for sale, including Class 1 and Class 3 communications.

I've heard that RSI is working on a Java-based "Linx Services" software product that will be cross-platform portable, but that's 2006 or later.

I bow to your greater knowledge (beats my 3 days). If I read, and there is no data available, I don't get the DN bit. I just time out and get the ERR. If data is then sent via the Host PC to the EWeb (whilst my read MSG is errored), then when I re-enable the MSG block, I don't receive the data, just sit there again with the EN bit on until I time out again. Surely the data should be in the EWeb buffer?

Click to expand...

This is incorrect. Look at the timeout in READ MSG UDT.
This timout will give you DN bit the same way as incoming data except LEN will be 0.
I set it at 1 second or so. Just make sure this timeout is less than MSG instruction TO you refered earlier.
Here is example how to do it:
A138737930 - 1756-EWEB Open Sockets Application sample

My customers use ENBT cards for the Control Logix ethernet connection. They use Ron Gages CEL library for the ethernet connections. I don't know why one would want to use a EWEB card.

Click to expand...

... because these gages understand CIP or PLC5 messages.
For dummy RAW ASCII TCP/IP devices you have to write your own protocol handling. ENBT does not do it. EWEB is the only device that has open socket interface. It does not use RSLINX.
It has nothing to do with EWEB's webserver feature.
It just happen that Rockwell put open sockets to the EWEB and not ENBT. ENBT -I/O control, EWEB - web and sockets.

Contr_Conn said:

For dummy RAW ASCII TCP/IP devices you have to write your own protocol handling. ENBT does not do it. EWEB is the only device that has open socket interface. It does not use RSLINX.
It has nothing to do with EWEB's webserver feature.
It just happen that Rockwell put open sockets to the EWEB and not ENBT. ENBT -I/O control, EWEB - web and sockets.

Click to expand...

Wow... I need to read up on this. Raw sockets are the way to go if you are passing specific information and not just reading blocks of the PLC's memory. But I've only done this with Opto22 where Ascii parsing is no big deal.

Contr_Conn said:

This is incorrect. Look at the timeout in READ MSG UDT.
This timout will give you DN bit the same way as incoming data except LEN will be 0.

Click to expand...

For UDT this may well be true. I am however, using TCP and have it set up on my desk. On powering the read block, the EN comes on, and stays on until either data arrives in the buffer and is read (DN bit) or no data arrives before the timeout (ERR bit).

UDT is User Defined Tag. It has nothing to do with UDP (protocol)

Open Read MSG,
look at the tag in the Source Element field (top right corner).
This tag is UDT structure.
One of the elements of this tag is a timeout.
This timeout needs to be set for 1 second. (1000 ms)
It will give you DN bit with zero LEN.

UDT structure:
Timeout DINT Specify the timeout in milliseconds
BufLen DINT Specify the number of bytes of data to receive.

Doh - I'm just not with it this week - sorry.
Found the problem - Had my UDT timeout set too high as you intimate (I put it up from 1 second so I had a chance to simulate the comms & see what was happening. So I caused my own problem, because I put the timeout higher than the MSG timeout, and it was the MSG timeout causing the error.
Anyhow, its looking good now.
Why has Rockwell added the socket interface to the EWeb and not the Enet? A cynical person may think its because the EWeb module is more expensive.

Why has Rockwell added the socket interface to the EWeb and not the Enet?

Click to expand...

To separate I/O control from unscheduled comms like sockets.
Also ENBT memory is full, EWEB has larger memory.
I think it's logical to have I/O control on ENBT, WEB and Sockets on EWEB