How to Avoid Idle Signal on Ethernet Cable IEEE 802.3

Maximum 115.2kbaud

Yes, the 3.5c is a fixed value of 1.75ms above 19.2kbaud, so it really begins to count

Cheers

Klaus

Modbus frames apparently have unconstrained length, UDP packets have a maximum size, possibly for this reason the stream-based TCP protocol was chosen.

--
?? 100% natural 

--- news://freenews.netfront.net/ - complaints: news@netfront.net ---

If that is case, possibly the command algorithm can be improved by using windowing or pipelining such that one request is in-flight over ethernet and another (or the response) is on the modbus wire at any one time.

This makes the netowork and translation latencey immaterial (WRT throughput), as the gateway will always have atleast one packet queued and will keep the modbus as busy as it can.

--
?? 100% natural 

--- news://freenews.netfront.net/ - complaints: news@netfront.net ---

Any good Modbus/TCP to Modbus RTU support multiple Modbs/TCP clients and queues additional requests, while the previous transaction is in progress. Jus use two threads on the Modbus/TCP client and open one connection on each thread to the gateway port 502 and send requests through each socket.

An analyzer based on the RDTSC (Read Time Stamp Counter) should have sufficient resolution.

Even without that, perform a large number (say 100) full transactions and from that, calculate the average transaction time.

While the framing mechanism on the serial side would allow infinite frame length, in practice at least the standard function codes have only 8 bit BC (byte count) fields, so the maximum length for a Force Multiple Coils is 264 bytes =

1 (slave) +1 (FC) +2 (Addr) +2 (Coils) +1 (BC) +255 (data) +2 (CRC)

which fits well into an Ethernet (or UDP) frame.

The original Modbus/TCP paper by Swales, specifies a 6 byte Modbus/TCP header, including a 16 bit remaining byte count field, however, only 8 bits were to be used (allowing 0-255 bytes). With this specification, not all Modbus RTU frames could be carried over Modbus/TCP. With 255 bytes, the maximum size FMC command could be

1 + 1 + 2 + 2 +1 + 248 bytes

capable of carrying 1984 coils.

For register commands, the suggested maximum number was 120 registers for reads and 100 for writes.

i just checked the Modbus.org site and the current specification does not seem to limit the 16 bit byte count field to only 0-255, so apparently full sized RTU frames can be carried also on the Modbus/TCP side. However, it is unclear, how many servers are in use that only accept shorter frames, so to be on the safe side, on the client side you should use those old conservative values, unless you check each server individually.

From the original Andy Swales paper:

I don't agree with most of those justifications and use Modbus/UDP whenever possible. Quite a few devices supporting Modbus/TCP also support Modbus/UDP.

A short transaction e.g. for writing a single coil or register contains 8 bytes or 88 bits with parity in both request as well in response. At 115k2 a frame is 0.76 ms long and if you use the recommended 1.75 ms gap, the total transaction takes 5 ms. Even with 3.5 character times, the transaction takes more than 2 ms.

These are long times compared to what you would expect to see on the TCP side, including gateway, ethernet switches and NICs.

That is pretty fast if measured with a maximum size read or write transaction, since it takes about 25 ms at 115k2 transferring 125 registers in either direction, so there is not much turn-around time at the slave.

However, if that 25 ms is measured for a short transfer (1 register), which only should take 2-5 ms, as calculated in my previous post, the performance is bad.

Contrast to this, I do not understand why you need 0.1 ms resolution in your timing analysis, 1 ms should be sufficient. In a Windows program, you should get 1 ms resolution time stamps, if you enable the multimedia timers at program startup.

libpcap (used by Wireshark and tcpdump) records the times quite reliably, even on Windows (though I'd prefer something more Unixish).

Get and install Wireshark according to the instructions. It provides everything you need for your measurements.

You can send echo packets to the Modbus clients, even when they are working. The standard requires thet thy will be processed.

--

Tauno Voipio

The OP asked for measurement in a TCP/IP transport.

--

-T.

Me too. The TCP encapsulation is a similar incarnation of networking ignorance as the time-based framing constraints of Modbus/RTU (which are violated by practically all PC hosts).

--

-Tauno

The real question, what do you do, if you do not get a response from the Modbus/TCP connection within a reasonable time (maybe 100 ms) ?

• Send the request again using the old connection ?

• Make an orderly connection shutdown (which may fail if the other node is down) and then make a new three way connect handshake and wait it to complete, before sending the request again ?

TCP/IP might be attractive in some cases, if keep-alive messages are sent say 10 times a second, instead of the default 2 hour cycle.

In practice, you have to monitor the transaction timeouts (milliseconds) as well as monitoring the health of the TCP/IP connection and restart it as needed with up to tens of seconds of delay.

In a real time control system, if the data that does not arrive in time,it is useless and in some cases harmful, if it can't be flagged as obsolete. A TCP/IP implementation tries to buffer up to 64 KiB of data and when e.g. a cable is reconnected, all those old messages are sent at once, which could cause a lot of havoc.

A serial frame system, Ethernet level MAC frames and UDP/IP frames work nearly the same way, it is just a question of different transports. In all these cases, if you do not get a valid response after a few retries, the other end is unreachable and there is no need to break and remake any connections.

Right.

The Modbus frames, are by their nature, datagrams, and they should handled as such (Plain Ethernet, UDP).

--

-TV

Getting 3.5+ character-times of slience out of a 16540 UART seems tricky,

Perhaps wait for the shift-register0-empty flag to be set and then turn off the transmitter then send 4 characters of dummy data, and wait for the empty flag again. (that gets you 4+ character times)...

I don't expect that will be easy to do with a typical OS-provided serial driver, and a USB UART would be even worse,

--
?? 100% natural 

--- news://freenews.netfront.net/ - complaints: news@netfront.net ---

For the tests we are asking for the return of 2 registers (4 bytes)

That is what corresponds to process data, values that needs to be monitored to what seems like realtime

Cheers

Klaus

I guess 1ms should be ok, it translates to a 5% error in the measurement. Cannot be much higher though

Cheers

Klaus

On a sunny day (Mon, 23 Sep 2013 00:39:52 -0700 (PDT)) it happened Klaus Kragelund wrote in :

I dunno if anybody mentioned this, but in TCP/IP there is the acknowledge packet (or not). You cannot reliably see if your data is received UNLESS you got that confirmation back. This is what makes TCP/IP so much slower than UDP. But then UDP may have packets lost. The point is that TCP, via the same network ALSO will lose packets sometimes. but then those will be re-transmitted.

So it seems to be silly to ask for a guaranteed minimum time, unless you have the perfect network (cable), and even then (collisions in ethernet etc).

So you can basically NEVER guarantee a minimum delay.

But you could make a good guess as to how often the next nuke plant goes China (Syndrome), and the same way for the probability that a data packet will arrive out of your specified window in time. Hey!

You cannot loop back a half-duplex RS-485 port.

Point taken, thanks :-)

Cheers

Klaus