Forums

How to Avoid Idle Signal on Ethernet Cable IEEE 802.3

Started by Klaus Kragelund September 19, 2013
On Saturday, September 21, 2013 11:21:29 AM UTC+2, upsid...@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. >
The Modbus TCP looks very much like the Modbus RTU (RS485), so the translation of the message is pretty simple Cheers Klaus
On Saturday, September 21, 2013 11:49:11 AM UTC+2, upsid...@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 > > > > 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
On 2013-09-21, Tauno Voipio <tauno.voipio@notused.fi.invalid> wrote:

> 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. -- &#9858;&#9859; 100% natural --- news://freenews.netfront.net/ - complaints: news@netfront.net ---
On 2013-09-21, upsidedown@downunder.com <upsidedown@downunder.com> wrote:
> On Sat, 21 Sep 2013 09:16:33 -0700, Don Y <this@isnotme.com> wrote:
>>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.
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. -- &#9858;&#9859; 100% natural --- news://freenews.netfront.net/ - complaints: news@netfront.net ---
On 22 Sep 2013 00:18:20 GMT, Jasen Betts <jasen@xnet.co.nz> wrote:

>On 2013-09-21, upsidedown@downunder.com <upsidedown@downunder.com> wrote: >> On Sat, 21 Sep 2013 09:16:33 -0700, Don Y <this@isnotme.com> wrote: > >>>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. > >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.
On Sat, 21 Sep 2013 14:52:50 -0700 (PDT), Klaus Kragelund
<klauskvik@hotmail.com> wrote:

>> 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
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.
On 22 Sep 2013 00:03:33 GMT, Jasen Betts <jasen@xnet.co.nz> wrote:

>On 2013-09-21, Tauno Voipio <tauno.voipio@notused.fi.invalid> wrote: > >> 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.
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 &#2013266065;transaction&#2013266066; 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.
On Sat, 21 Sep 2013 15:05:05 -0700 (PDT), Klaus Kragelund
<klauskvik@hotmail.com> wrote:

>> 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
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.
On Sat, 21 Sep 2013 14:51:41 -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
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.
On 22.9.13 12:52 , Klaus Kragelund wrote:
> 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
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