Multidrop bus on Windows

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

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.

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

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. 

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

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.

Still, it is /much/ nicer with a device like the FTDI chips that handles
the drive enable timing automatically.

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

There is a big challenge with these kinds of devices and serial port
numbers in Windows.  Windows gives a new comms port to each new device
it sees, and sometimes to the same device on a different USB bus.  It
should not mix up the numbers - but it is very easy for users to do so -
if you have two devices and they are on comms port numbers 45 and 57,
which is which?

Programs that are aware of the USB nature of the ports can make this a
lot easier - it's not hard to use Win32 calls or the FTDI DLL's to
identify serial numbers of devices or the physical placement on bus and
hub trees.

Or you can use Linux, which makes it a lot easier to do that kind of thing.

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

Ethernet to serial converters can be useful, but have their own
complications - you have a lot more jitter in timings, and you have
challenges about identifying and addressing them on the network.

The RS-485 driving issue is no different from what you get with USB
RS-485 converters - the bus driver is enabled if and only if you are
transmitting.

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

This is always going to be an issue.  It is an issue with USB too, but
less so than with Ethernet.

I have run USB serial ports at 3 Mbaud.  No Ethernet to serial converter
is going to send the last character within one or two character time
periods at these speeds.  (Nor will USB devices, but they'll be closer
and less varied.)

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:
>> 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 know that's the way /I/ handled it, decades ago when it was a problem.
 I assume it was standard practice.

(As a side issue, I wrote a program on Win3.1 which needed fast regular
processing at about 1 kHz.  The Windows timers were at 50 or 60 Hz,
which was not nearly fast enough.  But if you opened an unconnected
serial port at 9600 baud, enabled interrupts on transfers, and sent one
character at a time - you had interrupts at approximately 1 kHz.  This
thread brings back happy memories!)

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

When we have the choice, we invariably use FTDI devices - made in Scotland.

On older PC's, from the younger days of USB, I saw PC's crashing as the
result of ground loops through the USB drivers.  We had trouble with
that in one test system, long ago - the solution was an independent
ground wire from the PC chassis to the card, connected before the USB
was plugged in.

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

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

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

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

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

>Still, it is /much/ nicer with a device like the FTDI chips that handles
>the drive enable timing automatically.

So does some UARTs in a PCI cards.

>>> 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.
>
>There is a big challenge with these kinds of devices and serial port
>numbers in Windows.  Windows gives a new comms port to each new device
>it sees, and sometimes to the same device on a different USB bus.  It
>should not mix up the numbers - but it is very easy for users to do so -
>if you have two devices and they are on comms port numbers 45 and 57,
>which is which?
>
>Programs that are aware of the USB nature of the ports can make this a
>lot easier - it's not hard to use Win32 calls or the FTDI DLL's to
>identify serial numbers of devices or the physical placement on bus and
>hub trees.

The serial number trick works, but requires an unique serial number
.e.g. with a separate serial number chip or some Flash memory to store
a (hopefully) unique serial number at first use.

Relying on device position in a hub tree is a no no thing, since more
hub levels may have to be added if more USB devices are inserted.

>
>Or you can use Linux, which makes it a lot easier to do that kind of thing.
>
>> 
>> 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'.
>
>Ethernet to serial converters can be useful, but have their own
>complications - you have a lot more jitter in timings, and you have
>challenges about identifying and addressing them on the network.

Use fixed IP-addresses in a private address area such as 192.168.x.y.

>The RS-485 driving issue is no different from what you get with USB
>RS-485 converters - the bus driver is enabled if and only if you are
>transmitting.
>
>> 
>> 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.
>> 
>
>This is always going to be an issue.  It is an issue with USB too, but
>less so than with Ethernet.
>
>I have run USB serial ports at 3 Mbaud.  No Ethernet to serial converter
>is going to send the last character within one or two character time
>periods at these speeds.  (Nor will USB devices, but they'll be closer
>and less varied.)

For accurate timing, do not use TCP between PC and converter. UDP will
give a more predictable timing or just raw MAC framing, but this is
much harder to use on Windows.

A converter based on the QUICC co-processor (found on MC68360 and some
PPC models) should be able to handle a few fast serial lines. But of
course, these processors are an overkill for such simple task.

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.

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

> 
>> Still, it is /much/ nicer with a device like the FTDI chips that handles
>> the drive enable timing automatically.
> 
> So does some UARTs in a PCI cards.

Yes.  But those are often not directly compatible with standard ports.

> 
>>>> 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.
>>
>> There is a big challenge with these kinds of devices and serial port
>> numbers in Windows.  Windows gives a new comms port to each new device
>> it sees, and sometimes to the same device on a different USB bus.  It
>> should not mix up the numbers - but it is very easy for users to do so -
>> if you have two devices and they are on comms port numbers 45 and 57,
>> which is which?
>>
>> Programs that are aware of the USB nature of the ports can make this a
>> lot easier - it's not hard to use Win32 calls or the FTDI DLL's to
>> identify serial numbers of devices or the physical placement on bus and
>> hub trees.
> 
> The serial number trick works, but requires an unique serial number
> .e.g. with a separate serial number chip or some Flash memory to store
> a (hopefully) unique serial number at first use.

Any USB serial converter you buy should have a unique serial number.  If
they don't, then try buying from a reputable source instead of something
that fell off an eBay truck.

> 
> Relying on device position in a hub tree is a no no thing, since more
> hub levels may have to be added if more USB devices are inserted.

It is a "yes yes" thing for many people in many environments, because it
is obvious and convenient - it's just like plugging your RS-232 line
into "com1" at the back of an ancient PC.

The options are there, and it's up to you to pick the ones that suit best.

> 
>>
>> Or you can use Linux, which makes it a lot easier to do that kind of thing.
>>
>>>
>>> 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'.
>>
>> Ethernet to serial converters can be useful, but have their own
>> complications - you have a lot more jitter in timings, and you have
>> challenges about identifying and addressing them on the network.
> 
> Use fixed IP-addresses in a private address area such as 192.168.x.y.
> 

That can work - or it can lead to complications and conflicts.  And it
either means /very/ expensive converter devices with some way of viewing
and setting the IP addresses, or chicken-and-egg time-wasting for
configuration.

>> The RS-485 driving issue is no different from what you get with USB
>> RS-485 converters - the bus driver is enabled if and only if you are
>> transmitting.
>>
>>>
>>> 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.
>>>
>>
>> This is always going to be an issue.  It is an issue with USB too, but
>> less so than with Ethernet.
>>
>> I have run USB serial ports at 3 Mbaud.  No Ethernet to serial converter
>> is going to send the last character within one or two character time
>> periods at these speeds.  (Nor will USB devices, but they'll be closer
>> and less varied.)
> 
> For accurate timing, do not use TCP between PC and converter. UDP will
> give a more predictable timing or just raw MAC framing, but this is
> much harder to use on Windows.

Raw MAC framing is out of the question for Windows.  UDP is a better
than TCP/IP for low latency (but loses you the joys of redirecting your
traffic over ssh links, VPNs, the internet, etc.), but it is certainly
far from real-time.

> 
> A converter based on the QUICC co-processor (found on MC68360 and some
> PPC models) should be able to handle a few fast serial lines. But of
> course, these processors are an overkill for such simple task.
> 

Yes, that is overkill.

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.

-- 
Grant Edwards               grant.b.edwards        Yow! I'm not an Iranian!!
                                  at               I voted for Dianne
                              gmail.com            Feinstein!!

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.

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

-- 
Grant Edwards               grant.b.edwards        Yow! Could I have a drug
                                  at               overdose?
                              gmail.com