On 04/10/2019 14:54, upsidedown@downunder.com wrote:
> On Fri, 4 Oct 2019 13:00:30 +0200, David Brown
> <david.brown@hesbynett.no> wrote:
>
>> 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:
>> 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.
>
> Of course not. A fixed delay of say 10 ms is sufficient to produce
> _at_least_ a 3.5 character pause.at speeds above 9600 bit/s. While in
> principle, a single 10 ms pause would be sufficient also at 4800
> bit/s, the OS delay is not synchronized with the character stream.
>
So you put in two ticks of pause, giving you 10-20 ms delay. Or you
synchronise, or use some other timer system. Or you accept that if you
need low-latency, low-jitter, high speed communications, then Modbus RTU
was not the ideal choice.
>>
>>> 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.)
>
> In practice, most slaves after sending the response go _immediately_
> into Rx mode, so the master could send the next request immediately.
> This works very well in practice.
It is likely that a slave will go into receive mode quite quickly after
finishing transmission - agreed. I don't know about you, but when I
write code for a Modbus master, I still have a brief delay before
sending the next telegram.
>
> Modbus point to point connections work well, without observing
> accurate timing.
>
Yes, that usually makes things very simple.
>>
>>> 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.
>
> How many of those thousands of different Modbus slave devices actually
> follow this ?
>
A good many, I expect, have some delay. If nothing else, it is common
to get in the telegram, crc-check it, parse it, the figure out how to
handle it. In many cases this can take time (though in some cases it is
just a read or write to memory). A good slave implementation will
probably create the reply telegram in a memory buffer before starting
the reply at all - you want to make sure your reads and writes are
atomic, and mess with creating replies on the fly. All this will
naturally cause a delay on the small, cheap devices usually used on
Modbus slaves.
>
>>> 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.
>
> If the master sends the next request within 1.5 character times after
> the previous slave response has ended, all slaves will combine the
> previous response and next request to a single frame.
>
No, they won't - not if they parse and check the telegrams as they come
in (as some slaves do).
Look, if you are going to use a standardised protocol, follow the
standard. Assume that any other devices on the bus also follow the
standard. Otherwise the whole exercise is pointless.
>
>>> 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.
>
> With any half duplex protocols, watching for the latencies is critical
> to get a reasonable scan rate with multiple slaves. I once had nearly
> one hundred actuators on each 230k lines (due to slew rate limited 250
> kbit/s transceiver chips on both master as well as slave) to get a few
> cycles every second. The processor also handled generating controls
> for all these actuators. After trimming out most latencies, it become
> obvious that hundreds of amps drawn by the actuators at once would
> kill the power supplies, so the control signals had to be
> staggered:-).
In my experience it is usually easier to have tight control of your
latencies with a small microcontroller than with a big one. My comment
still stands - people do this all the time, on small microcontrollers.
>
>>> 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.
>
> While some code is required on QUICC to set up the system, sending a
> master frame is very simple. Just update the actual length to segment
> 2 and enable transmission. The next time the master program needs to
> react is when the 2 character time idle timeout of the slave response
> has expired.
>
>>
>> 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.
>
> Why would anyone try to do such tricks on brain dead IBM PC hardware.
Look at the title of the thread.
>
>> 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.
>
> For multidrop master, the critical thing is when the transmitter is
> turned off. For a slave, the how easily the 1.5 character (or more)
> time pause is detected.
>
>> 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).
>
> Profibus-DP at 12 Mbit/s is nasty even electrically in a multidrop
> system with frequency compensated T-connectors :-). At 1.5 Mbit/s even
> barbed wire works reasonably.
>
> Agreed that the timing requirement is nasty, but would be quite hard
> to achieve for instance 4 ms bus cycle times with multiple slaves in
> software only.
>
Agreed.