Allen-Bradley and Modbus TCP/IP

Is it possible to communicate between an Allen-Bradley PLC5 or SLC-500 and distributed I/O using Modbus TCP/IP ?

Yes,
One can build a Ethernet board that fits in a SLC that speaks Modbus/TCP. Few would be up to this challenge and be crazy enough to do this. Finally, Rockwell Automation would probably save this crazy person by not providing necessary information to interface to the SLC or PLC5 bus.

or

One can use a gate way that communicates to the ABs using CSP and to the I/O using Modbus TCP. A product that does this may an probably exists. It will not be cheap.

Check out www.mysst.com. They have gateway products. Someone must have done a gateway on a PC or more likely a PC104 embedded board. It wouldn't be hard to do.

SST's X-linx gateway is great stuff - I had a SLC control GEnius I/O modules with it. I'm sure they must have one for Modbus TCP.

In the "module" solution, I know that Spectrum Controls makes a communication module for the SLC that talks Modbus+. Perhaps they have one for Modbus TCP

The question should be ...
Why does nearly every other manufacturer, except AB,
communicate via modbus protocol?

Control Engineering Magazine has adds for quite a few bridges between A-B and Modbus TCP.

Are both the SLC and the Modbus I/O existing? If not, you should consider an alternate PLC that does talk Modbus ethernet, or consider alternate distributed I/O that has Ethernet/IP (DeviceNet) capability.

Prolinx, http://www.prolinxgateways.com, offers several AB to Modbus TCP gateways. Their literature lists a device (4210 MNET-RIO)that goes from AB Remote I/O to Modbus TCP.

There's a funny little thing that can happen when you build yourself a module to do the conversion (if you're so inclined). A co-worker of mine has seen this when he used a modbus (RS232) module in a SLC.

In order to transfer data to/from the CPU, you're going to have to use M-file transfers across the backplane. Well, the communication link was working fine for this guy. But, the M-File transfers were taking too long to update the data across the backplane at the baud rate he was using. I'm not sure what the solution was, but I think it involved scaling back the amount of data transfered to include only what he REALLY needed.

Lesson learned: you're marginally better off looking for an in-line converter.

AK