We have identified many devices which will convert modbus RTU serial to modbus TCP, but they all involve the following cycle:
(1) Receive modbus TCP request, (2) Convert to modbus RTU request and send request, (3) Receive modbus RTU slave reply, (4) Convert modbus RTU slave reply into modbus TCP slave reply, and send reply. Steps 1 to 4 can take up to 50ms, which is too slow for some of our customers. I know that Profibus ASICs are available which have dual-port RAM. The developer simply needs to read/write the dual-port RAM, and the ASIC handles the very fast profibus comms. Does anyone know if such devices exist for modbus TCP?

 

Not sure about asic chips, but Prolinx gateways offer essentially dual port ram where the gateway can collect info from the modbus rtu side and the modbus ethernet side can access this info. This eliminates the delays of forwarding a request that you talked about. Doing this requires that you have a predefined read/write set of registers that you access, and does not allow dynamic setup of registers to read/write on the fly.

 

Dual port RAM, TCP/IP, subspace communicator or quantum lines won't affect the fact that the entire device is limited by the speed of the Modbus RTU device.

One could create a custom solution that constantly polled a subset of the Modbus RTU registers and held them in RAM for quick reads by a TCP device, but I don't know of any off-the-shelf devices that can do this.

Alex Pavloff
Software Engineer
Eason Technology

 

Why not simply send modbus TCP directly? (That is, use an Ethernet card?)

Jiri
--
Jiri Baum <[email protected]> http://www.csse.monash.edu.au/~jirib
MAT LinuxPLC project --- http://mat.sf.net --- Machine Automation Tools

 

At the performance level of 50 ms (often just above the 'solve' PLC scan-time of any medium-to-large sized ladder logic application) it seems to me that you need to eliminate serial communication/control all together. Alex Pavloff says it best: "...the entire [system] is limited by the speed of the ModBus RTU device." This demanding application calls for all PLCs to have embedded Ethernet connectivity with “direct” I/O interoperability. In other words, that all PLCs can share values at a more efficient/automatic level “below” (at PLC configuration level) whatever communications request you generate right from logic/programming. Some folks call this Global Databases or Peer I/O, but whatever you choose to call it, the only ones I know that can do this are Modicon’s TSX-57, Quantum, and Momentum PLCs. Whether using a centralized or distributed approach, I think they can throttle your application to the level it seems you need. Check’m out and good luck…

 

Ubicom do a device that can be used a little like a Profibus ASIC, but not directly using Modbus TCP (though this is a fairly trivial implementation on top of the supplied protocol stack). Lantronix have a similar device, as well as a nice gateway device into an RS485 network.

Below that there are a growing number of 'zero copy' (i.e. with a shortcut through the protocol layering) implementations capable in principle of being run via a standard Ethernet controller
from a lower end micro. As usual, these give you TCP/IP, maybe a web server, and FTP, so you need to write your own Modbus TCP on top.

Cheers

Tim

 

Actually, I just realized what you were asking for - you're want to trade response time for latency.

You want a device you can query any time over Modbus/TCP with quick turn-around, which updates itself from Modbus/RTU at whatever (slower) speed it can. Is that right?

And to think how long it took me to understand that, given that the MatPLC does exactly the same thing, partly at my bidding... (MAT doesn't have its modbus slave module yet, so it doesn't fit, not to mention that it'd probably be a bit of an overkill.)


Sorry about the silly answer the other day.

Jiri
--
Jiri Baum <[email protected]> http://www.csse.monash.edu.au/~jirib
MAT LinuxPLC project --- http://mat.sf.net --- Machine Automation Tools

 

Yes, My Embedded device can constantly poll the subset of the Modbus RTU registers and held them in RAM. for quick reads by a TCP device,

Also I can do anything upon the customer reqiurements.


If you want know more detail,Please feel free to contact me.

Tony
[email protected]
Embedded firmware Engineer.
READYIP LTD.