Forums

How to Avoid Idle Signal on Ethernet Cable IEEE 802.3

Started by Klaus Kragelund September 19, 2013
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. -- Jeff Liebermann jeffl@cruzio.com 150 Felker St #D http://www.LearnByDestroying.com Santa Cruz CA 95060 http://802.11junk.com Skype: JeffLiebermann AE6KS 831-336-2558
Hi Jeff,

On 9/20/2013 12:49 PM, 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.
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". Just like looping an ethernet packet back through a router/switch won't guarantee that it gets *through* the router/switch!
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. Craft a message on the PC for the controller. There are a variety of Linux and windows tools that can do this. Use a bit in the parallel port as a trigger. Turn on the trigger bit and push the packet out the wire. The app/kernel delay from trigger bit to packet hitting the wire is going to be in the low uSec range. You could compute time on the Ethernet cable but that time is going to be in your final product and small anyway. Watch for the gateway to wiggle the RS485 signals. You could do it with a Intronix logicport analyzer or something similar. Other option would be to take something like a Mbed dev board and some simple code. Use the Mbed to generate the Ethernet packet and to watch the 485 lines. Last time I used a Mbed it was OK for quick little projects like this. [snip]
> I could assume (assumptions is the.....) that the ethernet TCP/IP > latency would be small, 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) > > Cheers > > Klaus
Pinging the box would give you a starting point. You could use something like hrPING or some other high resolution (uSec anyway) tool. That would tell you how fast the gateway can turn around a IP packet. I think the bigger issue is how long does it take to turn the IP packet into RS485. -- Chisolm Republic of Texas Still raining, 5.75in last check
On 20.9.13 9:00 , Klaus Kragelund wrote:

(Plenty of empty lines and some dicussion clipped)

> > 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]
> Klaus
IIRC, there is a ping command in Modbus protocol. Measure the signals at the sending Ethernet machine with Wireshark or tcpdump and scope the same on RS-485. You'll get the answer by a simple subtraction. If you want the total delay, the Ethernet trace is all you need. -- Tauno Voipio
On Fri, 20 Sep 2013 14:09:37 -0700, Don Y <this@isnotme.com> wrote:

>Hi Jeff, > >On 9/20/2013 12:49 PM, 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.
>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. 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). -- Jeff Liebermann jeffl@cruzio.com 150 Felker St #D http://www.LearnByDestroying.com Santa Cruz CA 95060 http://802.11junk.com Skype: JeffLiebermann AE6KS 831-336-2558
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.
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 ? 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.
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
What is your serial speed ? 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. I recommend splitting your serial Modbus slaves into several subnetworks, driven by separate Eth/serial converters driven in parallel by scanning programs. A 100BaseT backbone can easily handle the traffic from multiple serial networks. The cost of extra Eth/ser converters can be compensated by reduced RS-485 cabling costs, if the slaves are scattered around a larger area.
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. -- Tauno Voipio
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).
> 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).