Forums

How to Avoid Idle Signal on Ethernet Cable IEEE 802.3

Started by Klaus Kragelund September 19, 2013
On 9/21/2013 2:28 AM, upsidedown@downunder.com wrote:
> On Fri, 20 Sep 2013 12:49:03 -0700, Jeff Liebermann <jeffl@cruzio.com> > wrote: > >> On Fri, 20 Sep 2013 11:00:18 -0700 (PDT), Klaus Kragelund >> <klauskvik@hotmail.com> wrote: >> >>> 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 >> >> 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. > > 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)
Hi Jeff,

On 9/20/2013 11:37 PM, Jeff Liebermann wrote:
> On Fri, 20 Sep 2013 14:09:37 -0700, Don Y <this@isnotme.com> wrote: > >> I doubt that will work. Modbus is an application layer protocol. >> You're counting on the gateway to see this EIA485 message *destined* >> for a particular Modbus "Unit ID" (i.e., address on the 485 wire) >> and decide that it should, instead, be routed *out* to the ethernet >> side of the fence. To do so, the address field of the message >> encountered by the gateway would have to reflect the gateway's >> modbus address/unit ID. This would require rewriting the message >> "in" the "loopback connector". > > Full disclosure: I know nothing about Modbus.
<grin>
> Googling for info on Modbus loopback, I find: > Modbus&#2013266094; 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. > >> Just like looping an ethernet packet back through a router/switch >> won't guarantee that it gets *through* the router/switch! > 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).
On Sat, 21 Sep 2013 09:16:33 -0700, Don Y <this@isnotme.com> wrote:

>Hi Jeff, > >On 9/20/2013 11:37 PM, Jeff Liebermann wrote: >> On Fri, 20 Sep 2013 14:09:37 -0700, Don Y <this@isnotme.com> wrote: >> >>> I doubt that will work. Modbus is an application layer protocol. >>> You're counting on the gateway to see this EIA485 message *destined* >>> for a particular Modbus "Unit ID" (i.e., address on the 485 wire) >>> and decide that it should, instead, be routed *out* to the ethernet >>> side of the fence. To do so, the address field of the message >>> encountered by the gateway would have to reflect the gateway's >>> modbus address/unit ID. This would require rewriting the message >>> "in" the "loopback connector". >> >> Full disclosure: I know nothing about Modbus. > ><grin> > >> Googling for info on Modbus loopback, I find: >> Modbus&#2013266094; 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. >> >>> Just like looping an ethernet packet back through a router/switch >>> won't guarantee that it gets *through* the router/switch! >> 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). >
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.
On Sat, 21 Sep 2013 08:53:55 -0700, Don Y <this@isnotme.com> wrote:

>On 9/21/2013 2:28 AM, upsidedown@downunder.com wrote: >> On Fri, 20 Sep 2013 12:49:03 -0700, Jeff Liebermann <jeffl@cruzio.com> >> wrote: >> >>> On Fri, 20 Sep 2013 11:00:18 -0700 (PDT), Klaus Kragelund >>> <klauskvik@hotmail.com> wrote: >>> >>>> 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 >>> >>> 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. >> >> 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"
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.
>> 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.
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.
On Sat, 21 Sep 2013 18:25:49 +0300, Tauno Voipio
<tauno.voipio@notused.fi.invalid> wrote:

>On 21.9.13 12:21 , upsidedown@downunder.com wrote: >> On Fri, 20 Sep 2013 11:00:18 -0700 (PDT), Klaus Kragelund >> <klauskvik@hotmail.com> wrote: >> >>> >>> 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 >> >> 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. >> >> 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. >> >> The situation was quite different 5-10 years ago, but these converters >> have improved considerably. > > >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.
On Sat, 21 Sep 2013 08:48:12 -0700, Don Y <this@isnotme.com> wrote:

>On 9/21/2013 2:21 AM, upsidedown@downunder.com wrote: >> On Fri, 20 Sep 2013 11:00:18 -0700 (PDT), Klaus Kragelund >> <klauskvik@hotmail.com> wrote: >> >> 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).
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.
On Friday, September 20, 2013 8:23:41 PM UTC+2, Don Y wrote:
> Hi Klaus, > > > > [Argh, what is it with all these blank lines in your posts???] > > > > On 9/20/2013 11:00 AM, Klaus Kragelund wrote: > > > > > 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
> > > I could assume (assumptions is the.....) that the ethernet TCP/IP > > > latency would be small, > > > > 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? > > > > > and just record the time from sending a package to getting an answer > > > back, but it will probably be wrong by at least 1-10ms (the ping time) > > > > What does the current product *claim* this delay to be? Or, is > > it not specified?
Nothing specified Cheers Klaus
On Friday, September 20, 2013 9:39:05 PM UTC+2, Jeff Liebermann wrote:
> On Fri, 20 Sep 2013 11:01:33 -0700 (PDT), Klaus Kragelund > > <klauskvik@hotmail.com> wrote: > > > > >I would be satisfied with 0.1ms resolution, that would be more > > >than good (the unit without a gateway has 25ms turn-around time > > > > 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
On Friday, September 20, 2013 9:49:03 PM UTC+2, Jeff Liebermann wrote:
> On Fri, 20 Sep 2013 11:00:18 -0700 (PDT), Klaus Kragelund > > <klauskvik@hotmail.com> wrote: > > > > >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 > > > > 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
On Saturday, September 21, 2013 4:11:18 AM UTC+2, Joe Chisolm wrote:
> On Fri, 20 Sep 2013 11:00:18 -0700, Klaus Kragelund wrote: > > [snip] > > >> Klaus, > > >> > > >> > > >> > > >> I have not had my morning quart of coffee yet, so I'm not really > > >> following > > >> > > >> what you want to measure. Is the setup: > > >> > > >> Ethernet in -> gateway -> Ethernet out > > >> > > >> and you want to measure latency Eth packet to Eth packet? > > >> > > >> or > > >> > > >> Ethernet in -> gateway -> some other signal out > > >> > > >> and measure Eth packet in to assertion of some other signal out? > > >> > > >> > > > 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