Multidrop bus on Windows

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

On Thursday, October 3, 2019 at 3:35:31 AM UTC-4, David Brown wrote:
> On 03/10/2019 04:06, Rick C wrote:
> > On Wednesday, October 2, 2019 at 6:11:58 PM UTC-4,
> > upsid...@downunder.com wrote:
> > 
> >> 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.
> 
> That is not the case, at least not for FTDI devices (and several other
> manufacturers).  Plug a different device (different serial number) into
> the same port, and it will get a new comms port number.  Plug the old
> one into a different port, and it might get the old number, or it might
> get a completely new number - I have seen both effects, and can't
> remember the controlling factors.

You are saying that if you plug two identical USB serial port cables into the same USB port you will get two different COM port numbers?  I don't see that with FTDI devices.  I don't see any connection to serial number, rather to the type of cable.  FTDI will get a COM port number and another of the same type will get the same COM port number, but plug a CH340 cable into the same USB port and you'll get a new COM port number. 


> FTDI has application notes about registry entries you can change to get
> the "comms port number follows physical port" effect, primarily for use
> in test systems.
> 
> (Or you can use Linux with a few udev rules and get whatever number and
> naming system you want.)
> 
> > 
> > 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.
> > 
> 
> Ports 1 to 4 are reserved for the standard physical comms ports (even
> though they haven't been standard for a /long/ time on new PC's).

I have seen variable sets of low numbers reserved all the way up into the teens. 


> >> 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.
> 
> How are you trying to connect the PC's ?  Just a single Ethernet cable
> between them, or putting them on an existing network?
> 
> (You are right that MS seems to make many tasks, like networking, harder
> for each generation of Windows.)

Single cable between them.  I think I also tried using my home network but got zero traction with that.  The old system I used was a cable between two Win2k desktops.  

-- 

  Rick C.

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

On Thu, 3 Oct 2019 11:12:15 +0200, David Brown
<david.brown@hesbynett.no> wrote:

>On 03/10/2019 09:59, upsidedown@downunder.com wrote:
>> On Thu, 3 Oct 2019 09:19:41 +0200, David Brown
>> <david.brown@hesbynett.no> wrote:
>> 
>>> On 03/10/2019 00:11, upsidedown@downunder.com wrote:
>>>> On Wed, 2 Oct 2019 12:12:06 +0200, David Brown
>>>> <david.brown@hesbynett.no> wrote:
>>>>
>
>>> There was a common trick of sending an extra 0xff character beyond the
>>> telegram you wanted to send, and when you got the interrupt as that
>>> moved into the transmit register, you turned off the RS-485 driver.
>>> This had a risk of letting a start bit, or part of a start bit, get
>>> through - but for most protocols that was not an issue as it would be
>>> ignored by the receiver.
>> 
>> This is true for most protocols, but not with Modbus RTU, since if the
>> start bit gets trough, it calculates the frame length incorrectly and
>> tries to locate the CRC from the wrong position.
>
>Modbus requires a break before the start of the telegram - at least 3.5
>character times.  A slave that checks this will not be bothered by the
>noise.
>
>Failing that, it is not uncommon to avoid address 255 and consider a
>start address of 255 as noise.

Is this the reason why Modbus RTU documentation defines slave address
range 1 .. 247 (oxF7) ?

>But it certainly /can/ be an issue, and should be considered when
>designing a system.

On 2019-10-03 Rick C wrote in comp.arch.embedded:
> On Wednesday, October 2, 2019 at 6:11:58 PM UTC-4, upsid...@downunder.com wrote:
>> 
>> 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.  
>

That is how we handled this 30 years ago. ;-)

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

Hmm, had the same experience with FTDI just recently. In extreme conditions,
I must admit. But it did crash.

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

That "lock" seems rather soft indeed. A converter may have the same COM
number for a while. But then, after you haven't used it for a while, it
suddenly has a different number. For a while I put stickers with the number
on some converters, but that was useless as they changed after a while.

The real fun starts when you use FTDI chips on your own board and don't
program them with a serial number. Every time you plug them in, the number
is increased and if you do that with 4-port versions, the number rapidly go
over the 100.
(Last time I did this was a long time ago and on W7, may have changed now)


-- 
Stef    (remove caps, dashes and .invalid from e-mail address to reply by mail)

You will visit the Dung Pits of Glive soon.

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.

On 03/10/2019 16:08, Grant Edwards wrote:
> On 2019-10-03, David Brown <david.brown@hesbynett.no> wrote:
> 
>> FTDI has application notes about registry entries you can change to get
>> the "comms port number follows physical port" effect, primarily for use
>> in test systems.
> 
> I've worked for a "serial-port" company for 20 years, and port
> numbering foul-ups are a non-stop source of problems for Windows
> customers.  Still.

Agreed.  (The FTDI note is a kind of "hack" solution, that they only
suggest for specific cases like a PC used for testing cards with their
devices on them.)

> 
>> (Or you can use Linux with a few udev rules and get whatever number and
>> naming system you want.)
> 
> That is indeed the "right" answer (IMO).  I usually have 5-10 USB
> serial devices plugged in to my desktop at any point in time, and it
> doesn't matter what order/port I plug them in.  Thanks to a handful of
> udev rules, they always get repeatable and predictable names.
> 

Yes.

Without specific udev rules (i.e., using the common standard rules),
there is a simple and predictable naming system - you get
/dev/ttyUSBxxx, where xxx is a number.  When you attach a device, you
get the next available number.  For simple uses, that can be enough.
But when using serial ports a lot, it is helpful to have rules that
match your own needs - whether that be giving specific names to specific
serial devices, or specific types of devices, or specific physical
ports, or whatever combination you like.

On 03/10/2019 17:04, Rick C wrote:
> On Thursday, October 3, 2019 at 3:35:31 AM UTC-4, David Brown wrote:
>> On 03/10/2019 04:06, Rick C wrote:
>>> On Wednesday, October 2, 2019 at 6:11:58 PM UTC-4, 
>>> upsid...@downunder.com wrote:
>>> 
>>>> 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.
>> 
>> That is not the case, at least not for FTDI devices (and several
>> other manufacturers).  Plug a different device (different serial
>> number) into the same port, and it will get a new comms port
>> number.  Plug the old one into a different port, and it might get
>> the old number, or it might get a completely new number - I have
>> seen both effects, and can't remember the controlling factors.
> 
> You are saying that if you plug two identical USB serial port cables
> into the same USB port you will get two different COM port numbers?
> I don't see that with FTDI devices.  

Thinking more about this, it might depend on the devices.  Many newer
FTDI chips have ROM and/or EEPROM built in, and come with a serial
number.  But older ones relied on external EEPROM and you put in a
serial number yourself when you program them.  With blank devices, there
is no serial number and therefore no way to distinguish them until they
are programmed.  (And they should be programmed with a unique serial
number - that is a requirement of USB.)

Most of the time I am using ready-made cables from FTDI (especially the
USB to 3.3V TTL serial cables - they are hugely popular for us in
development).  These of course have serial numbers.

> I don't see any connection to
> serial number, rather to the type of cable.  FTDI will get a COM port
> number and another of the same type will get the same COM port
> number, but plug a CH340 cable into the same USB port and you'll get
> a new COM port number.

Certainly when you have different USB manufacturer ID or product ID, you
should get a different comms port.

And maybe something has changed, or varies with different FTDI driver
versions, Windows versions, history of drivers and devices on the
particular machine, or something.  Comms port numbers on Windows always
seems to be a bit of a guessing game.

> 
> 
>> FTDI has application notes about registry entries you can change to
>> get the "comms port number follows physical port" effect, primarily
>> for use in test systems.
>> 
>> (Or you can use Linux with a few udev rules and get whatever number
>> and naming system you want.)
>> 
>>> 
>>> 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.
>>> 
>> 
>> Ports 1 to 4 are reserved for the standard physical comms ports
>> (even though they haven't been standard for a /long/ time on new
>> PC's).
> 
> I have seen variable sets of low numbers reserved all the way up into
> the teens.
> 

I haven't seen that myself, but I don't find it hard to believe!

> 
>>>> 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.
>> 
>> How are you trying to connect the PC's ?  Just a single Ethernet
>> cable between them, or putting them on an existing network?
>> 
>> (You are right that MS seems to make many tasks, like networking,
>> harder for each generation of Windows.)
> 
> Single cable between them.  I think I also tried using my home
> network but got zero traction with that.  The old system I used was a
> cable between two Win2k desktops.
> 

You might, perhaps, need a cross-over cable for a direct connection.
Otherwise it is a matter of giving the two machines fixed IP addresses
on the same network.  Then IP networking should work.  I haven't tried
this with Windows machines, but I don't see any reason why you should
have trouble.  I certainly don't see any need for third-party software.

If you prefer, any cheap router will do the job.  Just connect both PC's
to LAN ports on the router - you don't need anything connected to the
"Internet" port on the router, or any setup.  Each PC will get an IP
address by DHCP and they can communicate.

(You might need to partially disable the local firewall junk on the
Windows PC's to let them listen to each other.  And if you have any
third-party "security" crapware, it's best to get rid of it.)

On 03/10/2019 19:15, upsidedown@downunder.com wrote:
> On Thu, 3 Oct 2019 11:12:15 +0200, David Brown
> <david.brown@hesbynett.no> wrote:
> 
>> On 03/10/2019 09:59, upsidedown@downunder.com wrote:
>>> On Thu, 3 Oct 2019 09:19:41 +0200, David Brown
>>> <david.brown@hesbynett.no> wrote:
>>>
>>>> On 03/10/2019 00:11, upsidedown@downunder.com wrote:
>>>>> On Wed, 2 Oct 2019 12:12:06 +0200, David Brown
>>>>> <david.brown@hesbynett.no> wrote:
>>>>>
>>
>>>> There was a common trick of sending an extra 0xff character beyond the
>>>> telegram you wanted to send, and when you got the interrupt as that
>>>> moved into the transmit register, you turned off the RS-485 driver.
>>>> This had a risk of letting a start bit, or part of a start bit, get
>>>> through - but for most protocols that was not an issue as it would be
>>>> ignored by the receiver.
>>>
>>> This is true for most protocols, but not with Modbus RTU, since if the
>>> start bit gets trough, it calculates the frame length incorrectly and
>>> tries to locate the CRC from the wrong position.
>>
>> Modbus requires a break before the start of the telegram - at least 3.5
>> character times.  A slave that checks this will not be bothered by the
>> noise.
>>
>> Failing that, it is not uncommon to avoid address 255 and consider a
>> start address of 255 as noise.
> 
> Is this the reason why Modbus RTU documentation defines slave address
> range 1 .. 247 (oxF7) ?

That could be the case.  Or they might have other reasons - sometimes I
wonder what the Modbus designers were thinking for some of their rather
arbitrary decisions.

> 
>> But it certainly /can/ be an issue, and should be considered when
>> designing a system.
> 

On 03/10/2019 16:04, Grant Edwards wrote:
> On 2019-10-03, David Brown <david.brown@hesbynett.no> wrote:
> 
>> Still, it is /much/ nicer with a device like the FTDI chips that handles
>> the drive enable timing automatically.
> 
> Does windows support half-duplex mode on the less-ancient versions of
> the 16x50?  I've used varous brands of 16850 UARTs and the half-duplex
> mode always worked fine on them.
> 

I believe so.  It is a /long/ time since I have done such programming,
but I seem to remember Win32 calls to put the serial driver in
"auto-RTS" mode suitable for RS-485.  I can't say I know how it was
implemented.

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