Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.arch.embedded > #30364

Re: Linux embedded and direction control of RS485 transceiver

Show all headers | View raw

On 24.3.21 19.22, upsidedown@downunder.com wrote:
> On Wed, 24 Mar 2021 18:32:36 +0200, Tauno Voipio
> <tauno.voipio@notused.fi.invalid> wrote:
> 
>>> In the Modbus RTU protocol specification it is required to turn on the
>>> transmitter (set to idle "1" state), wait 3.5 character times, then
>>> send the actual message, then keep the transmitter in active idle
>>> ("1") state for an other 3.5 character times, before turning off the
>>> transmitter, i.e. put the transmitter into tri-state.
>>>
>>> When the transmitter is turned into rtri-state and there are 'fail
>>> safe' pull up/down resistors, the line remains in the idle "1" state
>>> until next transmitter takes over the bus. BTW, the quotes around
>>> 'fail safe' termination is in the actual standard text, at least in
>>> early versions.
>>>
>>> If no passive pull up/down resistors are present on the bus, old
>>> signal reflections and external noise will cause some variable unknown
>>> noise voltages on the bus. However, when the next node turns the
>>> transmitter on for 3.5 character times in idle state, after it the
>>> first start bit of the first character is reliably detected.
>>>
>>> In Modbus RTU, there is at least 3.5 character times idle period
>>> between actual data transmitter between two stations since it is
>>> perfectly legal for station A to have the trailing 3.5 trailing idle
>>> and station B sends 3.5 preamble on simultaneously. Actually there are
>>> 5 (1.5+3.5) character times to turn of the Tx transmitter, since the
>>> Rx uses a 1.5 character time idle period as end of frame marker.
>>>
>>> In half duplex communication with short messages, the latencies
>>> between frames will reduce the throughput considerably. With long
>>> messages, the throughput loss is not significant.
>>
>>
>> The Modbus RTU is rotten - a protocol so badly designed that it
>> is difficult to exceed. Modbus on TCP is no better.
> 
> While the Modbus RTU timing specifications look hard, quite a lot
> slack is possible in practice. Not much problem in point-to-point.
> 
> In a multidrop slave configuration the only critical timing is the
> pause between slave A response before the master sends the next
> command to slave B. Slave B must be able to detect the end of slave A
> transmission, i.e. at least a 1.5 character time  pause. This is easy
> if the slave UART has hardware idle detection.
> 
> If the pause is not properly detected, response from slave A and
> master command to slave B are appended and the CRC doesn't match. This
> will cause a timeout and a retransmission by the master to slave B.
> 
> What is wrong with Modbus/TCP ? It is a nice request/response protocol
> with a fixed size header (including byte count) and variable size
> payload ?


The main problem is TCP. The modbus messages are datagrams by their
very nature, and they should be using UDP/IP instead. TCP explicitly
does *not* preserve record boundaries, but UDP does.

The RTU packet framing is bad: it prevents using any hardware UART
buffering if the timing specifications are to be obeyed. All Modbus
handlers on PCs I have met do not obey the packet timing constraints
except occasionally.

I wrote the first Modbus drivers for MC68332 with 16450 UARTs, and
it was quite a fight to make the system conform fully to the timing
specs.

The framing should be timing-independent, and just depending on special
characters in the data stream, like PPP in HDLC-style framing
(RFC 1662).

-- 

-TV

Back to comp.arch.embedded | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

Linux embedded and direction control of RS485 transceiver pozz <pozzugno@gmail.com> - 2021-03-24 00:06 +0100
  Re: Linux embedded and direction control of RS485 transceiver upsidedown@downunder.com - 2021-03-24 07:28 +0200
    Re: Linux embedded and direction control of RS485 transceiver Don Y <blockedofcourse@foo.invalid> - 2021-03-24 06:17 -0700
      Re: Linux embedded and direction control of RS485 transceiver upsidedown@downunder.com - 2021-03-24 17:49 +0200
        Re: Linux embedded and direction control of RS485 transceiver Tauno Voipio <tauno.voipio@notused.fi.invalid> - 2021-03-24 18:32 +0200
          Re: Linux embedded and direction control of RS485 transceiver upsidedown@downunder.com - 2021-03-24 19:22 +0200
            Re: Linux embedded and direction control of RS485 transceiver David Brown <david.brown@hesbynett.no> - 2021-03-24 19:44 +0100
              Re: Linux embedded and direction control of RS485 transceiver upsidedown@downunder.com - 2021-03-25 07:34 +0200
              Re: Linux embedded and direction control of RS485 transceiver upsidedown@downunder.com - 2021-03-25 07:47 +0200
            Re: Linux embedded and direction control of RS485 transceiver Tauno Voipio <tauno.voipio@notused.fi.invalid> - 2021-03-24 21:13 +0200
              Re: Linux embedded and direction control of RS485 transceiver upsidedown@downunder.com - 2021-03-25 07:39 +0200
              Re: Linux embedded and direction control of RS485 transceiver David Brown <david.brown@hesbynett.no> - 2021-03-25 10:48 +0100
                Re: Linux embedded and direction control of RS485 transceiver Tauno Voipio <tauno.voipio@notused.fi.invalid> - 2021-03-25 16:33 +0200
                Re: Linux embedded and direction control of RS485 transceiver Grant Edwards <invalid@invalid.invalid> - 2021-03-25 14:49 +0000
                Re: Linux embedded and direction control of RS485 transceiver upsidedown@downunder.com - 2021-03-25 18:43 +0200
                Re: Linux embedded and direction control of RS485 transceiver David Brown <david.brown@hesbynett.no> - 2021-03-26 09:47 +0100
        Re: Linux embedded and direction control of RS485 transceiver Don Y <blockedofcourse@foo.invalid> - 2021-03-24 14:30 -0700
  Re: Linux embedded and direction control of RS485 transceiver dalai lamah <antonio12358@hotmail.com> - 2021-03-24 11:48 +0100
    Re: Linux embedded and direction control of RS485 transceiver pozz <pozzugno@gmail.com> - 2021-03-25 00:23 +0100
  Re: Linux embedded and direction control of RS485 transceiver "A.P.Richelieu" <aprichelieu@gmail.com> - 2021-05-09 13:24 +0200
    Re: Linux embedded and direction control of RS485 transceiver Uwe Bonnes <bon@hertz.ikp.physik.tu-darmstadt.de> - 2021-05-09 12:01 +0000
    Re: Linux embedded and direction control of RS485 transceiver pozz <pozzugno@gmail.com> - 2021-05-10 09:46 +0200

csiph-web