Forums

How to Avoid Idle Signal on Ethernet Cable IEEE 802.3

Started by Klaus Kragelund September 19, 2013
On 21.9.13 11:39 , upsidedown@downunder.com wrote:
> 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. >
The OP asked for measurement in a TCP/IP transport. -- -T.
On 22.9.13 10:21 , upsidedown@downunder.com wrote:
> 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.
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). -- -Tauno
On Sun, 22 Sep 2013 14:07:22 +0300, Tauno Voipio
<tauno.voipio@notused.fi.invalid> wrote:

>> 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. > > >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.
On 22.9.13 2:46 , upsidedown@downunder.com wrote:
> On Sun, 22 Sep 2013 14:07:22 +0300, Tauno Voipio > <tauno.voipio@notused.fi.invalid> wrote: > >>> 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. >> >> >> 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. >
Right. The Modbus frames, are by their nature, datagrams, and they should handled as such (Plain Ethernet, UDP). -- -TV
On 2013-09-22, Tauno Voipio <tauno.voipio@notused.fi.invalid> wrote:
> On 22.9.13 10:21 , upsidedown@downunder.com wrote: >> 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 &lsquo;transaction&rsquo; 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. > > > 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, -- &#9858;&#9859; 100% natural --- news://freenews.netfront.net/ - complaints: news@netfront.net ---
On Sunday, September 22, 2013 9:42:21 AM UTC+2, upsid...@downunder.com wrote:
> 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.
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
On Sunday, September 22, 2013 9:53:34 AM UTC+2, upsid...@downunder.com wrote:
> 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.
I guess 1ms should be ok, it translates to a 5% error in the measurement. Cannot be much higher though Cheers Klaus
On a sunny day (Mon, 23 Sep 2013 00:39:52 -0700 (PDT)) it happened Klaus
Kragelund <klauskvik@hotmail.com> wrote in
<27450a3c-90d9-4358-b0d9-142ba9170baa@googlegroups.com>:

>> 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
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. So it seems to be silly to ask for a guaranteed minimum time, unless you have the perfect network (cable), and even then (collisions in ethernet etc). So you can basically NEVER guarantee a minimum delay. But you could make a good guess as to how often the next nuke plant goes China (Syndrome), and the same way for the probability that a data packet will arrive out of your specified window in time. Hey!
On Fri, 20 Sep 2013 12:49:03 -0700 Jeff Liebermann <jeffl@cruzio.com>
wrote in Message id: <hg9p399sgfllk3knpln2ipcuj303ire6v3@4ax.com>:

>Install an RS-485 loop back adapter in the RS-485 port.
You cannot loop back a half-duplex RS-485 port.
On Monday, September 23, 2013 10:07:10 AM UTC+2, Jan Panteltje wrote:
> On a sunny day (Mon, 23 Sep 2013 00:39:52 -0700 (PDT)) it happened Klaus > > Kragelund <klauskvik@hotmail.com> wrote in > > <27450a3c-90d9-4358-b0d9-142ba9170baa@googlegroups.com>: > > > > >> 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 > > > > 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