How to Avoid Idle Signal on Ethernet Cable IEEE 802.3

[Don Y]

On Fri, 20 Sep 2013 11:00:18 -0700 (PDT), Klaus Kragelund

The real issue for ethernet to serial converters is how to split the
serial stream to Ethernet packets. The naive approach would be to send
one Ethernet package for each serial character, which is of course
totally unacceptable.

In practice, you haver to assemble several characters to a frame and
send a frame when the frame is full or the last character has been
received. Some old converters waited more than 10 ms with no more
serial characters, before sending the last Ethernet frame.

The Modbus protocol includes provisions for encapsulating a
modbus message in an ethernet frame. The gateway just
peels off the ethernet framing, then "interprets" the
modbus message contained within -- and pushes it onto the
wire (the gateway typically being a modbus master).

If the converter understands something about the serial frame, such
knows what is the terminating character in the frame and then send the
last Ethernet frame.

Serial Modbus RTU separates frames with an idle period at least 3.5
character times long, so that is the delay before sending the Ethernet
frame. However, an idle period longer than 1.5 character times is
illegal in Modbus, so you should wait at least that period of time,
before sending the Ethernet frame. The upper level CRC check would
then reject this frame, if such gaps exists within a message.

My experience with reasonable serial speeds (115k2 and below), modern
eth/serial converters send that last frame quite rapidly and any
internal processing delays within the gateway or Eth switches are
small, compared to serial character times (100us@115k2) at reasonable
serial speeds.

Modbus is much slower than a typical ethernet. So, there is a
potential for the gateway to be overdriven by ethernet packets
intended for the modbus network (unless you drive it synchronously).

 

[Don Y]

What is an RS-485 loopback adapter ?

I know what an RS-232 (connect pins 2 and 3) or RS-422 (Tx+ to Rx+ and
Tx- to Rx-) loopback adapter is, but what is a 2 wire RS-485 adapter ?

Obviously doesn't make much sense in a 2-wire/simplex/HDX deployment.
<grin>

Think: "4-wire"

Regarding loop back messages on RS-232/422, the Modbus function code 8
(Diagnostics) with subfunction 0 could be used, since it has the same
bit pattern in both request and response, so it can be used in
loopback tests.

But you still have to deal with the *addressing* issue.

Imagine trying to implement an ethernet ping by simply
capturing the electrical signals on the wire and
"playing them back" a short time later. (hint: they'd
just be "seen" twice by the targeted node, not "returned"
to the originator)

 

[Don Y]

Hi Jeff,

Full disclosure: I know nothing about Modbus.

Googling for info on Modbus loopback, I find:
Modbus® RTU Serial Communications User Manual
<https://www.honeywellprocess.com/library/support/Public/Documents/51-52-25-66.pdf>
which offers on Pg 9 and 20:
RTU Function Code 08 Loopback Test.
Used for diagnostic testing of the communications port.

3.6 Function Code 08 - Loopback Message
Description
Echoes received query message.
Kinda looks like it has a suitable repeater (store and regurgitate).

Yes, but you are no longer measuring the "delay through the gateway".
Instead, you are measuring (twice) the delay through the gateway,
the time up and down the stack in the "PC" that is talking to the
gateway, the time to transmit the loopback message and its reply
(8+8 characters @ < 38K baud =~= 4ms) plus the time inside the modbus
slave to decode the message and schedule its reply (do you
now have to "measure the processing delay in the targeted node"?)

An ethernet ping "works" because the transport delays are smaller
(assuming no congestion in intermediate switches) and the ICMP
echo servers *tend* to be written "down low" in the network stacks
(instead of at the application layer).

 

[[email protected]]

Hi Jeff,





Yes, but you are no longer measuring the "delay through the gateway".
Instead, you are measuring (twice) the delay through the gateway,
the time up and down the stack in the "PC" that is talking to the
gateway, the time to transmit the loopback message and its reply
(8+8 characters @ < 38K baud =~= 4ms) plus the time inside the modbus
slave to decode the message and schedule its reply (do you
now have to "measure the processing delay in the targeted node"?)

An ethernet ping "works" because the transport delays are smaller
(assuming no congestion in intermediate switches) and the ICMP
echo servers *tend* to be written "down low" in the network stacks
(instead of at the application layer).

The OP is essentially interested how many slaves can be served each
second. Thus the total transaction delay (request+response) is
critical.

With Modbus RTU, the master _must_ observe the 3.5 character delay
between receiving a response from one slave, before sending a request
to an other slave. Otherwise, any properly working slave on the bus is
not able to recognize, if the next request is addressed to it, causing
a timeout situation.

 

[[email protected]]

Obviously doesn't make much sense in a 2-wire/simplex/HDX deployment.
<grin>

Think: "4-wire"

The original RS-422/485 standard recognize a 4 wire RS-485
configuration, in which the master has the transmitter constantly on
(essentially RS-422), while each slave listens on one pair (the master
Tx), but the slave only activates the transmitter when addressed and
send the message to the master Rx pair. I have sometimes forced to use
this configuration with badly behaving Modbus RTU slaves, since there
are now huge gaps between requests on the master Tx pair.

But you still have to deal with the *addressing* issue.

A loopback test with non-zero (non-broadcast) and no slave connected
to the gateway will simply return the same bit pattern.

Imagine trying to implement an ethernet ping by simply
capturing the electrical signals on the wire and
"playing them back" a short time later. (hint: they'd
just be "seen" twice by the targeted node, not "returned"
to the originator)

Of course, any real slave is disconnected during such ping tests.

 

[[email protected]]

Modbus has a standard means to pack the frames into TCP transport
(though UDP had been more suitable). The converters I know decode
Modbus frames from serial line and forward them in the standard
way in TCP transport, and the same to the other direction, of course.

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.

 

[[email protected]]

The Modbus protocol includes provisions for encapsulating a
modbus message in an ethernet frame. The gateway just
peels off the ethernet framing, then "interprets" the
modbus message contained within -- and pushes it onto the
wire (the gateway typically being a modbus master).

Since Moxa has already been mentioned in this thread,the Moxa MB3000
series converters do exactly that.

However, any (dumb) garden variety Ethernet to serial converters can
be used at the master side, provided that the message encoding is done
by the message header and not by any inter frame gaps.

 

[Klaus Kragelund]

Hi Klaus,



[Argh, what is it with all these blank lines in your posts???]

The problem is how to sync those two clocks? I thought about making a

small program to send the TCP/IP packet from the PC and toogling some

other signal at the PC at the same time, so I could measure the time

from that toogle to the gateway RS485 port reacted, but that would only

be the delay in one direction

Is there any bit of code on the modbus side that is automatically

invoked when "something special" is sent to it? Something that

you can observe independently?

Yes, but I do not have access to the code.

Similarly, some event that you can manually generate on the

modbus side that will cause some "specific" packet/message to

be IMMEDIATELY sent up the wire. I realize you would have to

arbitrate for ownership of that bus (you would have to do

this any time ANY traffic, regardless of direction, was gated

onto the bus) but you could possibly arrange for other traffic

to be quiescent?

I have full control of the bus, but it's pretty easy just to measure it

Is the content of those messages "time critical" in that they

are used *in* the control loops? Or, just SCADA that you

would *like* to have available, "promptly" (for some idea of

"promptly"). I.e., does the performance of your overall

system degrade as the propagation delay across the gateway

increases?

Not time critical, we just want to check the performance

Depends on how efficient the gateway is at moving the packets

it encounters. E.g., does it have to do any filtering or does

it just pass everything destined for a particular address/subnet?







What does the current product *claim* this delay to be? Or, is

it not specified?

Nothing specified

Cheers

Klaus

 

[Klaus Kragelund]

What unit? What and how are you measuring latency?

Our own unit. Measuring the start of the master transmission to the end of the telegram from the slave

25 msec is a very long delay. Typical small packet ICMP latency for

my junk router from LAN -> WAN -> LAN is about 1-2 msec. Something is

wrong with your measurement.

That's primarily the delay of the microcontroller in the unit.

Please re-read my postings and answer the other questions:

Between which ports on the "gateway" are you going to be measuring?

I did answer. From Ethernet->Gateway->Modbus RTU and vice versa

What's the Moxa model number?

UC 7112. It's basically a Linux computer with 2 ethernet and 2 serial ports. The Modbus TCP/IP SW was loaded into this

http://www.moxa.com/product/UC-7112_UC-7110.htm

For additional entertainment, try pinging with large packets and watch

the latency increase.



I suspect that you're trying to determine what to put on a data sheet

or product specification. Whatever number you pick, it has to be

measureable by the customer. If I can't understand what you're trying

to accomplish, what devices you're measuring, and how you intend to

measure it, there's little hope that a prospective customer can do it.

Revising the 802.3 specifications for your convenience isn't going to

help.

I am trying to see how fast the system would react, so for example how fast a repetition rate can be used in a round robin system using the gateway.

Cheers

Klaus

 

[Klaus Kragelund]

Install an RS-485 loop back adapter in the RS-485 port.

Spew some data on the ethernet port to the RS-485 port.

You should see the data coming back on the ethernet port.

Measure the delay with a protocol analyzer or custom software.

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

Regards

Klaus

 

[Klaus Kragelund]

On Fri, 20 Sep 2013 11:00:18 -0700, Klaus Kragelund wrote:

[snip]

Sorry if that is not clear, it is:

Ethernet in -> Gateway -> RS485 out (Modbus)

So I am interested in the delay of the gateway, so we can estimate the

round-robin cycle time for a number of units connected to the gateway,

with the delay of the gateway included in the equation

[snip]

I would try and find a old PC with a parallel port. Install Linux and

get the parallel port driver code and examples. These let you send

data to the parallel port easily.

The old PC would do the trick since the 100Base T4 does not have idle signalling and the task is reduced to just plugging on a scope, what I initially thought would be the way to measure the delay

Cheers

Klaus

 

[Klaus Kragelund]

The real issue for ethernet to serial converters is how to split the

serial stream to Ethernet packets. The naive approach would be to send

one Ethernet package for each serial character, which is of course

totally unacceptable.

The Modbus TCP looks very much like the Modbus RTU (RS485), so the translation of the message is pretty simple

Cheers

Klaus

 

[Klaus Kragelund]

What is your serial speed ?

Maximum 115.2kbaud

In any half duplex protocols, such as Modbus RTU, the total throughput

will increase by much less than a factor of 2, when doubling the line

speed, due to various fixed delays, thus there is a diminishing return

when increasing line speed.

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


Cheers

Klaus

 

[Jasen Betts]

Modbus has a standard means to pack the frames into TCP transport
(though UDP had been more suitable). The converters I know decode
Modbus frames from serial line and forward them in the standard
way in TCP transport, and the same to the other direction, of course.

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

 

[Jasen Betts]

The OP is essentially interested how many slaves can be served each
second. Thus the total transaction delay (request+response) is
critical.

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.

 

[[email protected]]

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.

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.

 

[[email protected]]

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

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.

 

[[email protected]]

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

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:

Developers familiar with MODBUS may wonder why the connection-oriented TCP protocol is used rather
than the datagram-oriented UDP. The main reason is to keep control of an individual ‘transaction’ by
enclosing it in a connection which can be identified, supervised, and canceled without requiring specific
action on the part of the client and server applications. This gives the mechanism a wide tolerance to
network performance changes, and allows security features such as firewalls and proxies to be easily
added.

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.

 

[[email protected]]

Maximum 115.2kbaud

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

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.

 

[[email protected]]

Our own unit. Measuring the start of the master transmission to the end of the telegram from the slave

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.