Shared Communications Bus - RS-422 or RS-485

On Friday, December 2, 2022 at 4:14:39 PM UTC-5, upsid...@downunder.com wrote:
> On Fri, 2 Dec 2022 10:09:50 -0800 (PST), Ricky
> <gnuarm.del...@gmail.com> wrote: 
> 
> >On Friday, December 2, 2022 at 5:01:14 AM UTC-5, upsid...@downunder.com wrote: 
> >> On Thu, 1 Dec 2022 23:25:03 -0800 (PST), Ricky 
> >> <gnuarm.del...@gmail.com> wrote: 
> >> 
> >> >On Thursday, December 1, 2022 at 11:30:44 PM UTC-5, Jasen Betts wrote: 
> >> >> On 2022-12-01, Ricky <gnuarm.del...@gmail.com> wrote: 
> >> >> 
> >> >> > 
> >> >> > The problem is, I don't have a PCIe slot on the laptops to plug 
> >> >> > into. They also offer a single port USB device that claims high baud 
> >> >> > rates, but baud rate is not the issue. Data rate is the issue, or 
> >> >> > more accurately, message rate. 
> >> >> How fast do you want / need? 
> >> > 
> >> >I'd like to get ~30 message pairs per second per end point. With 128 end points, that's around 4,000 message pairs per second or 8,000 messages (4,000 in each directon). 15 chars per message is 150 bits in each direction, for around 600,000 kbps each way, but they are essentially half duplex, so the bit rate would need to be above 1.2 Mbps. 
> >> One way to access a large number of stations with typically only a few 
> >> bits or bytes each at very short cycle times is to use EtherCAT 
> >> https://en.wikipedia.org/wiki/EtherCAT 
> >> 
> >> A single Ethernet frame is daisy chained through all station. Each 
> >> station can extract bits from the frame and replace with their input 
> >> data to be sent away. The propagation delay in each station is just a 
> >> few bit times on 100 Mbit/s Ethernet. 
> >> 
> >> The system works just like a local train in which each person just 
> >> travels between a few stations. 
> > 
> >The claims seem to support that it would be good for my application, but a quick look didn't show many vendors. I found these guys, but they sure don't put much information on their web pages. 
> > 
> >https://www.anybus.com/technical-support/pages/files-and-documentation---compactcom?ordercode=AB6677
> AnyBus is a company selling fiedbus converters from any technology 
> through their internal protocol to an other fiedbus technology. 
> 
> Check the Beckhoff site for information about EtherCAT.

I wish to learn as little about EitherCAT as possible.  I just want a local COM port that connects to a remote physical serial port. 


> >They use a bunch of canned images on their support page, the kind that you get with low cost web sites. 
> > 
> >More importantly, I found a document for "Host Application Implementation Guide" and it looks like this would be a lot of work to come up the learning curve. I did find where they can use a serial interface. What I have not found, 
> >is what would be needed on the PC side.
> On the master side you should need a standard Ethernet port to launch 
> the "local train", which runs through the special EtherCAT "slave 
> stations" before returning to the master port. For the slaves, special 
> chips are needed.

Yeah, I'm not clear on the "through" thing.  So the slaves have two Ethernet ports, with all data passing from one bus to another?  Or is it all just one Ethernet bus with each slave having two connectors?  


> >On the PC it needs to be a COM port. I see no indication that this software is provided.
> What COM port ? 

Lol.  The entire purpose of this is to connect a program on the PC which is written to talk to a COM port, to a device that is designed to talk over an asynchronous serial connection.  The original thought was an FTDI USB adapter to drive a 4-wire RS-485 bus.  


> Possibly for one time configuration of the slave chips ? 
> Or are you thinking about some AnyBus converter with a serial port ?

Yes.  


> >Maybe I'll look at this later. Right now it is too much work just to get up the learning curve. But thanks for the info.
> The learning curve may be too steep for a one-off project. 

Many solutions are far too complex.  The trick is finding one that is adequately simple. 


> I still do not understand why you would like to put all slaves on a 
> _single_ RS-485 bus. Split the large number of slaves between 8. 16 or 
> 32 independent RS-485 buses and run each bus with an independent 
> Windows process. You could even use multiple PCs, if driving all 
> buses from a single PC is too much.

Multiple Windows processes are not the issue.  The issue is identifying appropriate hardware that connects the PC to the test fixtures without excessive complexity.  Using 16 adapters for 16 test fixtures is "excessive", unless there is no simpler approach. 

Why did you think EtherCAT would be an appropriate approach?  

-- 

Rick C.

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

On Friday, December 2, 2022 at 5:56:47 PM UTC-5, whit3rd wrote:
> On Thursday, December 1, 2022 at 1:20:47 AM UTC-8, Ricky wrote: 
> > On Wednesday, November 30, 2022 at 3:48:40 PM UTC-4, whit3rd wrote: 
> > > On Wednesday, November 30, 2022 at 6:01:04 AM UTC-8, Ricky wrote: 
> 
> > > > 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. 
> 
> > > Maybe, instead of USB intermediate connect, you should have (the master) running 
> > > an RS422 card, for expandability maybe a four-port version like this 
> > > 
> > > <https://fastcomproducts.com/products/fastcom-4224-pcie/> 
> > > 
> > > and have the slaves reply to the buffer memories in its UART 
> > > 
> > > <https://assets.maxlinear.com/web/documents/xr17v358.pdf>
> > The problem is, I don't have a PCIe slot on the laptops to plug into. They also offer a single port USB device that claims high baud rates, but baud rate is not the issue. Data rate is the issue, or more accurately, message rate. I suppose the laptops can be canned and a commercial computer used.
> Do the laptops offer an open m.2 socket? 
> 
> <https://accesio.com/product/m-2-icm422-4/> 

Interesting, but I haven't seen any laptops with external ports for mPCe.  Isn't that used for flash drives? 


> It's also possible, sometimes, that the laptop has a dock connector (but using that 
> is perilous, they're all proprietary, thus will obsolesce rapidly).

Even if it has a dock connector, the dock only gives you Ethernet, USB, etc.  Unless you are talking about constructing something to interface directly to this port.  That would be very close to the bottom my list. 

-- 

Rick C.

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

On 2022-12-02, whit3rd <whit3rd@gmail.com> wrote:
> On Thursday, December 1, 2022 at 1:20:47 AM UTC-8, Ricky wrote:
>> On Wednesday, November 30, 2022 at 3:48:40 PM UTC-4, whit3rd wrote: 
>> > On Wednesday, November 30, 2022 at 6:01:04 AM UTC-8, Ricky wrote: 
>
>> > > 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.
>
>> > Maybe, instead of USB intermediate connect, you should have (the master) running 
>> > an RS422 card, for expandability maybe a four-port version like this 
>> > 
>> > <https://fastcomproducts.com/products/fastcom-4224-pcie/> 
>> > 
>> > and have the slaves reply to the buffer memories in its UART 
>> > 
>> > <https://assets.maxlinear.com/web/documents/xr17v358.pdf>
>
>> The problem is, I don't have a PCIe slot on the laptops to plug into. They also offer a single port USB device that claims high baud rates, but baud rate is not the issue. Data rate is the issue, or more accurately, message rate. I suppose the laptops can be canned and a commercial computer used. 
>
> Do the laptops offer an open m.2 socket?   
>
><https://accesio.com/product/m-2-icm422-4/>
>
> It's also possible, sometimes, that the laptop has a dock connector (but using that
> is perilous, they're all proprietary, thus will obsolesce rapidly).

These days most docks are USB (possibly running some alternate mode
like thunderbolt or PCIe over the USB connector)

Due to the standard connectors and protocols they are also somewhat
interchangable.

-- 
  Jasen.

On Friday, December 2, 2022 at 7:30:49 PM UTC-5, Jasen Betts wrote:
> On 2022-12-02, whit3rd <whi...@gmail.com> wrote: 
> > On Thursday, December 1, 2022 at 1:20:47 AM UTC-8, Ricky wrote: 
> >> On Wednesday, November 30, 2022 at 3:48:40 PM UTC-4, whit3rd wrote: 
> >> > On Wednesday, November 30, 2022 at 6:01:04 AM UTC-8, Ricky wrote: 
> > 
> >> > > 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. 
> > 
> >> > Maybe, instead of USB intermediate connect, you should have (the master) running 
> >> > an RS422 card, for expandability maybe a four-port version like this 
> >> > 
> >> > <https://fastcomproducts.com/products/fastcom-4224-pcie/> 
> >> > 
> >> > and have the slaves reply to the buffer memories in its UART 
> >> > 
> >> > <https://assets.maxlinear.com/web/documents/xr17v358.pdf> 
> > 
> >> The problem is, I don't have a PCIe slot on the laptops to plug into. They also offer a single port USB device that claims high baud rates, but baud rate is not the issue. Data rate is the issue, or more accurately, message rate. I suppose the laptops can be canned and a commercial computer used. 
> > 
> > Do the laptops offer an open m.2 socket? 
> > 
> ><https://accesio.com/product/m-2-icm422-4/> 
> > 
> > It's also possible, sometimes, that the laptop has a dock connector (but using that 
> > is perilous, they're all proprietary, thus will obsolesce rapidly).
> These days most docks are USB (possibly running some alternate mode 
> like thunderbolt or PCIe over the USB connector) 
> 
> Due to the standard connectors and protocols they are also somewhat 
> interchangable. 

I remember when USB and FireWire were still duking it out.  USB had introduced 2.0 and 480 Mbps and FireWire had just bumped up to 1 Gbps or something, but I suppose licensing was making it appear in fewer products.  Some guy on the Internet was enraged that the comparatively crude and poorly implemented USB, was overtaking FireWire, insisting it would prevail over USB.  Eventually USB improved the various glitches and compatibility problems, and reigns supreme, at up to 20 Gbps!  

Unfortunately, for my needs, the relative lack of sophistication of USB serial port implementations means they won't support a high throughput for my application.  So as nice as USB is, it's still too slow for serial ports.  Oh, the irony!  

I wonder if FireWire would have handled the job? 

-- 

Rick C.

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

On Friday, December 2, 2022 at 7:05:45 PM UTC-8, Ricky wrote:

> I remember when USB and FireWire were still duking it out. USB had introduced 2.0 and 480 Mbps and FireWire had just bumped up to 1 Gbps or something, but I suppose licensing was making it appear in fewer products. Some guy on the Internet was enraged that the comparatively crude and poorly implemented USB, was overtaking FireWire, insisting it would prevail over USB. Eventually USB improved the various glitches and compatibility problems, and reigns supreme, at up to 20 Gbps! 
> 
> Unfortunately, for my needs, the relative lack of sophistication of USB serial port implementations means they won't support a high throughput for my application. So as nice as USB is, it's still too slow for serial ports. Oh, the irony! 
> 
> I wonder if FireWire would have handled the job? 

On some laptops, yeah; there was a security issue on Macbooks, because the Firewire
interface was on a DMA channel, it could get straight access to every block on the hard drive without
any OS involvement.

On Fri, 2 Dec 2022 15:03:40 -0800 (PST), Ricky
<gnuarm.deletethisbit@gmail.com> wrote:

>On Friday, December 2, 2022 at 4:14:39 PM UTC-5, upsid...@downunder.com wrote:
>> On Fri, 2 Dec 2022 10:09:50 -0800 (PST), Ricky
>> <gnuarm.del...@gmail.com> wrote: 
>> 
>> >On Friday, December 2, 2022 at 5:01:14 AM UTC-5, upsid...@downunder.com wrote: 
>> >> On Thu, 1 Dec 2022 23:25:03 -0800 (PST), Ricky 
>> >> <gnuarm.del...@gmail.com> wrote: 
>> >> 
>> >> >On Thursday, December 1, 2022 at 11:30:44 PM UTC-5, Jasen Betts wrote: 
>> >> >> On 2022-12-01, Ricky <gnuarm.del...@gmail.com> wrote: 
>> >> >> 
>> >> >> > 
>> >> >> > The problem is, I don't have a PCIe slot on the laptops to plug 
>> >> >> > into. They also offer a single port USB device that claims high baud 
>> >> >> > rates, but baud rate is not the issue. Data rate is the issue, or 
>> >> >> > more accurately, message rate. 
>> >> >> How fast do you want / need? 
>> >> > 
>> >> >I'd like to get ~30 message pairs per second per end point. With 128 end points, that's around 4,000 message pairs per second or 8,000 messages (4,000 in each directon). 15 chars per message is 150 bits in each direction, for around 600,000 kbps each way, but they are essentially half duplex, so the bit rate would need to be above 1.2 Mbps. 
>> >> One way to access a large number of stations with typically only a few 
>> >> bits or bytes each at very short cycle times is to use EtherCAT 
>> >> https://en.wikipedia.org/wiki/EtherCAT 
>> >> 
>> >> A single Ethernet frame is daisy chained through all station. Each 
>> >> station can extract bits from the frame and replace with their input 
>> >> data to be sent away. The propagation delay in each station is just a 
>> >> few bit times on 100 Mbit/s Ethernet. 
>> >> 
>> >> The system works just like a local train in which each person just 
>> >> travels between a few stations. 
>> > 
>> >The claims seem to support that it would be good for my application, but a quick look didn't show many vendors. I found these guys, but they sure don't put much information on their web pages. 
>> > 
>> >https://www.anybus.com/technical-support/pages/files-and-documentation---compactcom?ordercode=AB6677
>> AnyBus is a company selling fiedbus converters from any technology 
>> through their internal protocol to an other fiedbus technology. 
>> 
>> Check the Beckhoff site for information about EtherCAT.
>
>I wish to learn as little about EitherCAT as possible.  I just want a local COM port that connects to a remote physical serial port. 
>
>
>> >They use a bunch of canned images on their support page, the kind that you get with low cost web sites. 
>> > 
>> >More importantly, I found a document for "Host Application Implementation Guide" and it looks like this would be a lot of work to come up the learning curve. I did find where they can use a serial interface. What I have not found, 
>> >is what would be needed on the PC side.
>> On the master side you should need a standard Ethernet port to launch 
>> the "local train", which runs through the special EtherCAT "slave 
>> stations" before returning to the master port. For the slaves, special 
>> chips are needed.
>
>Yeah, I'm not clear on the "through" thing.  So the slaves have two Ethernet ports, with all data passing from one bus to another?  Or is it all just one Ethernet bus with each slave having two connectors?  

Most Ethernet ports have separate connections for the Rx pair and the
Tx Pair. The cable coming from the precious station goes into the Rx
pair and from the Tx pair there is a cable to the next station. Thus
you have to make such cable or use a suitable T-connector at each
station. The slave vendor might provide for convenience separate RJ-45
connectors, one for the Rx pair and the other for the Tx pair. It is
more than a decade since I evaluated various fieldbuses, so I am not
sure what most vendors use today.

>
>> >On the PC it needs to be a COM port. I see no indication that this software is provided.
>> What COM port ? 
>
>Lol.  The entire purpose of this is to connect a program on the PC which is written to talk to a COM port, to a device that is designed to talk over an asynchronous serial connection.  The original thought was an FTDI USB adapter to drive a 4-wire RS-485 bus.  
>
>
>> Possibly for one time configuration of the slave chips ? 
>> Or are you thinking about some AnyBus converter with a serial port ?
>
>Yes.  
>
>
>> >Maybe I'll look at this later. Right now it is too much work just to get up the learning curve. But thanks for the info.
>> The learning curve may be too steep for a one-off project. 
>
>Many solutions are far too complex.  The trick is finding one that is adequately simple. 
>
>
>> I still do not understand why you would like to put all slaves on a 
>> _single_ RS-485 bus. Split the large number of slaves between 8. 16 or 
>> 32 independent RS-485 buses and run each bus with an independent 
>> Windows process. You could even use multiple PCs, if driving all 
>> buses from a single PC is too much.
>
>Multiple Windows processes are not the issue.  The issue is identifying appropriate hardware that connects the PC to the test fixtures without excessive complexity.  Using 16 adapters for 16 test fixtures is "excessive", unless there is no simpler approach. 

It is not clear why you seem to prefer USB and laptops. Using a table
top will give more options.Doesn't your favorite laptop even have a
proper Ethernet port, but you have to rely on some external USB to
Ethernet dongle ?

IMHO the simplest thing to make the connection would to use an
Ethernet pot on a lap/table top, use two 8 port (or four 4 port)
Ethernet to RS-42//485 converters. This you would have 16 independent
multidrop buses. Put the converters in UDP mode and the programming is
easy. Write the whole Tx message into the socket and receive a full
serial frame from the UDP socket.

>Why did you think EtherCAT would be an appropriate approach?  

Since you do not want to use simpler solutions.

On Saturday, December 3, 2022 at 1:56:22 AM UTC-5, upsid...@downunder.com wrote:
> On Fri, 2 Dec 2022 15:03:40 -0800 (PST), Ricky
> <gnuarm.del...@gmail.com> wrote: 
> 
> >On Friday, December 2, 2022 at 4:14:39 PM UTC-5, upsid...@downunder.com wrote: 
> >> On Fri, 2 Dec 2022 10:09:50 -0800 (PST), Ricky 
> >> <gnuarm.del...@gmail.com> wrote: 
> >> 
> >> >On Friday, December 2, 2022 at 5:01:14 AM UTC-5, upsid...@downunder.com wrote: 
> >> >> On Thu, 1 Dec 2022 23:25:03 -0800 (PST), Ricky 
> >> >> <gnuarm.del...@gmail.com> wrote: 
> >> >> 
> >> >> >On Thursday, December 1, 2022 at 11:30:44 PM UTC-5, Jasen Betts wrote: 
> >> >> >> On 2022-12-01, Ricky <gnuarm.del...@gmail.com> wrote: 
> >> >> >> 
> >> >> >> > 
> >> >> >> > The problem is, I don't have a PCIe slot on the laptops to plug 
> >> >> >> > into. They also offer a single port USB device that claims high baud 
> >> >> >> > rates, but baud rate is not the issue. Data rate is the issue, or 
> >> >> >> > more accurately, message rate. 
> >> >> >> How fast do you want / need? 
> >> >> > 
> >> >> >I'd like to get ~30 message pairs per second per end point. With 128 end points, that's around 4,000 message pairs per second or 8,000 messages (4,000 in each directon). 15 chars per message is 150 bits in each direction, for around 600,000 kbps each way, but they are essentially half duplex, so the bit rate would need to be above 1.2 Mbps. 
> >> >> One way to access a large number of stations with typically only a few 
> >> >> bits or bytes each at very short cycle times is to use EtherCAT 
> >> >> https://en.wikipedia.org/wiki/EtherCAT 
> >> >> 
> >> >> A single Ethernet frame is daisy chained through all station. Each 
> >> >> station can extract bits from the frame and replace with their input 
> >> >> data to be sent away. The propagation delay in each station is just a 
> >> >> few bit times on 100 Mbit/s Ethernet. 
> >> >> 
> >> >> The system works just like a local train in which each person just 
> >> >> travels between a few stations. 
> >> > 
> >> >The claims seem to support that it would be good for my application, but a quick look didn't show many vendors. I found these guys, but they sure don't put much information on their web pages. 
> >> > 
> >> >https://www.anybus.com/technical-support/pages/files-and-documentation---compactcom?ordercode=AB6677 
> >> AnyBus is a company selling fiedbus converters from any technology 
> >> through their internal protocol to an other fiedbus technology. 
> >> 
> >> Check the Beckhoff site for information about EtherCAT. 
> > 
> >I wish to learn as little about EitherCAT as possible. I just want a local COM port that connects to a remote physical serial port. 
> > 
> > 
> >> >They use a bunch of canned images on their support page, the kind that you get with low cost web sites. 
> >> > 
> >> >More importantly, I found a document for "Host Application Implementation Guide" and it looks like this would be a lot of work to come up the learning curve. I did find where they can use a serial interface. What I have not found, 
> >> >is what would be needed on the PC side. 
> >> On the master side you should need a standard Ethernet port to launch 
> >> the "local train", which runs through the special EtherCAT "slave 
> >> stations" before returning to the master port. For the slaves, special 
> >> chips are needed. 
> > 
> >Yeah, I'm not clear on the "through" thing. So the slaves have two Ethernet ports, with all data passing from one bus to another? Or is it all just one Ethernet bus with each slave having two connectors?
> Most Ethernet ports have separate connections for the Rx pair and the 
> Tx Pair. The cable coming from the precious station goes into the Rx 
> pair and from the Tx pair there is a cable to the next station. Thus 
> you have to make such cable or use a suitable T-connector at each 
> station. The slave vendor might provide for convenience separate RJ-45 
> connectors, one for the Rx pair and the other for the Tx pair. 

Yeah, that's what they do, they have two connectors.  It didn't occur to me you could separate them this way.  But I suppose Ethernet works ok this way.  Their system diagrams show a complete loop, so the typical Ethernet two way protocols still work I suppose.  


> It is 
> more than a decade since I evaluated various fieldbuses, so I am not 
> sure what most vendors use today.
> > 
> >> >On the PC it needs to be a COM port. I see no indication that this software is provided. 
> >> What COM port ? 
> > 
> >Lol. The entire purpose of this is to connect a program on the PC which is written to talk to a COM port, to a device that is designed to talk over an asynchronous serial connection. The original thought was an FTDI USB adapter to drive a 4-wire RS-485 bus. 
> > 
> > 
> >> Possibly for one time configuration of the slave chips ? 
> >> Or are you thinking about some AnyBus converter with a serial port ? 
> > 
> >Yes. 
> > 
> > 
> >> >Maybe I'll look at this later. Right now it is too much work just to get up the learning curve. But thanks for the info. 
> >> The learning curve may be too steep for a one-off project. 
> > 
> >Many solutions are far too complex. The trick is finding one that is adequately simple. 
> > 
> > 
> >> I still do not understand why you would like to put all slaves on a 
> >> _single_ RS-485 bus. Split the large number of slaves between 8. 16 or 
> >> 32 independent RS-485 buses and run each bus with an independent 
> >> Windows process. You could even use multiple PCs, if driving all 
> >> buses from a single PC is too much. 
> > 
> >Multiple Windows processes are not the issue. The issue is identifying appropriate hardware that connects the PC to the test fixtures without excessive complexity. Using 16 adapters for 16 test fixtures is "excessive", unless there is no simpler approach.
> It is not clear why you seem to prefer USB and laptops. Using a table 
> top will give more options.Doesn't your favorite laptop even have a 
> proper Ethernet port, but you have to rely on some external USB to 
> Ethernet dongle ? 

I don't prefer USB if it is a single device providing a single serial port.  I'd be very happy with an Ethernet to serial device.  I would also be happy with either USB or Ethernet providing N serial ports if they can provide the message rate I need.  But the devices seem to all be limited by the CPU they use.  

When I start looking at using individual serial adapters, I lean to Ethernet.  I have had difficulties with cascaded USB port expanders and have zero interest in testing those waters.  Ethernet is easy to work with in this regard, once the setup is established. 

I can't recall ever seeing a laptop in the last 20 years that didn't have an Ethernet port.  I have no idea why you think mine doesn't.  


> IMHO the simplest thing to make the connection would to use an 
> Ethernet pot on a lap/table top, use two 8 port (or four 4 port) 
> Ethernet to RS-42//485 converters. This you would have 16 independent 
> multidrop buses. Put the converters in UDP mode and the programming is 
> easy. Write the whole Tx message into the socket and receive a full 
> serial frame from the UDP socket.

What programming?  The serial converters have drivers to make them look like COM ports on the PC.   The code to talk to the serial port is already written and working.  Actually, it was much more complex than required, because of some comms problems resulting in verification in the comms, with retries.  Not very pretty.  So I will probably restructure it.  But not planning to do anything that would involve coding at such a low level as Ethernet packets. 


> >Why did you think EtherCAT would be an appropriate approach?
> Since you do not want to use simpler solutions.

LOL!  Show me a simpler solution that works and I'm ON IT! 

One vendor thinks I should use his Ethernet to serial gadget to host my own handler for aggregating multiple targets in a single message train.  I'm definitely not writing code for a third party device.  This is all in support of a redesign of a product I sell.  I want to improve the testing process.  I'm not looking to reinvent all wheels.  If I can't get something that runs as fast as I'd like, I can live with it running a bit slower.  500 tests overnight can be pretty good too.  

But I still have one trick up my sleeve... using the handshake lines as a daisychained priority enable, to prevent collisions when the slaves reply to the master commands which are sent without waiting for other replies.  I prefer to not implement that, but if I have to...  it's got to be simpler than many of the other schemes. 

-- 

Rick C.

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

On Sat, 3 Dec 2022 00:10:13 -0800 (PST), Ricky
<gnuarm.deletethisbit@gmail.com> wrote:

>
>> IMHO the simplest thing to make the connection would to use an 
>> Ethernet pot on a lap/table top, use two 8 port (or four 4 port) 
>> Ethernet to RS-42//485 converters. This you would have 16 independent 
>> multidrop buses. Put the converters in UDP mode and the programming is 
>> easy. Write the whole Tx message into the socket and receive a full 
>> serial frame from the UDP socket.
>
>What programming?  The serial converters have drivers to make them look like COM ports on the PC.   The code to talk to the serial port is already written and working. 

The problem with those vendor supplied COM port look-a-likes is that
they only support a single line. If you have multiple lines, you will
have to use a process (or at least a thread) for each physical serial
line to get any advantage of using multiple lines.

Using UDP sockets, you can send a single request to every serial line
in parallel. Then start waiting for responses from these lines, by
issuing a select() call and process each response as it has arrived.
This can all be done un a single thread. I have used this technique to
drive up to 50 serial lines with Eth/serial converters controlling 50
Variable Frequency Drives (VFD) running 50 motors from a single
thread.

On Saturday, December 3, 2022 at 7:00:04 AM UTC-5, upsid...@downunder.com wrote:
> On Sat, 3 Dec 2022 00:10:13 -0800 (PST), Ricky 
> <gnuarm.del...@gmail.com> wrote: 
> 
> > 
> >> IMHO the simplest thing to make the connection would to use an 
> >> Ethernet pot on a lap/table top, use two 8 port (or four 4 port) 
> >> Ethernet to RS-42//485 converters. This you would have 16 independent 
> >> multidrop buses. Put the converters in UDP mode and the programming is 
> >> easy. Write the whole Tx message into the socket and receive a full 
> >> serial frame from the UDP socket. 
> > 
> >What programming? The serial converters have drivers to make them look like COM ports on the PC. The code to talk to the serial port is already written and working.
> The problem with those vendor supplied COM port look-a-likes is that 
> they only support a single line. If you have multiple lines, you will 
> have to use a process (or at least a thread) for each physical serial 
> line to get any advantage of using multiple lines. 

I will look into that.  I've not been told I can't open multiple COM ports from a single process. 


> Using UDP sockets, you can send a single request to every serial line 
> in parallel. Then start waiting for responses from these lines, by 
> issuing a select() call and process each response as it has arrived. 
> This can all be done un a single thread. I have used this technique to 
> drive up to 50 serial lines with Eth/serial converters controlling 50 
> Variable Frequency Drives (VFD) running 50 motors from a single 
> thread.

How does the UDP socket map to a serial port?  What driver is required from the adapter vendor?  

I'm not looking to do tons of work for this.  Actually, I finally got past my initial resistance to an idea that might allow high data rates on a single COM port, as well as controlling the timing of the slaves on the shared bus.  DEL characters can be added to the master messages to space them out.  Since the slaves respond very rapidly, the spacing will give the first slave time to complete the reply before the second slave starts sending.   Since the master sends large messages and the slave replies should look like a single message, this should be very fast in the end, with a single serial port. 

-- 

Rick C.

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

lørdag den 3. december 2022 kl. 21.57.49 UTC+1 skrev Ricky:
> On Saturday, December 3, 2022 at 7:00:04 AM UTC-5, upsid...@downunder.com wrote: 
> > On Sat, 3 Dec 2022 00:10:13 -0800 (PST), Ricky 
> > <gnuarm.del...@gmail.com> wrote: 
> > 
> > > 
> > >> IMHO the simplest thing to make the connection would to use an 
> > >> Ethernet pot on a lap/table top, use two 8 port (or four 4 port) 
> > >> Ethernet to RS-42//485 converters. This you would have 16 independent 
> > >> multidrop buses. Put the converters in UDP mode and the programming is 
> > >> easy. Write the whole Tx message into the socket and receive a full 
> > >> serial frame from the UDP socket. 
> > > 
> > >What programming? The serial converters have drivers to make them look like COM ports on the PC. The code to talk to the serial port is already written and working. 
> > The problem with those vendor supplied COM port look-a-likes is that 
> > they only support a single line. If you have multiple lines, you will 
> > have to use a process (or at least a thread) for each physical serial 
> > line to get any advantage of using multiple lines.
> I will look into that. I've not been told I can't open multiple COM ports from a single process.

you can open as many as you like, they are mostly just like files

> > Using UDP sockets, you can send a single request to every serial line 
> > in parallel. Then start waiting for responses from these lines, by 
> > issuing a select() call and process each response as it has arrived. 
> > This can all be done un a single thread. I have used this technique to 
> > drive up to 50 serial lines with Eth/serial converters controlling 50 
> > Variable Frequency Drives (VFD) running 50 motors from a single 
> > thread.
> How does the UDP socket map to a serial port? What driver is required from the adapter vendor? 
> 
> I'm not looking to do tons of work for this. Actually, I finally got past my initial resistance to an idea that might allow high data rates on a single COM port, as well as controlling the timing of the slaves on the shared bus. DEL characters can be added to the master messages to space them out. Since the slaves respond very rapidly, the spacing will give the first slave time to complete the reply before the second slave starts sending. Since the master sends large messages and the slave replies should look like a single message, this should be very fast in the end, with a single serial port. 
> 

yes, concat your messages spaced with some special character to give each slave a slot and send that as one long message