Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.arch.embedded > #28904
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Newsgroups | comp.arch.embedded |
| Subject | Re: Multidrop bus on Windows |
| Date | 2019-10-04 15:13 +0200 |
| Organization | A noiseless patient Spider |
| Message-ID | <qn7ghk$jrb$1@dont-email.me> (permalink) |
| References | (7 earlier) <nk2bpehdda86i8pqirfajdc0v71stpvkto@4ax.com> <qn6qaq$vq2$1@dont-email.me> <972epepn3vqd4kgnrn0cr05omkbv9ni4v0@4ax.com> <qn78of$9fr$1@dont-email.me> <9gcepe90p4oh26u1e8rjklir08ehs1703b@4ax.com> |
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.
Back to comp.arch.embedded | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll 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