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

Groups > comp.arch.embedded > #28901

Re: Multidrop bus on Windows

Show all headers | View raw

On 04/10/2019 11:44, upsidedown@downunder.com wrote:
> On Fri, 4 Oct 2019 08:54:18 +0200, David Brown
> <david.brown@hesbynett.no> wrote:
> 
>> On 03/10/2019 08:10, upsidedown@downunder.com wrote:
>>> On Wed, 2 Oct 2019 22:16:36 -0700 (PDT), Rick C 
>>> <gnuarm.deletethisbit@gmail.com> wrote:
>>>
>>>> On Thursday, October 3, 2019 at 12:39:47 AM UTC-4,
>>>> upsid...@downunder.com wrote:
>>>>> On Wed, 2 Oct 2019 19:06:22 -0700 (PDT), Rick C 
>>>>> <gnuarm.deletethisbit@gmail.com> wrote:
>>>>>
>>> There are dozens PLC serial protocols that supports multidrop and
>>> the timing issue may effect them all.
>>>
>>
>> I have worked with several different PLC serial protocols.  Modbus RTU
>> is the only one I know of that does not have a specific start character
>> in the telegrams - for all others, "noise" characters at the start of a
>> telegram will be happily ignored.
>>
>>> The most common PLC serial protocol these days is Modbus RTU. While
>>> it has some nasty timing requirements, the master side can take some 
>>> slack in timing, but this doesn't apply to Modbus slave, which needs 
>>> to handle timing correctly.
>>>
>>
>> That is not true.  If you want to be able to communicate with the
>> fussiest of devices on either side, you need to match the timings.  That
>> means the master can't have breaks inside a telegram, or send out a new
>> request too soon before the end of the last reply.  (Those are the only
>> two timings of relevance to Modbus RTU.)  Equally, most Modbus masters
>> and slaves are quite relaxed about their checks and in practice lax
>> timings on a slave will not often be a problem.  I simply don't see the
>> asymmetry you mention.
> 
> Apart for reduced troughput, the master can safely insert a crude
> delay (such as 10 ms OS tick) before sending out the request, so there
> is at least a 3.5 character time silent period ahead of the request.

There are no timing requirements for when a master sends a request, or
for when the slave replies, other than the minimum 3.5 character delay.
 These pauses are not part of the protocol specification.

> This will ensure that all slaves can reliably detect a pause between
> frames (even if not addressed to your slave). You could even skip the
> extra delay when sending multiple requests to the same slave, 

You can't skip the 3.5 character delay - whether you are sending to the
same or a different device.  Any delay beyond that is entirely up to the
device sending.  (This is the same for masters and slaves.)

> but it
> definitively needed when first accessing one slave and then send next
> request to a new slave, so that the new slave will reliably separate
> the response from the old slave and the next request addressed to your
> slave.
> 
> After sending the request, the master should disable the transmitter
> and let the fail-safe termination drive the bus into idle state. There
> is a timing window up to 70 bit times (3.5 master character times +
> 3.5 character slave preamble) for the master to go from Tx to Rx. In
> practice, this window may have to be limited to 10-20 bit times for
> more or less standard slave implementations.

Slaves are not allowed to reply before the 3.5 character time break.
There is no protocol-specified maximum delay time.

> 
> OTOH the master Tx should not be turned off more than 1 bit time
> before the end of last stop bit of last character, so that the last
> stop bit will actively drive the line to mark "1" state and then let
> the fail-safe termination passively take over the idle "1" state.

That is obvious.

> 
> On the slave side, each slave must be able to detect when a response
> from an other slave has ended and when the master is sending a new
> request to you. This requires accurate timing. Otherwise the slave
> will concatenate the two requests and the CRC will hopefully fail and
> after timeout, the master have to do a resend.
> 

It does not need to be done by accurate time - often approximate timing
is sufficient.  And slaves can happily read and check telegrams that are
not addressed to them (such as replies to the master) and use that for
synchronisation.

> 
> Agreed that implementing  Modbus RTU timing accurately is hard,
> especially at high speeds.

It can be a bit fiddly, and would be easier with a concrete
start-of-telegram character, but it is not /that/ hard.

> With the QUICC I/O coprocessor (on MC68360
> and some PPC), this can be done relatively accurately.

People do it all the time on all sorts of microcontrollers.  There is no
need for overkill on the processor power.  These might be good choices
of processor for other reasons, but for common baud rates (19.2 kbaud is
standard, above 115.2 kbaud is very rare) you can work happily with a
little 8-bit microcontroller.

>  Multiple
> segments can be chained and sent out in sequence and when last segment
> is sent, this will then interrupt the main processors. In the first
> segment send 4 dummy characters with Tx driver disabled, in the second
> send actual message with Tx ON and in the third segment send 3 dummy
> characters with Tx OFF. On Rx, set the Idle timeout to 2 character
> times. 
> 
> This will produce a 4 character preamble with 3 character trailing and
> 2 character Rx end detection, compared to 3.5 character preample, 3.5
> trailer and Rx 1.5 pause detection as specified in the standard.
>  

I don't know if I have ever heard of a Modbus implementation being done
in such a complex manner.

You turn on your driver, send out the telegram, and turn off the driver
again.  If you are trying to do this on an ancient Windows system, it is
a bit of a pain - fortunately, that hasn't been needed for decades.
When the slave receives the telegram, it interprets it, figures out the
reply telegram, waits if necessary (and who cares if it is 3.5 character
times or 10 ms?), turns on its driver, sends out the telegram, turns of
the driver.

There is no need to make a mountain out of a molehill, or use high-end
communication controllers that are designed for things like Profibus
(with 12 MBaud on RS-485, and hideously complicated timing and processing).

>> It /is/ the case that an 0xff character could be the start of a Modbus
>> RTU telegram, and therefore you need to be careful about using one as an
>> extra interrupt-generator for switching the RS-485 bus.
>>
> 

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

Thread

Multidrop bus on Windows pozz <pozzugno@gmail.com> - 2019-10-01 16:02 +0200
  Re: Multidrop bus on Windows Dave Nadler <drn@nadler.com> - 2019-10-01 08:01 -0700
    Re: Multidrop bus on Windows pozz <pozzugno@gmail.com> - 2019-10-02 09:04 +0200
      Re: Multidrop bus on Windows upsidedown@downunder.com - 2019-10-02 11:33 +0300
        Re: Multidrop bus on Windows David Brown <david.brown@hesbynett.no> - 2019-10-02 12:12 +0200
          Re: Multidrop bus on Windows Dave Nadler <drn@nadler.com> - 2019-10-02 04:59 -0700
          Re: Multidrop bus on Windows upsidedown@downunder.com - 2019-10-03 01:11 +0300
            Re: Multidrop bus on Windows Rick C <gnuarm.deletethisbit@gmail.com> - 2019-10-02 19:06 -0700
              Re: Multidrop bus on Windows upsidedown@downunder.com - 2019-10-03 07:39 +0300
                Re: Multidrop bus on Windows Rick C <gnuarm.deletethisbit@gmail.com> - 2019-10-02 22:16 -0700
                Re: Multidrop bus on Windows upsidedown@downunder.com - 2019-10-03 09:10 +0300
                Re: Multidrop bus on Windows Rick C <gnuarm.deletethisbit@gmail.com> - 2019-10-03 07:53 -0700
                Re: Multidrop bus on Windows David Brown <david.brown@hesbynett.no> - 2019-10-04 08:54 +0200
                Re: Multidrop bus on Windows upsidedown@downunder.com - 2019-10-04 12:44 +0300
                Re: Multidrop bus on Windows David Brown <david.brown@hesbynett.no> - 2019-10-04 13:00 +0200
                Re: Multidrop bus on Windows upsidedown@downunder.com - 2019-10-04 15:54 +0300
                Re: Multidrop bus on Windows David Brown <david.brown@hesbynett.no> - 2019-10-04 15:13 +0200
                Re: Multidrop bus on Windows upsidedown@downunder.com - 2019-10-04 16:40 +0300
                Re: Multidrop bus on Windows David Brown <david.brown@hesbynett.no> - 2019-10-04 16:49 +0200
                Re: Multidrop bus on Windows Grant Edwards <invalid@invalid.invalid> - 2019-10-04 16:14 +0000
                Re: Multidrop bus on Windows upsidedown@downunder.com - 2019-10-05 14:24 +0300
              Re: Multidrop bus on Windows David Brown <david.brown@hesbynett.no> - 2019-10-03 09:35 +0200
                Re: Multidrop bus on Windows Grant Edwards <invalid@invalid.invalid> - 2019-10-03 14:08 +0000
                Re: Multidrop bus on Windows David Brown <david.brown@hesbynett.no> - 2019-10-04 08:59 +0200
                Re: Multidrop bus on Windows Rick C <gnuarm.deletethisbit@gmail.com> - 2019-10-03 08:04 -0700
                Re: Multidrop bus on Windows David Brown <david.brown@hesbynett.no> - 2019-10-04 09:43 +0200
                Re: Multidrop bus on Windows Rick C <gnuarm.deletethisbit@gmail.com> - 2019-10-04 03:16 -0700
                Re: Multidrop bus on Windows David Brown <david.brown@hesbynett.no> - 2019-10-04 13:10 +0200
              Re: Multidrop bus on Windows Stef <stef33d@yahooI-N-V-A-L-I-D.com.invalid> - 2019-10-03 22:12 +0200
            Re: Multidrop bus on Windows David Brown <david.brown@hesbynett.no> - 2019-10-03 09:19 +0200
              Re: Multidrop bus on Windows upsidedown@downunder.com - 2019-10-03 10:59 +0300
                Re: Multidrop bus on Windows David Brown <david.brown@hesbynett.no> - 2019-10-03 11:12 +0200
                Re: Multidrop bus on Windows upsidedown@downunder.com - 2019-10-03 20:15 +0300
                Re: Multidrop bus on Windows David Brown <david.brown@hesbynett.no> - 2019-10-04 09:45 +0200
                Re: Multidrop bus on Windows upsidedown@downunder.com - 2019-10-04 12:58 +0300
              Re: Multidrop bus on Windows Grant Edwards <invalid@invalid.invalid> - 2019-10-03 14:04 +0000
                Re: Multidrop bus on Windows David Brown <david.brown@hesbynett.no> - 2019-10-04 09:47 +0200
  Re: Multidrop bus on Windows David Brown <david.brown@hesbynett.no> - 2019-10-01 20:44 +0200
    Re: Multidrop bus on Windows pozz <pozzugno@gmail.com> - 2019-10-02 09:03 +0200
      Re: Multidrop bus on Windows David Brown <david.brown@hesbynett.no> - 2019-10-02 12:14 +0200

csiph-web