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

Groups > comp.arch.embedded > #28869 > unrolled thread

Multidrop bus on Windows

Back to article view | Back to comp.arch.embedded

Contents

  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

Page 1 of 2  [1] 2  Next page →

#28869 — Multidrop bus on Windows

I often work on embedded firmware for MCUs connected by a multidrop 
master/slave RS485 bus.

Moreover I try to compile the same code with mingw compiler, simulating 
the hw. Of course, I simulate the serial bus connection (UART) by using 
a COM port on Windows.
This allows me to speed-up testing, debugging and so on.

So I can launch many simulators of the same device or different devices. 
If they are two, I can use null-modem emulator (such as com0com) to make 
a point-to-point connection between the two devices.

What I'm trying to do is to launch three o more device simulators, each 
opening a virtual serial port, and let them talk together as they are on 
a real RS485 bus.

What I'm searching is a software that retransmit all data received on 
one serial port to all other serial ports under control.

Device 1 <-> COM11 <- null-modem emulator -> COM12
Device 2 <-> COM13 <- null-modem emulator -> COM14
Device 3 <-> COM15 <- null-modem emulator -> COM16

This bus simulator should open COM12, COM14 and COM16 and retransmits 
all data received on one port to all other ports.

I know I can write this myself, however I'm sure someone already wrote 
something similar to reuse.

[toc] | [next] | [standalone]

#28870

On Tuesday, October 1, 2019 at 10:02:20 AM UTC-4, pozz wrote:
> I often work on embedded firmware for MCUs connected by a multidrop 
> master/slave RS485 bus.
> 
> Moreover I try to compile the same code with mingw compiler, simulating 
> the hw. Of course, I simulate the serial bus connection (UART) by using 
> a COM port on Windows.
> This allows me to speed-up testing, debugging and so on.
> 
> So I can launch many simulators of the same device or different devices. 
> If they are two, I can use null-modem emulator (such as com0com) to make 
> a point-to-point connection between the two devices.
> 
> What I'm trying to do is to launch three o more device simulators, each 
> opening a virtual serial port, and let them talk together as they are on 
> a real RS485 bus.
> 
> What I'm searching is a software that retransmit all data received on 
> one serial port to all other serial ports under control.
> 
> Device 1 <-> COM11 <- null-modem emulator -> COM12
> Device 2 <-> COM13 <- null-modem emulator -> COM14
> Device 3 <-> COM15 <- null-modem emulator -> COM16
> 
> This bus simulator should open COM12, COM14 and COM16 and retransmits 
> all data received on one port to all other ports.
> 
> I know I can write this myself, however I'm sure someone already wrote 
> something similar to reuse.

Why don't you stub the RS485 comms with some kind of network pub-sub layer?
Perhaps using IP-multicast?
I don't know offhand of a straight-forward (non-commercial) pub sub library,
but probably there are a few out there... Maybe DBus?
I wouldn't use serial comms for simulation.
Hope that helps,
Best Regards, Dave

[toc] | [prev] | [next] | [standalone]

#28873

Il 01/10/2019 17:01, Dave Nadler ha scritto:
> On Tuesday, October 1, 2019 at 10:02:20 AM UTC-4, pozz wrote:
>> I often work on embedded firmware for MCUs connected by a multidrop
>> master/slave RS485 bus.
>>
>> Moreover I try to compile the same code with mingw compiler, simulating
>> the hw. Of course, I simulate the serial bus connection (UART) by using
>> a COM port on Windows.
>> This allows me to speed-up testing, debugging and so on.
>>
>> So I can launch many simulators of the same device or different devices.
>> If they are two, I can use null-modem emulator (such as com0com) to make
>> a point-to-point connection between the two devices.
>>
>> What I'm trying to do is to launch three o more device simulators, each
>> opening a virtual serial port, and let them talk together as they are on
>> a real RS485 bus.
>>
>> What I'm searching is a software that retransmit all data received on
>> one serial port to all other serial ports under control.
>>
>> Device 1 <-> COM11 <- null-modem emulator -> COM12
>> Device 2 <-> COM13 <- null-modem emulator -> COM14
>> Device 3 <-> COM15 <- null-modem emulator -> COM16
>>
>> This bus simulator should open COM12, COM14 and COM16 and retransmits
>> all data received on one port to all other ports.
>>
>> I know I can write this myself, however I'm sure someone already wrote
>> something similar to reuse.
> 
> Why don't you stub the RS485 comms with some kind of network pub-sub layer?
> Perhaps using IP-multicast?
> I don't know offhand of a straight-forward (non-commercial) pub sub library,
> but probably there are a few out there... Maybe DBus?
> I wouldn't use serial comms for simulation.

I sometimes need to connect a simulator to a real device, so I need to 
use COM port.

[toc] | [prev] | [next] | [standalone]

#28874

On Wed, 2 Oct 2019 09:04:31 +0200, pozz <pozzugno@gmail.com> wrote:

>Il 01/10/2019 17:01, Dave Nadler ha scritto:
>> On Tuesday, October 1, 2019 at 10:02:20 AM UTC-4, pozz wrote:
>>> I often work on embedded firmware for MCUs connected by a multidrop
>>> master/slave RS485 bus.
>>>
>>> Moreover I try to compile the same code with mingw compiler, simulating
>>> the hw. Of course, I simulate the serial bus connection (UART) by using
>>> a COM port on Windows.
>>> This allows me to speed-up testing, debugging and so on.
>>>
>>> So I can launch many simulators of the same device or different devices.
>>> If they are two, I can use null-modem emulator (such as com0com) to make
>>> a point-to-point connection between the two devices.
>>>
>>> What I'm trying to do is to launch three o more device simulators, each
>>> opening a virtual serial port, and let them talk together as they are on
>>> a real RS485 bus.
>>>
>>> What I'm searching is a software that retransmit all data received on
>>> one serial port to all other serial ports under control.
>>>
>>> Device 1 <-> COM11 <- null-modem emulator -> COM12
>>> Device 2 <-> COM13 <- null-modem emulator -> COM14
>>> Device 3 <-> COM15 <- null-modem emulator -> COM16
>>>
>>> This bus simulator should open COM12, COM14 and COM16 and retransmits
>>> all data received on one port to all other ports.
>>>
>>> I know I can write this myself, however I'm sure someone already wrote
>>> something similar to reuse.
>> 
>> Why don't you stub the RS485 comms with some kind of network pub-sub layer?
>> Perhaps using IP-multicast?
>> I don't know offhand of a straight-forward (non-commercial) pub sub library,
>> but probably there are a few out there... Maybe DBus?
>> I wouldn't use serial comms for simulation.
>
>I sometimes need to connect a simulator to a real device, so I need to 
>use COM port.

If you intend to use a typical 14500 compatible UART on a PC, there
are issues with Tx/Rx switching in half duplex multidrop RS-485.

[toc] | [prev] | [next] | [standalone]

#28875

On 02/10/2019 10:33, upsidedown@downunder.com wrote:
> On Wed, 2 Oct 2019 09:04:31 +0200, pozz <pozzugno@gmail.com> wrote:
> 
<snip>
>> I sometimes need to connect a simulator to a real device, so I need to 
>> use COM port.
> 
> If you intend to use a typical 14500 compatible UART on a PC, there
> are issues with Tx/Rx switching in half duplex multidrop RS-485.
> 

It is a /long/ time since I have used "real" UART devices on a PC.  I
almost invariably use FTDI chip's USB UART cables and converters.  These
have no problem with RS-485 direction switching - I've run them at 3 MB.
 (As usual, life is much easier with Linux than with Windows for such
things - in particular, you have no messing about with drivers, and no
run-away comms port numbering.)

[toc] | [prev] | [next] | [standalone]

#28877

On Wednesday, October 2, 2019 at 6:12:10 AM UTC-4, David Brown wrote:
> ... It is a /long/ time since I have used "real" UART devices on a PC.  I
> almost invariably use FTDI chip's USB UART cables and converters.  These
> have no problem with RS-485 direction switching - I've run them at 3 MB.
>  (As usual, life is much easier with Linux than with Windows for such
> things - in particular, you have no messing about with drivers, and no
> run-away comms port numbering.)

Also, Exar make a USB-RS485 converter and drivers; I used these some years
back to interface test code to a 485 bus.

[toc] | [prev] | [next] | [standalone]

#28878

On Wed, 2 Oct 2019 12:12:06 +0200, David Brown
<david.brown@hesbynett.no> wrote:

>On 02/10/2019 10:33, upsidedown@downunder.com wrote:
>> On Wed, 2 Oct 2019 09:04:31 +0200, pozz <pozzugno@gmail.com> wrote:
>> 
><snip>
>>> I sometimes need to connect a simulator to a real device, so I need to 
>>> use COM port.
>> 
>> If you intend to use a typical 14500 compatible UART on a PC, there
>> are issues with Tx/Rx switching in half duplex multidrop RS-485.

Should be 16450. Those do not have an interrupt when the last stop bit
of the last character has actually shifted out of the UART shift
register, only when he last character has been moved from the Tx FIFO
to the shift register. It still takes a full character time before the
character has actually been shifted out and the transmitter can be
disabled and set to tri-state.  

Some implementations put the Tx into tri-state some bit times too
early and the last character is corrupted, typically having the last
bits (most significant bits set eg. 0xFx, 0xEx etc due to 'fail safe'
termination) . Others turn off the Tx too late, when the opposite end
has already started to send the reply and the first character is lost
or the whole message is garbled (start bit missing).
 
>It is a /long/ time since I have used "real" UART devices on a PC.  I
>almost invariably use FTDI chip's USB UART cables and converters.  These
>have no problem with RS-485 direction switching - I've run them at 3 MB.
> (As usual, life is much easier with Linux than with Windows for such
>things - in particular, you have no messing about with drivers, and no
>run-away comms port numbering.)

I once tried some USB to serial converters, one crashed the Windows.

An other mixed the enumeration when two or more such converters were
plugged into USB ports in different order, sending communication to
wrong serial lines with potentially lethal consequences.

These days I prefer ethernet to serial converters with proper Rx/Tx
hardware switching. These work fine and you get 100 m range and
galvanic isolation for 'free'.

Some early ethernet to serial converters waited  a looong time before
forwarding the last Rx character to ethernet. Some had adjustable time
settings with minimum settings of 10 ms :-(. This did make these
devices useless for high speed half duplex traffic. Modern versions
forwards the last character after one or few character time idle
period detected on the Rx serial line.

[toc] | [prev] | [next] | [standalone]

#28879

On Wednesday, October 2, 2019 at 6:11:58 PM UTC-4, upsid...@downunder.com wrote:
> On Wed, 2 Oct 2019 12:12:06 +0200, David Brown
> <david.brown@hesbynett.no> wrote:
> 
> >On 02/10/2019 10:33, upsidedown@downunder.com wrote:
> >> On Wed, 2 Oct 2019 09:04:31 +0200, pozz <pozzugno@gmail.com> wrote:
> >> 
> ><snip>
> >>> I sometimes need to connect a simulator to a real device, so I need to 
> >>> use COM port.
> >> 
> >> If you intend to use a typical 14500 compatible UART on a PC, there
> >> are issues with Tx/Rx switching in half duplex multidrop RS-485.
> 
> Should be 16450. Those do not have an interrupt when the last stop bit
> of the last character has actually shifted out of the UART shift
> register, only when he last character has been moved from the Tx FIFO
> to the shift register. It still takes a full character time before the
> character has actually been shifted out and the transmitter can be
> disabled and set to tri-state.  
> 
> Some implementations put the Tx into tri-state some bit times too
> early and the last character is corrupted, typically having the last
> bits (most significant bits set eg. 0xFx, 0xEx etc due to 'fail safe'
> termination) . Others turn off the Tx too late, when the opposite end
> has already started to send the reply and the first character is lost
> or the whole message is garbled (start bit missing).

I'm surprised no one thought of dealing with this issue by appending an optional char of all ones to the end of the message and adjusting the protocol to simply ignore this single char.  Treat it as optional and if the start bit is lost, no problem.  If it is received it gets tossed, no problem.  

I recall working on a system that had this problem.  I don't recall how we dealt with it.  I seem to recall digging into the interrupt handler but that was over 30 years ago.  With the info I gained I did write a driver for the timer interrupt and the counter that drove the speaker.  I would read an 8 bit DAC sample and use it to pulse width modulate the speaker pulse train.  The timer interrupt was used to time the 8 kHz sample rate if I remember correctly.  It was seriously crude, but in those days a "multimedia" package was pretty pricey and many government computers didn't have it even if they needed it.  This was a cheap way to play modem sounds for educational purposes on whatever PCs they had handy.  I had actually done this for my own amusement using a modem sound as my test file.  When one of the managers heard modem sounds coming from the lab he had to see how that was happening.  He knew only a couple of PCs in the office had multimedia kits installed.  He was amazed.  lol  It's so simple, I guess some people just don't think about stuff like that.  For me it was play. 


> >It is a /long/ time since I have used "real" UART devices on a PC.  I
> >almost invariably use FTDI chip's USB UART cables and converters.  These
> >have no problem with RS-485 direction switching - I've run them at 3 MB.
> > (As usual, life is much easier with Linux than with Windows for such
> >things - in particular, you have no messing about with drivers, and no
> >run-away comms port numbering.)
> 
> I once tried some USB to serial converters, one crashed the Windows.

The Chinese brands don't have great drivers.  The Chinese fakes of quality brands are pretty crap.  I don't know of any that are so bad they crap out the PC though. 


> An other mixed the enumeration when two or more such converters were
> plugged into USB ports in different order, sending communication to
> wrong serial lines with potentially lethal consequences.

Probably not the sequence, but rather the USB port.  When you plug a serial device into a USB port it gets a COM port number.  That number is now "locked" (in a soft way) and won't be reused unless you force it.  Plug the same serial device in another USB port and it will get a new COM port number.  The good point is you can select a COM port number without going into the setup by picking the USB port you plug it into.  The bad point is you need to remember which COM port is associated with which USB port.  

If you want, you can even pick an COM port number overriding any "in use" COM numbers as long as you know they aren't being used by hardware.  Not sure why, but Windows seems to want to reserve some low COM port numbers to start. 


> These days I prefer ethernet to serial converters with proper Rx/Tx
> hardware switching. These work fine and you get 100 m range and
> galvanic isolation for 'free'.

It's great if your device has an Ethernet port.  I don't know what it takes to set up the connection, but I know it was a bear to get two Windows 10 PCs to talk to each other over Ethernet, things like fill sharing.  Years before I use a web site WOW.com (World of Windows networking) or maybe it was WOWN.com, I forget.  It had the straight skinny on getting Win2k working and made it easy.  After Win2k MS seems to have made Ethernet harder and harder with each new generation.  Meanwhile WOWN.com was sold and the new guys didn't care about content, they just milked the traffic for advertising.  

Maybe I'm not recalling it right.  I see a site at wown.com which vectors to http://techgenix.com/networking/.  But searching for "world of windows networking" finds a site, http://www.windowsnetworking.com/j_helmig/contact.htm which looks like what I remember.  Oh, well. 

 
> Some early ethernet to serial converters waited  a looong time before
> forwarding the last Rx character to ethernet. Some had adjustable time
> settings with minimum settings of 10 ms :-(. This did make these
> devices useless for high speed half duplex traffic. Modern versions
> forwards the last character after one or few character time idle
> period detected on the Rx serial line.

Paper tape compatibility?  lol 

-- 

  Rick C.

  - Get 2,000 miles of free Supercharging
  - Tesla referral code - https://ts.la/richard11209

[toc] | [prev] | [next] | [standalone]

#28880

On Wed, 2 Oct 2019 19:06:22 -0700 (PDT), Rick C
<gnuarm.deletethisbit@gmail.com> wrote:

>> >> If you intend to use a typical 14500 compatible UART on a PC, there
>> >> are issues with Tx/Rx switching in half duplex multidrop RS-485.
>> 
>> Should be 16450. Those do not have an interrupt when the last stop bit
>> of the last character has actually shifted out of the UART shift
>> register, only when he last character has been moved from the Tx FIFO
>> to the shift register. It still takes a full character time before the
>> character has actually been shifted out and the transmitter can be
>> disabled and set to tri-state.  
>> 
>> Some implementations put the Tx into tri-state some bit times too
>> early and the last character is corrupted, typically having the last
>> bits (most significant bits set eg. 0xFx, 0xEx etc due to 'fail safe'
>> termination) . Others turn off the Tx too late, when the opposite end
>> has already started to send the reply and the first character is lost
>> or the whole message is garbled (start bit missing).
>
>I'm surprised no one thought of dealing with this issue by appending an optional char of all ones to the end of the message and adjusting the protocol to simply ignore this single char.  Treat it as optional and if the start bit is lost, no problem.  If it is received it gets tossed, no problem.  

Serial communication is often used to connect devices from different
vendors, so it is out of the question to alter a standard protocol.

[toc] | [prev] | [next] | [standalone]

#28881

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:
> 
> >> >> If you intend to use a typical 14500 compatible UART on a PC, there
> >> >> are issues with Tx/Rx switching in half duplex multidrop RS-485.
> >> 
> >> Should be 16450. Those do not have an interrupt when the last stop bit
> >> of the last character has actually shifted out of the UART shift
> >> register, only when he last character has been moved from the Tx FIFO
> >> to the shift register. It still takes a full character time before the
> >> character has actually been shifted out and the transmitter can be
> >> disabled and set to tri-state.  
> >> 
> >> Some implementations put the Tx into tri-state some bit times too
> >> early and the last character is corrupted, typically having the last
> >> bits (most significant bits set eg. 0xFx, 0xEx etc due to 'fail safe'
> >> termination) . Others turn off the Tx too late, when the opposite end
> >> has already started to send the reply and the first character is lost
> >> or the whole message is garbled (start bit missing).
> >
> >I'm surprised no one thought of dealing with this issue by appending an optional char of all ones to the end of the message and adjusting the protocol to simply ignore this single char.  Treat it as optional and if the start bit is lost, no problem.  If it is received it gets tossed, no problem.  
> 
> Serial communication is often used to connect devices from different
> vendors, so it is out of the question to alter a standard protocol.

What standard protocol?  You mean the one that doesn't work? 

But that was the problem we faced.  Several boxes had been built, some paid for by the government, some on a company's dime, but this detail had escaped them all and no working system could be built.  I really don't recall what happened.  It may have been that we added a timer to the controlling PC to disable the drive, but I'm pretty sure there was at least one box that didn't wait long enough for that to work reliably.  The slaves have to wait long enough to start their transmission to be sure the master driver is turned off.  I suppose the dummy character still has that issue as well.  

I remember asking how each vendor had been able to deliver a component they could demonstrate would work.  I suppose they rigged something on the PC to work with their own box while not being totally compatible with the other vendor's boxes.  

I also remember there was no spec on the whole thing like a bus protocol.  It only specified things like the contents of the data packet.  Watkins Johnson was one of the vendors who made their box using government money and had at least one flaw in the protocol (I think it was their product that would turn on so quickly after receiving the command it would actually step on the final stop bit).  But their business model didn't allow them to fix the problem unless the government paid for it.  

I think to work reliably an RS-485 bus needs biasing resistors for when no one is driving.  This bus didn't have that.  I expect they didn't have it in any of the slaves and the PC didn't accommodate it.  They chould have used two connectors on each slave unit for passing the signals through to the next slave and the final slave could have the terminating resistors plugged into the final daisy chain connector.  Is it GPIB that works similarly to that?  Or maybe I'm thinking of SCSI with several complex bus types to allow high speed operation at the time. 

-- 

  Rick C.

  + Get 2,000 miles of free Supercharging
  + Tesla referral code - https://ts.la/richard11209

[toc] | [prev] | [next] | [standalone]

#28882

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:
>> 
>> >> >> If you intend to use a typical 14500 compatible UART on a PC, there
>> >> >> are issues with Tx/Rx switching in half duplex multidrop RS-485.
>> >> 
>> >> Should be 16450. Those do not have an interrupt when the last stop bit
>> >> of the last character has actually shifted out of the UART shift
>> >> register, only when he last character has been moved from the Tx FIFO
>> >> to the shift register. It still takes a full character time before the
>> >> character has actually been shifted out and the transmitter can be
>> >> disabled and set to tri-state.  
>> >> 
>> >> Some implementations put the Tx into tri-state some bit times too
>> >> early and the last character is corrupted, typically having the last
>> >> bits (most significant bits set eg. 0xFx, 0xEx etc due to 'fail safe'
>> >> termination) . Others turn off the Tx too late, when the opposite end
>> >> has already started to send the reply and the first character is lost
>> >> or the whole message is garbled (start bit missing).
>> >
>> >I'm surprised no one thought of dealing with this issue by appending an optional char of all ones to the end of the message and adjusting the protocol to simply ignore this single char.  Treat it as optional and if the start bit is lost, no problem.  If it is received it gets tossed, no problem.  
>> 
>> Serial communication is often used to connect devices from different
>> vendors, so it is out of the question to alter a standard protocol.
>
>What standard protocol?  You mean the one that doesn't work? 

There are dozens PLC serial protocols that supports multidrop and the
timing issue may effect them all.

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.

>
>But that was the problem we faced.  Several boxes had been built, some paid for by the government, some on a company's dime, but this detail had escaped them all and no working system could be built.  I really don't recall what happened.  It may have been that we added a timer to the controlling PC to disable the drive, but I'm pretty sure there was at least one box that didn't wait long enough for that to work reliably.  The slaves have to wait long enough to start their transmission to be sure the master driver is turned off.  I suppose the dummy character still has that issue as well.  
>
>I remember asking how each vendor had been able to deliver a component they could demonstrate would work.  I suppose they rigged something on the PC to work with their own box while not being totally compatible with the other vendor's boxes.  

Use some other UART than the 16450 family. Since default PC serial
ports are RS-232 only, you need some external converter driving the
bus. Alternatively use an ISA/PCI card with proper UART and RS-422/485
drivers on board.

>I also remember there was no spec on the whole thing like a bus protocol.  It only specified things like the contents of the data packet.  Watkins Johnson was one of the vendors who made their box using government money and had at least one flaw in the protocol (I think it was their product that would turn on so quickly after receiving the command it would actually step on the final stop bit).  But their business model didn't allow them to fix the problem unless the government paid for it.  
>
>I think to work reliably an RS-485 bus needs biasing resistors for when no one is driving.  

The original RS-485 standard specified the optional 'fail.safe'
resistors. The quotes are from the standard text.

>This bus didn't have that.  I expect they didn't have it in any of the slaves and the PC didn't accommodate it.  

Most  multidrop protocols have  start and end characters or sequences,
so the receiver can ignore line noise before frames or late echoes
after  frames, but timing errors can eat the start or end byte. Modbus
RTU doesn't have start/stop characters but relies on pauses between
frames. For this reason, the bytes had to be sent in one sequence
without too long gaps between bytes. Pauses longer than 1.5 character
times indicate that this is random bus noise without fail-safe
resistors or late echoes due to reflections in an unterminated bus.
Thus Modbus RTU has also been designed to work on a bare bus or with a
properly terminated bus with proper fail-safe resistors.

>They chould have used two connectors on each slave unit for passing the signals through to the next slave and the final slave could have the terminating resistors plugged into the final daisy chain connector.  Is it GPIB that works similarly to that?  Or maybe I'm thinking of SCSI with several complex bus types to allow high speed operation at the time. 

[toc] | [prev] | [next] | [standalone]

#28889

On Thursday, October 3, 2019 at 2:10:07 AM UTC-4, upsid...@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:
> >> 
> >> >> >> If you intend to use a typical 14500 compatible UART on a PC, there
> >> >> >> are issues with Tx/Rx switching in half duplex multidrop RS-485.
> >> >> 
> >> >> Should be 16450. Those do not have an interrupt when the last stop bit
> >> >> of the last character has actually shifted out of the UART shift
> >> >> register, only when he last character has been moved from the Tx FIFO
> >> >> to the shift register. It still takes a full character time before the
> >> >> character has actually been shifted out and the transmitter can be
> >> >> disabled and set to tri-state.  
> >> >> 
> >> >> Some implementations put the Tx into tri-state some bit times too
> >> >> early and the last character is corrupted, typically having the last
> >> >> bits (most significant bits set eg. 0xFx, 0xEx etc due to 'fail safe'
> >> >> termination) . Others turn off the Tx too late, when the opposite end
> >> >> has already started to send the reply and the first character is lost
> >> >> or the whole message is garbled (start bit missing).
> >> >
> >> >I'm surprised no one thought of dealing with this issue by appending an optional char of all ones to the end of the message and adjusting the protocol to simply ignore this single char.  Treat it as optional and if the start bit is lost, no problem.  If it is received it gets tossed, no problem.  
> >> 
> >> Serial communication is often used to connect devices from different
> >> vendors, so it is out of the question to alter a standard protocol.
> >
> >What standard protocol?  You mean the one that doesn't work? 
> 
> There are dozens PLC serial protocols that supports multidrop and the
> timing issue may effect them all.

I was discussing something that happened nearly 30 years ago when these protocols were either not yet in existence or not well known.  The project I am talking about was essentially custom with the various vendors trying to make their units controllable over a shared bus without considering the other units available. 

-- 

  Rick C.

  -- Get 2,000 miles of free Supercharging
  -- Tesla referral code - https://ts.la/richard11209

[toc] | [prev] | [next] | [standalone]

#28893

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.

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.

[toc] | [prev] | [next] | [standalone]

#28898

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.
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, 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.

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.

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.


Agreed that implementing  Modbus RTU timing accurately is hard,
especially at high speeds. With the QUICC I/O coprocessor (on MC68360
and some PPC), this can be done relatively accurately. 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.
 
>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.
>

[toc] | [prev] | [next] | [standalone]

#28901

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.
>>
> 

[toc] | [prev] | [next] | [standalone]

#28903

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:
>>>> 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.

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.

>
>> 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.

Modbus point to point connections work well, without observing
accurate timing.
 
>
>> 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 ?


>> 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.


>> 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:-).

>>  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.

>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.

[toc] | [prev] | [next] | [standalone]

#28904

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.

[toc] | [prev] | [next] | [standalone]

#28905

On Fri, 4 Oct 2019 15:13:24 +0200, David Brown
<david.brown@hesbynett.no> wrote:

>
>>>> 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).

Yes, some do it. It is easy in a point to point system, in which you
know if master only or slave only frames are expected.  The same
applies to a multidrop master. 

However, a multidrop slave has to determine if it is a response from
an other slave or a request from the master and hence know when the
end of telegram is expected. Can you do it for all function codes ?
Some ad hoc code is sufficient for the most common function codes, but
is it possible for all.

[toc] | [prev] | [next] | [standalone]

#28906

On 04/10/2019 15:40, upsidedown@downunder.com wrote:
> On Fri, 4 Oct 2019 15:13:24 +0200, David Brown
> <david.brown@hesbynett.no> wrote:
> 
>>
>>>>> 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).
> 
> Yes, some do it. It is easy in a point to point system, in which you
> know if master only or slave only frames are expected.  The same
> applies to a multidrop master. 
> 
> However, a multidrop slave has to determine if it is a response from
> an other slave or a request from the master and hence know when the
> end of telegram is expected. Can you do it for all function codes ?
> Some ad hoc code is sufficient for the most common function codes, but
> is it possible for all.
> 

Yes - at least, for all standard function codes.

In most Modbus systems, only a very few function codes are ever used,
which makes it all a little easier.

[toc] | [prev] | [next] | [standalone]

#28907

On 2019-10-04, upsidedown@downunder.com <upsidedown@downunder.com> wrote:

> 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.

I've seen it done without timing by using a state machine (including
running CRC) to keep track of the response from the other slave and
detect its end even without a gap.

-- 
Grant

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.arch.embedded

csiph-web