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

Groups > comp.arch.embedded > #30383

Re: Linux embedded and direction control of RS485 transceiver

Show all headers | View raw

On 25/03/2021 17:43, upsidedown@downunder.com wrote:
> On Thu, 25 Mar 2021 10:48:31 +0100, David Brown
> <david.brown@hesbynett.no> wrote:
> 
>> On 24/03/2021 20:13, Tauno Voipio wrote:
>>> 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.
>>
>> It would have made sense for Modbus to be standardised on UDP as well.
>> But TCP/IP has advantages over UDP - it is a lot more reliable if you
>> have a complicated network setup, or multiple masters.
>>
>> Omron have a "FINS" protocol that is much the same principle as Modbus,
>> with both UDP and TCP/IP versions, and where I have experience with both
>> versions.
>>
>> UDP is fine on a simple local Ethernet connection, but often has trouble
>> when you have routers, VPN's, gateways, and other complications on the
>> network.  More importantly, perhaps, is that with UDP there is no
>> "connection".  One node sends a request message to another node, that
>> node sends a reply message to the first node.  With TCP/IP, the reply is
>> sent back up the same connection - with UDP, there is no connection.  So
>> there is no way to tell if a reply is to the correct message, or the
>> correct connection, or even the correct node if you have routers
>> involved.  It quickly becomes a reliability mess - it almost always
>> works, and sometimes fails depending on timing details between nodes.
>> Horrible.
> 
> UDP (or raw Ethernet framing) can be handy in redundant systems, if
> you do not care which physical redundant station responds. This is
> true, especially if multicasts / broadcasts are used.
> 

Sure.  I've used UDP for that kind of thing (like broadcasts for
identifying devices on a network).  But it is a pain if you /do/ care
which node responds, because the response is a direct answer to a
request.  You can always add tags or identifiers to your messages, and
perhaps extra messages for acknowledging that each end actually received
the telegram they were supposed to get - and suddenly you find you've
gone to a lot of effort to re-invent a poor man's TCP/IP.

The best solution would be for SCTP to become popular.  I have only read
about it, not used it, but it seems to combine the best features of
TCP/IP with the best features of UDP, while avoiding the worst features
of both.  Reliable transmission (with /your/ choice of reliability vs.
overhead tradeoffs), connections, datagrams.  But Windows does not
support it natively, nor do most standard routers.

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