Maker Pro
Maker Pro

How to Avoid Idle Signal on Ethernet Cable IEEE 802.3

T

Tauno Voipio

Jan 1, 1970
0
That could be an idea, I am just worried the PC won't measure this correctly

Regards

Klaus



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.
 
T

Tauno Voipio

Jan 1, 1970
0
Of course this is true for any real Modbus RTU to Modbus/TCP I(UDP)
converter.

However, any dumb Ethernet/serial converter (knowing nothing about
Modbus or any other serial protocol) works surprisingly well, as long
as the higher level protocol only relies on the request and response
header and does not try to detect any interframe gaps.

For the master side, this is not a big problem, a large number of
systems are running all over the world.

For the slave side, the situation is much more demanding.

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

Tauno Voipio

Jan 1, 1970
0
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.


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).
 
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).

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.
 
T

Tauno Voipio

Jan 1, 1970
0
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).
 
J

Jasen Betts

Jan 1, 1970
0
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).

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,
 
K

Klaus Kragelund

Jan 1, 1970
0
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.

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
 
K

Klaus Kragelund

Jan 1, 1970
0
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.

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

Cheers

Klaus
 
K

Klaus Kragelund

Jan 1, 1970
0
On a sunny day (Mon, 23 Sep 2013 00:39:52 -0700 (PDT)) it happened Klaus


<[email protected]>:






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.
Point taken, thanks :)

Cheers

Klaus
 
T

Tauno Voipio

Jan 1, 1970
0
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,


To add insult to injury, the requirement for timed framing makes
it impossible to use hardware FIFOs, as they lose the timing.
 
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,

The 14550 UART is a brain dead construction even for RS-485, not to
mention Modbus RTU.

In that idiot design, you can get an interrupt, when the last byte is
transferred _into_ the shift register. For any practical RS-485
purposes, the only interesting time is when the last transmitted
message last stop bit has been actually sent.

For the idiotic 14550 chip the only way to detect this is by polling
(busy looping) a HW register (no interrupt available), until that bit
is actually sent.

While this might be acceptable for single thread executive like
PC/MS-DOS, this is completely unacceptable in any multitasking
environment.
 
T

Tauno Voipio

Jan 1, 1970
0
The 14550 UART is a brain dead construction even for RS-485, not to
mention Modbus RTU.

In that idiot design, you can get an interrupt, when the last byte is
transferred _into_ the shift register. For any practical RS-485
purposes, the only interesting time is when the last transmitted
message last stop bit has been actually sent.

For the idiotic 14550 chip the only way to detect this is by polling
(busy looping) a HW register (no interrupt available), until that bit
is actually sent.

While this might be acceptable for single thread executive like
PC/MS-DOS, this is completely unacceptable in any multitasking
environment.


Remember that the 8250 (base model for PC async serial interface)
was made for RS-232 modem connections. It is not interesting when
sending is done, only when more can be pushed to the pipeline.

The same applies even more to the newer versions with FIFOs.
 
Top