Reply by pozz May 10, 20212021-05-10
Il 09/05/2021 13:24, A.P.Richelieu ha scritto:
> Den 2021-03-24 kl. 00:06, skrev pozz: >> I have an half-duplex RS485 bus with 10-20 different nodes. Some of >> them are 8-bit MCU based, one of them could be Linux embedded. >> >> It's half-duplex, so it's important for the transmitter node to >> disable the driver as soon as the last transmitted bit is shifted out. >> >> Many small low-cost MCU has interrupt on transmission complete, so the >> delay of disabling the driver is usually on the order of microseconds. >> >> Some new Cortex-M MCUs have an automatic control of external RS485 >> transceiver, so the delay is really zero. >> >> What happens in Linux embedded systems? Many of them are based on NXP >> i.MX CPUs and it seems they aren't able to control the RS485 direction >> in hardware, but some code is needed. This approach could increase the >> delay of disabling the driver in the order of milliseconds. >> >> Is it possible that a powerful CPU isn't able to control RS485 driver >> in hardware? > > Atmel (now Microchip) ARM products has a serial port which supports > handling the RS-485 direction in hardware. It also has an interrupt > which is triggered after a programmable delay has occured without any > receied characters.
I know SAM D family MCUs has a nice SERCOM peripheral with RS485 direction in hardware. But my discussion was for Linux embedded, so MPUs (Cortex-A).
Reply by Uwe Bonnes May 9, 20212021-05-09
A.P.Richelieu <aprichelieu@gmail.com> wrote:
 
> Atmel (now Microchip) ARM products has a serial port which supports > handling the RS-485 direction in hardware. It also has an interrupt > which is triggered after a programmable delay has occured without any > receied characters. >
Similar for recent STM32 U(s)arts. -- Uwe Bonnes bon@elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 1623569 ------- Fax. 06151 1623305 --------- (Phone also available during "mobile work")
Reply by A.P.Richelieu May 9, 20212021-05-09
Den 2021-03-24 kl. 00:06, skrev pozz:
> I have an half-duplex RS485 bus with 10-20 different nodes. Some of them > are 8-bit MCU based, one of them could be Linux embedded. > > It's half-duplex, so it's important for the transmitter node to disable > the driver as soon as the last transmitted bit is shifted out. > > Many small low-cost MCU has interrupt on transmission complete, so the > delay of disabling the driver is usually on the order of microseconds. > > Some new Cortex-M MCUs have an automatic control of external RS485 > transceiver, so the delay is really zero. > > What happens in Linux embedded systems? Many of them are based on NXP > i.MX CPUs and it seems they aren't able to control the RS485 direction > in hardware, but some code is needed. This approach could increase the > delay of disabling the driver in the order of milliseconds. > > Is it possible that a powerful CPU isn't able to control RS485 driver in > hardware?
Atmel (now Microchip) ARM products has a serial port which supports handling the RS-485 direction in hardware. It also has an interrupt which is triggered after a programmable delay has occured without any receied characters.
Reply by David Brown March 26, 20212021-03-26
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&nbsp; 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.
Reply by March 25, 20212021-03-25
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&#4294967295; 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.
Reply by Grant Edwards March 25, 20212021-03-25
On 2021-03-25, Tauno Voipio <tauno.voipio@notused.fi.invalid> wrote:
>>> >>> The framing should be timing-independent, and just depending on special >>> characters in the data stream, like PPP in HDLC-style framing >>> (RFC 1662). >> >> Yes, within limits - it's important to have timeouts of some sort so >> that you can re-synchronise in the case of lost characters. But the >> timeouts should be large enough so that they are not an inconvenience >> for normal handling. > > > Right - and the protocol should make it easy to grab frame boundaries, > as PPP flags (0x7e, gullwing) do.
And Modbus ASCII. ;)
Reply by Tauno Voipio March 25, 20212021-03-25
On 25.3.21 11.48, David Brown 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&nbsp; 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. > > So while we use UDP FINS between nodes directly on the same network > segment, we /always/ use TCP/IP for routed traffic, VPN traffic, or > anything else "complicated". > > For Modbus, I have used Modbus/TCP on several systems, including > networks with large numbers of nodes. The overhead of TCP/IP > (acknowledge packets) usually has negligible cost, and it is not > difficult to handle the streaming nature of the protocol. > >> >> 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. > > That's a different matter - and I agree. > >> >> 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). >> > > Yes, within limits - it's important to have timeouts of some sort so > that you can re-synchronise in the case of lost characters. But the > timeouts should be large enough so that they are not an inconvenience > for normal handling.
Right - and the protocol should make it easy to grab frame boundaries, as PPP flags (0x7e, gullwing) do. -- -TV
Reply by David Brown March 25, 20212021-03-25
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&nbsp; 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. So while we use UDP FINS between nodes directly on the same network segment, we /always/ use TCP/IP for routed traffic, VPN traffic, or anything else "complicated". For Modbus, I have used Modbus/TCP on several systems, including networks with large numbers of nodes. The overhead of TCP/IP (acknowledge packets) usually has negligible cost, and it is not difficult to handle the streaming nature of the protocol.
> > 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.
That's a different matter - and I agree.
> > 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). >
Yes, within limits - it's important to have timeouts of some sort so that you can re-synchronise in the case of lost characters. But the timeouts should be large enough so that they are not an inconvenience for normal handling.
Reply by March 25, 20212021-03-25
On Wed, 24 Mar 2021 19:44:39 +0100, David Brown
<david.brown@hesbynett.no> wrote:

>On 24/03/2021 18:22, upsidedown@downunder.com wrote: >> On Wed, 24 Mar 2021 18:32:36 +0200, Tauno Voipio >> <tauno.voipio@notused.fi.invalid> wrote: >> > >>> The Modbus RTU is rotten - a protocol so badly designed that it >>> is difficult to exceed. Modbus on TCP is no better. >> >> 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 ? >> >> > >Modbus/TCP has a bit of redundancy in its headers, and some limits that >exist only because of its heritage (like the maximum number of registers >you are allowed to transfer at a time being 127, and the highest >register address being 9999). If you are writing your own server code, >you can easily ignore them, but the master side has to know that the >server supports them. > >There are a number of underspecified issues, such as endianness >(especially for multi-register items) and atomicity of transfers. And >there is the silly mixup of register numbers (1 to 10000) and addresses >(0 to 9999). Then there are a whole bunch of rarely used function codes >that made little sense for Modbus RTU, and no sense at all when you have >Ethernet.
Modbus RTU registers are big endian Modbus RTU did not support 32 bit integers or floats. However, many vendors needed to transfer 32 bit entities, so they used their own format for these double register pairs. The vendors have carried these formats also to Modbus/TCP.
Reply by March 25, 20212021-03-25
On Wed, 24 Mar 2021 21:13:14 +0200, Tauno Voipio
<tauno.voipio@notused.fi.invalid> 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.
Quite a few vendors support also Modbus/UDP.