Shared Communications Bus - RS-422 or RS-485

On Saturday, November 5, 2022 at 3:32:42 AM UTC-4, whit3rd wrote:
> On Friday, November 4, 2022 at 5:17:26 PM UTC-7, Ricky wrote: 
> 
> > The RS-422 solution lets me use a bog standard chip and all cabling is just in parallel, so very easy to implement... 
> 
> Each pair is a short drop from the backbone; how do you wire that 'in parallel' when it requires two terminated 
> endpoints on a serial string? U-turn cables, and plug in a dummy short link when a slave is 
> removed from the ensemble?

The master has a cable with an RJ-45 plug.  Each test fixture board has two RJ-11 connectors, wired to each other and to an RS-422 receiver/driver chip.  The master (PC) plugs into one of the connectors on the first test fixture card.  The other connector is jumpered to the next card.  Jumpering continues to the last card.  I haven't decided yet, but the termination resistor can be either through a jumper installed on 0.1" header pins on the last card, or I could make an RJ-45 plug with the terminating resistor.  

I could use RJ-11, but RJ-45 seems to be much more available in various combinations of lengths, colors, and stock!  

I'm a bit concerned about buying premade cables intended for Ethernet, like Cat5e.  Seems they use a rather odd wiring scheme, with 4 twisted pairs.  Pair 1 is on the first two pins.  Pair 2 is on pins 3 and 6.  Pair 3 is on pins 4 and 5.  Pair 4 is on pins 7 and 8.  Even odder, is that the colors used are different between two variations of the standard, EIA/TIA 568A & 568B.  Every reference I've found so far, talks as if there's no big difference in the two standards, A and B, but it seems as if the only difference is the color of pair 1 and pair 2, being reversed between them.  That's it, no electrical difference at all, just the two pair colors are swapped.  They even say there's a preference for one over the other depending on the use.  WTF is that about???   It's hard to believe there would be two different standards, if there's no difference other than the insulation color! 

Anyway, the first web site I found to easily buy the combination of length, etc. I would want doesn't say how the connectors are pinned out.  The A vs. B versions of the standard don't matter, but it does matter if twisted pairs are not wired to the standard.  I need to know which pins are paired and twisted, to put the differential signals on.  

-- 

Rick C.

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

On Fri, 4 Nov 2022 07:57:04 -0700 (PDT), Ricky
<gnuarm.deletethisbit@gmail.com> wrote:

>On Friday, November 4, 2022 at 5:17:57 AM UTC-4, upsid...@downunder.com wrote:
>> On Tue, 1 Nov 2022 22:30:58 -0700 (PDT), Ricky 
>> <gnuarm.del...@gmail.com> wrote: 
>> 
>> >I could do an RS-422 interface with a master to slave pair and a slave to master pair. The slaves do not speak until spoken to, so there will be no collisions.
>> The master can be standard RS-422, but the slaves needs to be 4-wire 
>> RS-485 i.e. the slave Tx is in tri-state until the slave is addressed. 
>> 
>> On a PC side, do NOT use standard RS-232 PC ports followed by an 
>> RS-232 to RS-422/485 external converter, there is a great risks for 
>> timing problems. Use proper RS-422/485 PCI cards (or external Ethernet 
>> to RS-422/485 converter for laptops).
>
>PCI cards?  What's wrong with USB cables?  FTDI makes chips that provide serial ports from USB interfaces.  

OK, I found that some FTDI chips provide unique serial numbers, so you
could safely use multiple identical chips on the same PC. Without a
unique serial number I would not use two or more identical USB devices
on the same PC. Moving the USB device to an other USB port on the PC
could cause safety critical issues.

With any RS-422/48/current loop system you need to calculate the
available bandwidth for each slave device and possibly limit the
number of slaves (less than 31 for RS-485). Thus multiple masters and
networks may be required.

For applications requiring a few or a few dozen  serial lines I prefer
using Ethernet (UDP) yo serial (RS-232/422/485/current loop)
converters. First of all, these systems have galvanic isolation as a
bonus, serial signals can be routed to the final use using Ethernet
with cheap standard fiber connections.

On Saturday, November 5, 2022 at 8:18:35 AM UTC-4, upsid...@downunder.com wrote:
> On Fri, 4 Nov 2022 07:57:04 -0700 (PDT), Ricky
> <gnuarm.del...@gmail.com> wrote: 
> 
> >On Friday, November 4, 2022 at 5:17:57 AM UTC-4, upsid...@downunder.com wrote: 
> >> On Tue, 1 Nov 2022 22:30:58 -0700 (PDT), Ricky 
> >> <gnuarm.del...@gmail.com> wrote: 
> >> 
> >> >I could do an RS-422 interface with a master to slave pair and a slave to master pair. The slaves do not speak until spoken to, so there will be no collisions. 
> >> The master can be standard RS-422, but the slaves needs to be 4-wire 
> >> RS-485 i.e. the slave Tx is in tri-state until the slave is addressed. 
> >> 
> >> On a PC side, do NOT use standard RS-232 PC ports followed by an 
> >> RS-232 to RS-422/485 external converter, there is a great risks for 
> >> timing problems. Use proper RS-422/485 PCI cards (or external Ethernet 
> >> to RS-422/485 converter for laptops). 
> > 
> >PCI cards? What's wrong with USB cables? FTDI makes chips that provide serial ports from USB interfaces.
> OK, I found that some FTDI chips provide unique serial numbers, so you 
> could safely use multiple identical chips on the same PC. Without a 
> unique serial number I would not use two or more identical USB devices 
> on the same PC. Moving the USB device to an other USB port on the PC 
> could cause safety critical issues. 
> 
> With any RS-422/48/current loop system you need to calculate the 
> available bandwidth for each slave device and possibly limit the 
> number of slaves (less than 31 for RS-485). Thus multiple masters and 
> networks may be required. 
> 
> For applications requiring a few or a few dozen serial lines I prefer 
> using Ethernet (UDP) yo serial (RS-232/422/485/current loop) 
> converters. First of all, these systems have galvanic isolation as a 
> bonus, serial signals can be routed to the final use using Ethernet 
> with cheap standard fiber connections.

Perhaps you don't understand the use case.  There is only one master serial port on a PC.  It runs at some rate &ge; 1 Mbps.  It will run two buses (one master transmit and one master receive) with up to 32 slave test fixture cards.  The USB protocol provides polling rates at 8 kHz.  With every master message getting a slave response, that's 4,000 message pairs per second.  That is over 100 messages per second to each slave and should be fast enough for my needs.  

Even if I'm off by 2:1 and probably if I'm off by 5:1, the system will still be very usable.  

I see no need for Ethernet, or galvanic isolation.  The power supplies will provide galvanic isolation.  It is possible I would use one FTDI cable per rack, rather than combine two 16 test fixture card racks on one serial port.  But in that case I'd probably use two PCs as well.  At this time, a single rack, testing 128 UUTs will suit my expected needs. 

-- 

Rick C.

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

On Sat, 5 Nov 2022 09:03:32 -0700 (PDT), Ricky
<gnuarm.deletethisbit@gmail.com> wrote:

>
>Perhaps you don't understand the use case.  There is only one master serial port on a PC.  It runs at some rate ? 1 Mbps.  It will run two buses (one master transmit and one master receive) with up to 32 slave test fixture cards.  

If you want 1 s update cycle with 32 slaves, you have only 30 ms/slave
transaction (request+response). Since this is simple half-duplex
(despite separate Tx and Rx paths) you need to transmit the request,
decode and generate the response and send the response within 30 ms.
The slave processing delay will quite drastically reduce the system
throughput.

At 1 Mbs (100000 cps) the transaction (request+response) can just
contain 3000 characters.

>The USB protocol provides polling rates at 8 kHz.  

That is 125 bits or 12.5 characters/poll.

>With every master message getting a slave response, that's 4,000 message pairs per second.  That is over 100 messages per second to each slave and should be fast enough for my needs.  

You have to calculate how many slave Rx/Tx delays are required at each
slave to generate a response and add this to the message Tx and Rx
times to get the total transaction times.

Of course, if you only need to poll every slave once every few seconds
or every minute, you cuild use 1/2 or 1/4 UL RS-5485 Unit load (UL)
transceivers and poll 64 or 182 slaves in one loop.

On Sunday, November 6, 2022 at 7:09:30 AM UTC-5, upsid...@downunder.com wrote:
> On Sat, 5 Nov 2022 09:03:32 -0700 (PDT), Ricky 
> <gnuarm.del...@gmail.com> wrote: 
> 
> > 
> >Perhaps you don't understand the use case. There is only one master serial port on a PC. It runs at some rate ? 1 Mbps. It will run two buses (one master transmit and one master receive) with up to 32 slave test fixture cards. 
> 
> If you want 1 s update cycle with 32 slaves, you have only 30 ms/slave 
> transaction (request+response). Since this is simple half-duplex 
> (despite separate Tx and Rx paths) you need to transmit the request, 
> decode and generate the response and send the response within 30 ms. 
> The slave processing delay will quite drastically reduce the system 
> throughput. 

The slave will have sub-microsecond response time. 


> At 1 Mbs (100000 cps) the transaction (request+response) can just 
> contain 3000 characters.
> >The USB protocol provides polling rates at 8 kHz.
> That is 125 bits or 12.5 characters/poll.
> >With every master message getting a slave response, that's 4,000 message pairs per second. That is over 100 messages per second to each slave and should be fast enough for my needs.
> You have to calculate how many slave Rx/Tx delays are required at each 
> slave to generate a response and add this to the message Tx and Rx 
> times to get the total transaction times. 
> 
> Of course, if you only need to poll every slave once every few seconds 
> or every minute, you cuild use 1/2 or 1/4 UL RS-5485 Unit load (UL) 
> transceivers and poll 64 or 182 slaves in one loop.

I don't think you are grasping how this needs to work. 

All 128 or 256 UUTs are addressed on the same bus with 8 UUTs on a test fixture card, with one RS-422 driver receiver, so 16 or 32 RS-422 bus loads.  The messages are short enough that the bit rate is not limiting.  Rather the message rate (USB polling rate) is the limiting factor.  With an 8 kHz polling rate of USB high speed, I would get 32 message pairs per second per UUT (the pair is one command from PC and one response from a slave).  

With the polling rate of 1 kHz of USB full speed, the message pair rate is only 4 per second.  That's a bit limiting although it can still work.  I'd like to find serial cables that work at USB high speed data rates. 

-- 

Rick C.

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

I have been digging into the various interfaces I could use and it seems when serial ports are involved, the handling of the data gets slow.  It doesn't matter much what the claimed baud rate is on the serial port, there is significant overhead for handling a "message". 

I have a protocol that sends a short message of around 12-15 characters from the master to an addressed slave.  The slave responds virtually immediately with a reply with about the same length.  There seems to be significant lag in handling the messages on every adapter device I've gotten info on.  

The FTDI USB to RS-422 or RS-485 interfaces can not handle this protocol faster than the USB polling rate, which for the high-speed interface is 8,000 per second.  So  4,000 message and response pairs in a second.  That sounds fast, but there are a lot of units, so it is the minimum I would like to see. 

Some people have suggested that I use Ethernet on each board, but splitting that out would be a bit of a pain and each board would need setup, etc.  I expect there are Ethernet to serial modules that could be put on the board, but it's more learning curve.  However... I found Ethernet to serial devices which would appear to support over 3 Mbps on the serial side.  However, when I contacted them about the short message issue, they indicated each message, in each direction would have 1 ms of overhead!  That drops the message pair rate to no more than 500 per second, eight times slower than USB!  

I'm looking at multi-port Ethernet to serial interfaces now.  If they can manage 500 message pairs a second on 16 ports, that would at least be as fast as the USB and less likely to not actually achieve that rate... I suppose.  I'm asking another vendor who's serial ports are only 1 Mbps, but maybe they don't have the 1 ms overhead and can actually get close to 1 Mbps on each port.  Then I could get by with a 4 port unit. 

Maybe I should look at adding an Ethernet port to each board.  I really don't like the idea of the learning curve.  If it is a module that can be mounted to the board without too much height, and requires a minimal amount of setup, then maybe this can work.  It's going to be a PITA to identify the units on the PC.  Which unit is COM1?   Which is COM2, etc?  But I suppose that can be managed, somehow.  As long as once it is setup it isn't forgotten and has to be repeated.  

-- 

Rick C.

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

On 30/11/2022 02:00, Ricky wrote:
> I have been digging into the various interfaces I could use and it seems when serial ports are involved, the handling of the data gets slow.  It doesn't matter much what the claimed baud rate is on the serial port, there is significant overhead for handling a "message".

<snip>

You could separate the node selection/addressing function from the data. 
  In concept a completely different approach using a large 
multi-position electronic switch to select one of n devices and then use 
whatever point-to-point comms you want, eg RS232.  The switch is 
controlled by the PC.

Or if cabling is a big deal, a distributed selector.  Possibly as simple 
as daisy-chained single-stage shift registers for each node which switch 
their RS232 in turn to the single PC RS232 port.  The PC would twiddle 
the shift register clock and data to send a single bit round the nodes 
in turn.  Or use addresses, but that needs a uC for each node plus 
firmware and some way of setting the address.

-- 
Cheers
Clive

On Tue, 29 Nov 2022 18:00:06 -0800 (PST), Ricky
<gnuarm.deletethisbit@gmail.com> wrote:

>I have been digging into the various interfaces I could use and it seems when serial ports are involved, the handling of the data gets slow.  It doesn't matter much what the claimed baud rate is on the serial port, there is significant overhead for handling a "message". 

Why do you insist of putting all your 256 slaves on a single serial
bus and poll them sequentially? Any half duplex protocol is going to
have a lot of overhead and at high nominal line speeds the effective
throughput is going to be well below nominal speed.

Split your 256 slaves into say 8 buses of 32 slaves each or even 32
multidrop buses with 8 slaves each. You can then scan each bus
independently and use a lower nominal line speed on each bus. On
Windows, you could have 8 or 32 in depended processes, each scanning a
single bus segment. The physical implementation could be a single 8
port or 32 port RS-485 PCIe card or four 8 port Ethernet/RS-485
converter. In the latter case for ultimate performance you could add
two or four ethernet ports to the PC for driving one or two 8 port
Eth/RS-485 adapters.

Redo your speed calculations with 8 or 32 slaves on a single RS-485
bus.

Of course, if you like RS-232 (or RS-422) very much, get 256 RS-232
ports on PCIe cards or Eth/RS-232  converters. Primitive converters
can be quite cheap these days. You may need some 32 port Ethernet
switches also- If your current application only handles a single slave
on one RS-232 line, you just need 256 Windows processes in the PC. If
course, if your current process is boated, this may consume a lot of
resources.

On Wednesday, November 30, 2022 at 7:33:23 AM UTC-4, Clive Arthur wrote:
> On 30/11/2022 02:00, Ricky wrote: 
> > I have been digging into the various interfaces I could use and it seems when serial ports are involved, the handling of the data gets slow. It doesn't matter much what the claimed baud rate is on the serial port, there is significant overhead for handling a "message".
> <snip> 
> 
> You could separate the node selection/addressing function from the data. 
> In concept a completely different approach using a large 
> multi-position electronic switch to select one of n devices and then use 
> whatever point-to-point comms you want, eg RS232. The switch is 
> controlled by the PC. 
> 
> Or if cabling is a big deal, a distributed selector. Possibly as simple 
> as daisy-chained single-stage shift registers for each node which switch 
> their RS232 in turn to the single PC RS232 port. The PC would twiddle 
> the shift register clock and data to send a single bit round the nodes 
> in turn. Or use addresses, but that needs a uC for each node plus 
> firmware and some way of setting the address. 

I'm not sure how any of this would help.  The problem is the adapters providing the serial port function are not able to handle lots of small messages, at anything remotely close to the actual baud rate of the serial port, because of the small message sizes.  

The cabling is one of the issues.  The test fixture boards have to be removed and reinstalled each day with a new load of UUTs.  I'd like the cabling to be as simple as reasonable.  I'd also like to not have a plethora of adapter boxes, like splitting Ethernet into 16 ports with multiple boxes.  It can get messy very quickly.  That's why the 4-wire RS-485 is appealing.  Each test fixture board has two RJ-45 connectors for an in-and-out arraignment.  Plug the PC into the first one and use a very short CAT5 cable to connect to each next test fixture board.  Take one out of the middle and it doesn't matter, just jumper over it.  The boards them selves will have a switch setting to identify them, likely a hex rotary switch.  

-- 

Rick C.

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

On Wednesday, November 30, 2022 at 8:48:31 AM UTC-4, upsid...@downunder.com wrote:
> On Tue, 29 Nov 2022 18:00:06 -0800 (PST), Ricky 
> <gnuarm.del...@gmail.com> wrote: 
> 
> >I have been digging into the various interfaces I could use and it seems when serial ports are involved, the handling of the data gets slow. It doesn't matter much what the claimed baud rate is on the serial port, there is significant overhead for handling a "message".
> Why do you insist of putting all your 256 slaves on a single serial 
> bus and poll them sequentially? Any half duplex protocol is going to 
> have a lot of overhead and at high nominal line speeds the effective 
> throughput is going to be well below nominal speed. 

Why is that?  What is the nature of this, "overhead"?  The slaves are FPGAs.  They use a 33 MHz clock to talk to the UUT using an SPI type interface with two data in pins, so less than  1 uS to send the command and get the response.  Where's this implicit overhead?  

The overhead is in the adapters.  I have not heard back from FTDI, but people have mentioned that the USB bus operates on polling, and full-speed polls at up to 1,000 per second while hi-speed operates at up to 8,000 per second.  If there are no other delays, that could give me around 1 Mbps throughput and 16 message pairs per UUT per second, which would be marginally adequate. 


> Split your 256 slaves into say 8 buses of 32 slaves each or even 32 
> multidrop buses with 8 slaves each. 

32 buses are more than I have boards.  


> You can then scan each bus 
> independently and use a lower nominal line speed on each bus. 

I still need an adapter that provides the 16 serial ports.  I've asked a couple of vendors if this would work with their equipment and not  heard back yet. 


> On 
> Windows, you could have 8 or 32 in depended processes, each scanning a 
> single bus segment. 

Zero need for multiple processes.  


> The physical implementation could be a single 8 
> port or 32 port RS-485 PCIe card or four 8 port Ethernet/RS-485 
> converter. In the latter case for ultimate performance you could add 
> two or four ethernet ports to the PC for driving one or two 8 port 
> Eth/RS-485 adapters. 

It's hard to fit a PCIe card in the laptops being used. 


> Redo your speed calculations with 8 or 32 slaves on a single RS-485 
> bus. 

That can't be done until I hear back from the vendors. 


> Of course, if you like RS-232 (or RS-422) very much, get 256 RS-232 
> ports on PCIe cards or Eth/RS-232 converters. Primitive converters 
> can be quite cheap these days. You may need some 32 port Ethernet 
> switches also- If your current application only handles a single slave 
> on one RS-232 line, you just need 256 Windows processes in the PC. If 
> course, if your current process is boated, this may consume a lot of 
> resources.

A PC with 256 cables running to 16 boards seems like a bit of overkill. 

I'm surprised the Ethernet adapter vendors didn't design their products to be a bit more speed aware.  I can only think the data is going through a processor, when it should be handled in hardware, like an FPGA.  I used to design  network test gear, and we handled a 77 MHz interface by passing the data through the FPGA with the processor only managing the control and status from the UI.  A 100 Mbps Ethernet interface should not have 1 ms delays to handle a single message. 

-- 

Rick C.

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