On Monday, December 12, 2022 at 12:11:59 PM UTC-4, Ricky wrote:
> On Monday, December 12, 2022 at 10:46:05 AM UTC-4, Don Y wrote:
> > On 12/11/2022 1:26 PM, Les Cargill wrote:
> > > It is possible to write software for a RasPi that downmuxes one
> > > Ethernet port to multiple USB serial ports. If 16 is too much
> > > for one RasPi then use two RasPi at 8 ports each or four at 4 each.
> > Aren't rPi's dirt cheap? Why not an rPi *per* DUT and port the "Windows"
> > software *into* the rPi.
> That is an option, but spreading a program over 9 programs does not make it more simple and STILL doesn't solve the problem of the 8 UUTs on each test fixture board replying at the same time. Also, rPis are not all that small.
> > No need to worry about sharing a medium
> > (what happens if a leaf node misbehaves and jabbers when it should
> > be silent? Will the upstream host be able to detect this and
> > KNOW who to blame?)
> Please read the description of the system. I think you have misunderstood what is happening. There are 8 UUTs on each test fixture card, controlled by four FPGAs. There is still an issue of communicating with each UUT, even if you assign an SBC to each test fixture card.
> > In the *ported* code, virtualize the HMI to access a "display server"
> > on the Windows box -- which is really all you'd ever want/need a PC for!
> Additional, unnecessary work.
> > > Given 115200 baud per serial port, that's a little under 16 megabit over
> > > Ethernet plus overhead - fits well in a 100 MBit connection.
> > >
> > > The RasPi doesn't have to move; I'd use them screwed or
> > > velcro-ed onto plywood with permanent wiring to the DUTs.
> > >
> > > Then you connect with sockets from the PC to the RasPi. It
> > > can even be 802.11; in fact, some RasPi architectures put
> > > the onboard Ethernet on the USB bus ( which then contends for
> > > bandwidth with the serial ports ) where the 802.11 seems to
> > > be part of the SOIC. You will be bottlenecked by USB for this.
> > > How much is a thing to measure.
> > With a processor-per-DUT, the DUT interface runs at whatever rate
> > the host-tester (processor) and DUT consider to be appropriate.
> Oh, so I should add EIGHT rPis to each test fixture board? Sorry, that is just too much overkill. The rPis might be bigger than the UUTs, so it would only allow four UUTs on a test fixture board, if I can even get them to fit.
>
> Plus, now you've only shifted the entire problem from the RS-485 domain where it is handled by a parallel bus using no extra hardware, to the Ethernet domain where I would need to add 128 Ethernet ports using switches. This has become a Frankenstein's monster!
> > There's no concern for other DUTs "elsewhere"; they can be in Siberia
> > for all that matters! You don't really care what the latency between
> > write() and bits-on-the-wire happens to be; you just treat it as a
> > synchronous call and count on the Rx ISR to capture any reply
> > on which you can pend() (with a timeout in case the DUT stops
> > talking, unexpectedly)
> >
> > And, if you are talking to the host-tester (processor) from the
> > HMI host via ethernet, you can add as many "drops" as you have
> > available switch ports (and adding switches is straightforward).
> And absurd at this level.
> > You never worry that adding more "test nodes" will compromise
> > the tests on the pre-existing nodes -- because the tests are
> > handled *locally* in the corresponding host-testers!
> There won't be added test fixture boards without adding chassis. The chassis only has room for 16 boards and they all require power. Additional test capability will require another chassis.
>
> Maybe an image would help to grasp the approach. Here is a rough drawing of the front panel.
>
> https://arius.com/foobar/TestFixture.png
>
> The gray blocks in the center are RJ-45 connectors, with one connected to the other, as well as the RS-485 devices on the board. Six inch jumpers are around $3 each and would be used to tie the boards together forming a bus, with the first board connected to the PC and the spare connector on the last board connected to terminators.
>
> The power connector isn't shown because it has not been picked. Likely a version of the ubiquitous barrel connector with a detent for retention. I will need to fan those out from the power supply.
> > > If you go this way, Google for "Persistent names for USB-serial devices in Linux"
> > >
> > > The RasPi can be headless or remoted using Cygwin's X server.
> > >
> > > A properly constructed Windows process can use one thread
> > > and "select()" to manage comms.
> > You obviously have to demux the results for your "presentation
> > layer". So, that code exists regardless.
> With one program controlling everything, there's no need for "demuxing". Any errors would be recorded to an error log file and sent to the display, which will likely be just a line by line display like a terminal.
> > > This obviously isn't a "zero code" solution but it's a very handy
> > > thing to know how to do. Your serial port handler on the Windows
> > > machine should be easily converted to using sockets.
> > If you've got a fair bit of money at stake, it seems like
> > INVESTING a little in a reliable test fixture would be a
> > prudent course of action. Esp as the number of units increases
> > (drive labor costs to zero -- install DUT, wait, remove DUT)
> That's why I don't want to add hardware ad infinitum. Less hardware, less chance for failures. I would use a backplane for the interconnections, but that will require another board to be designed with careful consideration of the alignment and time is short on this project.
>
> If the unit was going to be used to test individual UUTs, there would be no need for the parallelism. The DUTs have a low failure rate. This test fixture will accent the failure rate, because loading will be much faster if there are no failures. This will also speed up testing enormously, by eliminating the triple handling of each UUT.
On Monday, December 12, 2022 at 10:46:05 AM UTC-4, Don Y wrote:
> On 12/11/2022 1:26 PM, Les Cargill wrote:
> > It is possible to write software for a RasPi that downmuxes one
> > Ethernet port to multiple USB serial ports. If 16 is too much
> > for one RasPi then use two RasPi at 8 ports each or four at 4 each.
> Aren't rPi's dirt cheap? Why not an rPi *per* DUT and port the "Windows"
> software *into* the rPi.
That is an option, but spreading a program over 9 programs does not make it more simple and STILL doesn't solve the problem of the 8 UUTs on each test fixture board replying at the same time. Also, rPis are not all that small.
> No need to worry about sharing a medium
> (what happens if a leaf node misbehaves and jabbers when it should
> be silent? Will the upstream host be able to detect this and
> KNOW who to blame?)
Please read the description of the system. I think you have misunderstood what is happening. There are 8 UUTs on each test fixture card, controlled by four FPGAs. There is still an issue of communicating with each UUT, even if you assign an SBC to each test fixture card.
> In the *ported* code, virtualize the HMI to access a "display server"
> on the Windows box -- which is really all you'd ever want/need a PC for!
Additional, unnecessary work.
> > Given 115200 baud per serial port, that's a little under 16 megabit over
> > Ethernet plus overhead - fits well in a 100 MBit connection.
> >
> > The RasPi doesn't have to move; I'd use them screwed or
> > velcro-ed onto plywood with permanent wiring to the DUTs.
> >
> > Then you connect with sockets from the PC to the RasPi. It
> > can even be 802.11; in fact, some RasPi architectures put
> > the onboard Ethernet on the USB bus ( which then contends for
> > bandwidth with the serial ports ) where the 802.11 seems to
> > be part of the SOIC. You will be bottlenecked by USB for this.
> > How much is a thing to measure.
> With a processor-per-DUT, the DUT interface runs at whatever rate
> the host-tester (processor) and DUT consider to be appropriate.
Oh, so I should add EIGHT rPis to each test fixture board? Sorry, that is just too much overkill. The rPis might be bigger than the UUTs, so it would only allow four UUTs on a test fixture board, if I can even get them to fit.
Plus, now you've only shifted the entire problem from the RS-485 domain where it is handled by a parallel bus using no extra hardware, to the Ethernet domain where I would need to add 128 Ethernet ports using switches. This has become a Frankenstein's monster!
> There's no concern for other DUTs "elsewhere"; they can be in Siberia
> for all that matters! You don't really care what the latency between
> write() and bits-on-the-wire happens to be; you just treat it as a
> synchronous call and count on the Rx ISR to capture any reply
> on which you can pend() (with a timeout in case the DUT stops
> talking, unexpectedly)
>
> And, if you are talking to the host-tester (processor) from the
> HMI host via ethernet, you can add as many "drops" as you have
> available switch ports (and adding switches is straightforward).
And absurd at this level.
> You never worry that adding more "test nodes" will compromise
> the tests on the pre-existing nodes -- because the tests are
> handled *locally* in the corresponding host-testers!
There won't be added test fixture boards without adding chassis. The chassis only has room for 16 boards and they all require power. Additional test capability will require another chassis.
Maybe an image would help to grasp the approach. Here is a rough drawing of the front panel.
https://arius.com/foobar/TestFixture.png
The gray blocks in the center are RJ-45 connectors, with one connected to the other, as well as the RS-485 devices on the board. Six inch jumpers are around $3 each and would be used to tie the boards together forming a bus, with the first board connected to the PC and the spare connector on the last board connected to terminators.
The power connector isn't shown because it has not been picked. Likely a version of the ubiquitous barrel connector with a detent for retention. I will need to fan those out from the power supply.
> > If you go this way, Google for "Persistent names for USB-serial devices in Linux"
> >
> > The RasPi can be headless or remoted using Cygwin's X server.
> >
> > A properly constructed Windows process can use one thread
> > and "select()" to manage comms.
> You obviously have to demux the results for your "presentation
> layer". So, that code exists regardless.
With one program controlling everything, there's no need for "demuxing". Any errors would be recorded to an error log file and sent to the display, which will likely be just a line by line display like a terminal.
> > This obviously isn't a "zero code" solution but it's a very handy
> > thing to know how to do. Your serial port handler on the Windows
> > machine should be easily converted to using sockets.
> If you've got a fair bit of money at stake, it seems like
> INVESTING a little in a reliable test fixture would be a
> prudent course of action. Esp as the number of units increases
> (drive labor costs to zero -- install DUT, wait, remove DUT)
That's why I don't want to add hardware ad infinitum. Less hardware, less chance for failures. I would use a backplane for the interconnections, but that will require another board to be designed with careful consideration of the alignment and time is short on this project.
If the unit was going to be used to test individual UUTs, there would be no need for the parallelism. The DUTs have a low failure rate. This test fixture will accent the failure rate, because loading will be much faster if there are no failures. This will also speed up testing enormously, by eliminating the triple handling of each UUT.
--
Rick C.
-+--+ Get 1,000 miles of free Supercharging
-+--+ Tesla referral code - https://ts.la/richard11209
Reply by Ricky●December 12, 20222022-12-12
On Monday, December 12, 2022 at 9:44:16 AM UTC-4, Les Cargill wrote:
> Ricky wrote:
> > On Sunday, December 11, 2022 at 4:27:02 PM UTC-4, Les Cargill wrote:
> >> Ricky wrote:
> >>> On Friday, December 2, 2022 at 4:14:39 PM UTC-5,
> >>> upsid...@downunder.com wrote:
> >> <snip>
> >>>
> >>> 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 possible to write software for a RasPi that downmuxes one
> >> Ethernet port to multiple USB serial ports. If 16 is too much for
> >> one RasPi then use two RasPi at 8 ports each or four at 4 each.
> >>
> >> Given 115200 baud per serial port, that's a little under 16 megabit
> >> over Ethernet plus overhead - fits well in a 100 MBit connection.
> >>
> >> The RasPi doesn't have to move; I'd use them screwed or velcro-ed
> >> onto plywood with permanent wiring to the DUTs.
> >>
> >> Then you connect with sockets from the PC to the RasPi. It can even
> >> be 802.11; in fact, some RasPi architectures put the onboard
> >> Ethernet on the USB bus ( which then contends for bandwidth with
> >> the serial ports ) where the 802.11 seems to be part of the SOIC.
> >> You will be bottlenecked by USB for this. How much is a thing to
> >> measure.
> >>
> >> If you go this way, Google for "Persistent names for USB-serial
> >> devices in Linux"
> >>
> >> The RasPi can be headless or remoted using Cygwin's X server.
> >>
> >> A properly constructed Windows process can use one thread and
> >> "select()" to manage comms.
> >>
> >> This obviously isn't a "zero code" solution but it's a very handy
> >> thing to know how to do. Your serial port handler on the Windows
> >> machine should be easily converted to using sockets.
> >
> > I know some people think more hardware is not complex, but the more
> > hardware and cabling required, the less reliable and harder to debug
> > everything is.
> >
> No question of that.
> > Then there's the fact that very few people actually understand what
> > I'm building.
> I can't argue with that.
> You mention hard wiring to the DUT. Maybe I'm not
> > familiar with this term, but to me it's the same as UUT,
> Generally, those are synonyms.
> > which are
> > the product I would be testing in order to ship. I very much do not
> > want to permanently wire anything to the UUTs.
> >
> Then permanently wire to a connector to the UUT. You will presumably
> need wires of some sort. In the case I described, "permanent" worked
> better.
Sorry, I have no idea what you are talking about. Why on earth do I need wires???
> > Assuming you have not read the earlier messages in this thread, let
> > me describe the set up again.
> The setup's been being described on here for weeks. All I know is
> simpler ways to distribute data over multiple serial ports using a Pi.
> You'll have to take it from there.
Sorry, you've said nothing that would make me think using an rPi would be simpler than what I've described, all of which you've trimmed, so I have no idea if you've read it or not.
--
Rick C.
-+--- Get 1,000 miles of free Supercharging
-+--- Tesla referral code - https://ts.la/richard11209
Reply by Don Y●December 12, 20222022-12-12
On 12/11/2022 1:26 PM, Les Cargill wrote:
> It is possible to write software for a RasPi that downmuxes one
> Ethernet port to multiple USB serial ports. If 16 is too much
> for one RasPi then use two RasPi at 8 ports each or four at 4 each.
Aren't rPi's dirt cheap? Why not an rPi *per* DUT and port the "Windows"
software *into* the rPi. No need to worry about sharing a medium
(what happens if a leaf node misbehaves and jabbers when it should
be silent? Will the upstream host be able to detect this and
KNOW who to blame?)
In the *ported* code, virtualize the HMI to access a "display server"
on the Windows box -- which is really all you'd ever want/need a PC for!
> Given 115200 baud per serial port, that's a little under 16 megabit over
> Ethernet plus overhead - fits well in a 100 MBit connection.
>
> The RasPi doesn't have to move; I'd use them screwed or
> velcro-ed onto plywood with permanent wiring to the DUTs.
>
> Then you connect with sockets from the PC to the RasPi. It
> can even be 802.11; in fact, some RasPi architectures put
> the onboard Ethernet on the USB bus ( which then contends for
> bandwidth with the serial ports ) where the 802.11 seems to
> be part of the SOIC. You will be bottlenecked by USB for this.
> How much is a thing to measure.
With a processor-per-DUT, the DUT interface runs at whatever rate
the host-tester (processor) and DUT consider to be appropriate.
There's no concern for other DUTs "elsewhere"; they can be in Siberia
for all that matters! You don't really care what the latency between
write() and bits-on-the-wire happens to be; you just treat it as a
synchronous call and count on the Rx ISR to capture any reply
on which you can pend() (with a timeout in case the DUT stops
talking, unexpectedly)
And, if you are talking to the host-tester (processor) from the
HMI host via ethernet, you can add as many "drops" as you have
available switch ports (and adding switches is straightforward).
You never worry that adding more "test nodes" will compromise
the tests on the pre-existing nodes -- because the tests are
handled *locally* in the corresponding host-testers!
> If you go this way, Google for "Persistent names for USB-serial devices in Linux"
>
> The RasPi can be headless or remoted using Cygwin's X server.
>
> A properly constructed Windows process can use one thread
> and "select()" to manage comms.
You obviously have to demux the results for your "presentation
layer". So, that code exists regardless.
> This obviously isn't a "zero code" solution but it's a very handy
> thing to know how to do. Your serial port handler on the Windows
> machine should be easily converted to using sockets.
If you've got a fair bit of money at stake, it seems like
INVESTING a little in a reliable test fixture would be a
prudent course of action. Esp as the number of units increases
(drive labor costs to zero -- install DUT, wait, remove DUT)
Reply by Les Cargill●December 12, 20222022-12-12
Ricky wrote:
> On Sunday, December 11, 2022 at 4:27:02 PM UTC-4, Les Cargill wrote:
>> Ricky wrote:
>>> On Friday, December 2, 2022 at 4:14:39 PM UTC-5,
>>> upsid...@downunder.com wrote:
>> <snip>
>>>
>>> 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 possible to write software for a RasPi that downmuxes one
>> Ethernet port to multiple USB serial ports. If 16 is too much for
>> one RasPi then use two RasPi at 8 ports each or four at 4 each.
>>
>> Given 115200 baud per serial port, that's a little under 16 megabit
>> over Ethernet plus overhead - fits well in a 100 MBit connection.
>>
>> The RasPi doesn't have to move; I'd use them screwed or velcro-ed
>> onto plywood with permanent wiring to the DUTs.
>>
>> Then you connect with sockets from the PC to the RasPi. It can even
>> be 802.11; in fact, some RasPi architectures put the onboard
>> Ethernet on the USB bus ( which then contends for bandwidth with
>> the serial ports ) where the 802.11 seems to be part of the SOIC.
>> You will be bottlenecked by USB for this. How much is a thing to
>> measure.
>>
>> If you go this way, Google for "Persistent names for USB-serial
>> devices in Linux"
>>
>> The RasPi can be headless or remoted using Cygwin's X server.
>>
>> A properly constructed Windows process can use one thread and
>> "select()" to manage comms.
>>
>> This obviously isn't a "zero code" solution but it's a very handy
>> thing to know how to do. Your serial port handler on the Windows
>> machine should be easily converted to using sockets.
>
> I know some people think more hardware is not complex, but the more
> hardware and cabling required, the less reliable and harder to debug
> everything is.
>
No question of that.
> Then there's the fact that very few people actually understand what
> I'm building.
I can't argue with that.
You mention hard wiring to the DUT. Maybe I'm not
> familiar with this term, but to me it's the same as UUT,
Generally, those are synonyms.
> which are
> the product I would be testing in order to ship. I very much do not
> want to permanently wire anything to the UUTs.
>
Then permanently wire to a connector to the UUT. You will presumably
need wires of some sort. In the case I described, "permanent" worked
better.
> Assuming you have not read the earlier messages in this thread, let
> me describe the set up again.
The setup's been being described on here for weeks. All I know is
simpler ways to distribute data over multiple serial ports using a Pi.
You'll have to take it from there.
<snip>
--
Les Cargill
Reply by Ricky●December 12, 20222022-12-12
On Sunday, December 11, 2022 at 4:27:02 PM UTC-4, Les Cargill wrote:
> Ricky wrote:
> > On Friday, December 2, 2022 at 4:14:39 PM UTC-5,
> > upsid...@downunder.com wrote:
> <snip>
> >
> > 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 possible to write software for a RasPi that downmuxes one
> Ethernet port to multiple USB serial ports. If 16 is too much
> for one RasPi then use two RasPi at 8 ports each or four at 4 each.
>
> Given 115200 baud per serial port, that's a little under 16 megabit over
> Ethernet plus overhead - fits well in a 100 MBit connection.
>
> The RasPi doesn't have to move; I'd use them screwed or
> velcro-ed onto plywood with permanent wiring to the DUTs.
>
> Then you connect with sockets from the PC to the RasPi. It
> can even be 802.11; in fact, some RasPi architectures put
> the onboard Ethernet on the USB bus ( which then contends for
> bandwidth with the serial ports ) where the 802.11 seems to
> be part of the SOIC. You will be bottlenecked by USB for this.
> How much is a thing to measure.
>
> If you go this way, Google for "Persistent names for USB-serial devices
> in Linux"
>
> The RasPi can be headless or remoted using Cygwin's X server.
>
> A properly constructed Windows process can use one thread
> and "select()" to manage comms.
>
> This obviously isn't a "zero code" solution but it's a very handy
> thing to know how to do. Your serial port handler on the Windows
> machine should be easily converted to using sockets.
I know some people think more hardware is not complex, but the more hardware and cabling required, the less reliable and harder to debug everything is.
Then there's the fact that very few people actually understand what I'm building. You mention hard wiring to the DUT. Maybe I'm not familiar with this term, but to me it's the same as UUT, which are the product I would be testing in order to ship. I very much do not want to permanently wire anything to the UUTs.
Assuming you have not read the earlier messages in this thread, let me describe the set up again. Previously, the UUT (a small daughtercard) was tested one at a time on a test fixture, controlled via serial port by an application running on a Windows PC. Once passing, they would be placed on some of my customers units to be inserted into a chassis where they would be powered up overnight. The next day they would be retested and prepared for shipping. The handling results in some connector failures and costs. In order to reduce the time and costs, I am designing a new test fixture.
The new test fixture will consist of multiple boards, each holding eight UUTs and four FPGAs to control the UUTs. The control will still be serial from a single PC, over a shared 4-wire RS-485 bus. Each UUT would receive a command, and reply immediately (< 1 us), preventing any contention on the shared RS-485 bus. On discussing this, it became apparent there would be significant delays in the serial comms adapter on the USB bus. Even though the serial rate can be as high as 3 Mbps, the command sent from the PC and the reply returning to the PC would experience delays independent of the serial bus data rate. The messages are short, so at 3 Mbps, they take only 50 us each. Adding 1 ms in each direction greatly slows the data rate, limiting the rate of testing.
The problem is not the speed of the serial bus, rather the delays in waiting for the replies because of the adapters. I have checked with several suppliers, using both USB and Ethernet, they all have similar delays.
There are several ways to solve this problem. One is to use multiple serial adapters. It is not clear that this would actually solve the problem, and it creates a bit of a mess of wiring. Each time the UUTs are inserted into the fixture, the wiring has to be disconnected and reconnected.
Another is to modify the serial protocol to send more than one command at a time, with a scheme to prevent contention on the bus. With 8 UUTs on each test fixture card, it would not be complex to command all eight in one string sent out with 8 commands. The FPGAs would use a very simple priority scheme to prevent collisions on the bus. Then all 8 UUTs can be commanded and the replies returned in about half a ms, allowing the rate of commands to be increased eight fold.
With a 1 ms polling rate on the USB bus, that would provide 4,000 commands per second on the bus, or about 32 messages per UUT per second.
This keeps the hardware a simple as possible. There is existing FPGA code to process the commands, which will need some modifications to be addressed and to handle the serial priority of replies. The PC software needs to be modified to address targets and test multiple UUTs at the same time. Otherwise, this is not a big deal... well, other than having to design and build the new test fixture board. The existing boards are 14 years old and have produced some 10,000 units. They have outlived their usefulness with the large orders anticipated.
If I were going to add modules to manage the issue at hand, I think it would be Ethernet to serial modules to mount on the test fixture boards. That would require a sixteen port switch and still requires something like the priority scheme to multiplex the replies on the 485 bus. Looking into that, I decided the simpler approach is to just let the PC talk to all the test fixtures at once. The same issue applies to using an rPi as far as I'm aware. I have no reason to believe the rPi can mange the RS-485 bus any more effectively than the expensive Ethernet adapters from various vendors. I don't want to take on the hassle of trying to make that work.
--
Rick C.
--+++ Get 1,000 miles of free Supercharging
--+++ Tesla referral code - https://ts.la/richard11209
Reply by Don●December 11, 20222022-12-11
Les Cargill wrote:
> Ricky wrote:
>> upsid...@downunder.com wrote:
> <snip>
>>
>> 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 possible to write software for a RasPi that downmuxes one
> Ethernet port to multiple USB serial ports. If 16 is too much
> for one RasPi then use two RasPi at 8 ports each or four at 4 each.
>
> Given 115200 baud per serial port, that's a little under 16 megabit over
> Ethernet plus overhead - fits well in a 100 MBit connection.
>
> The RasPi doesn't have to move; I'd use them screwed or
> velcro-ed onto plywood with permanent wiring to the DUTs.
Indeed. In my case screws secure a pi to plywood placed inside a rack
drawer. One of my pi's shown in the upper right corner of the plywood,
connected to a switch with a blue Cat5E cable:
<https://crcomp.net/misc/plypi.png>
Danke,
--
Don, KB7RPU, https://www.qsl.net/kb7rpu
There was a young lady named Bright Whose speed was far faster than light;
She set out one day In a relative way And returned on the previous night.
Reply by Les Cargill●December 11, 20222022-12-11
Ricky wrote:
> On Friday, December 2, 2022 at 4:14:39 PM UTC-5,
> upsid...@downunder.com wrote:
<snip>
>
> 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 possible to write software for a RasPi that downmuxes one
Ethernet port to multiple USB serial ports. If 16 is too much
for one RasPi then use two RasPi at 8 ports each or four at 4 each.
Given 115200 baud per serial port, that's a little under 16 megabit over
Ethernet plus overhead - fits well in a 100 MBit connection.
The RasPi doesn't have to move; I'd use them screwed or
velcro-ed onto plywood with permanent wiring to the DUTs.
Then you connect with sockets from the PC to the RasPi. It
can even be 802.11; in fact, some RasPi architectures put
the onboard Ethernet on the USB bus ( which then contends for
bandwidth with the serial ports ) where the 802.11 seems to
be part of the SOIC. You will be bottlenecked by USB for this.
How much is a thing to measure.
If you go this way, Google for "Persistent names for USB-serial devices
in Linux"
The RasPi can be headless or remoted using Cygwin's X server.
A properly constructed Windows process can use one thread
and "select()" to manage comms.
This obviously isn't a "zero code" solution but it's a very handy
thing to know how to do. Your serial port handler on the Windows
machine should be easily converted to using sockets.
--
Les Cargill
Reply by Ricky●December 9, 20222022-12-09
I've had trouble finding a good terminal emulator under Windows, but it seems Hterm checks off all the items on my list. It shows the main six control codes, NUL, Bell, HT, FF, LF, CR and underlines Tx and Rx data with different colors, as well as letting me dump a text file to the serial port as if it were typed.
The only thing I'd like to seem some improvement in, is adjusting the fonts in the data display. It lets you adjust the font size, but it would be nice to change the font and/or set bold at least.
--
Rick C.
--++- Get 1,000 miles of free Supercharging
--++- Tesla referral code - https://ts.la/richard11209
Reply by John Walliker●December 4, 20222022-12-04
On Sunday, 4 December 2022 at 21:46:08 UTC, Don Y wrote:
> On 12/4/2022 12:26 PM, upsid...@downunder.com wrote:
> > None. You just need to set the line speed and 2/4Wire RS-4xx mode for
> > each serial port, set each port into UDP mode and set a unique IP
> > address for the entire converter box. On the master PC you must just
> > use socket reads and writes.
> The problem with stateful devices between "here" and "there" is
> you have to either ensure (punishable by death) that no one
> disconnects/powers-down one of those devices (which would cause it
> to lose its current state/configuration); or, build ack/nak into
> your protocol so you are sure every external device in your chain
> can be verified as "present" and functioning as intended.
>
> [No acks with UDP; TCP considerably more costly; roll-your own may
> be even costlier -- esp if no experience designing reliable protocols]
>
> I designed/built a device to allow us to ISP OTPs to speed up
> manufacturing. As it was driven by an '11, my interface had to
> be a serial port. Transfering 128K binaries at 9600 bps is a
> considerable timesink -- so, cache the image in the device and
> just let the '11 tell you when to write, read, verify, etc.
>
> Easy peasy.
>
> Call from manufacturing some months later that lots of units
> were failing final test. Turned out, the OTPs were blank!
>
> No, not all of them. Approx one system per day was correct.
> The *first*!
>
> Turns out, new hire was "exceedingly prudent" and would power
> down my device before disconnecting from the UUT. Of course,
> 128K cache was DRAM (FLASH not being available, back then,
> and the device wasn't designed to NEED a nonvolatile store!)
> so it promptly forgot everything it had been told.
>
> Including start/end addresses, etc.
>
> But, would dutifully report that it had written and verified
> every address -- from 0x00000 to 0x00000 on each of the subsequent
> invocations!
>
> Had the guy who had written the UI on the '11 included
> verification of parameters after each operation (the protocol
> that I designed allowed for the host to write AND read the current
> settings), he could have alerted the user to the fact that the
> start/end addresses had changed ("OhMiGosh! How??")
> and saved me from intervening.
>
> "Do the instructions tell you to power down the device after
> each unit?"
>
> "No, but I thought it was good practice not to disconnect things
> with power applied."
>
> "Yes, and I designed this device to allow that to happen, SAFELY,
> so we didn't have to keep reloading the image after each unit!"
>
> "Oh"
>
> Modify instructions to include:
> "Do not power down device until all units are processed!"
>
> Likewise, serial port implementation had hardware and software
> flow control -- instead of just RxTx -- so the host could tell
> that there *was* something out there responding to the
> data stream -- instead of just a "dangling wire".
This is a familiar story. Once upon a time (1975) I was the "new hire".
It was a summer job and one of the tasks was testing a very large pile
of switching power supplies for a communication system in the Stockholm
underground railway. I was supposed to attach a dummy load to each of the
outputs in turn until the psu was fully loaded, test all the output
voltages and spike levels, then remove the loads one by one. This got very
tedious, so I connected them all at once and then turned on the 48V power.
That was fine until I also disconnected all the loads at once. Unfortunately,
this let out a lot of magic smoke before the input fuse had time to blow.
They had a storage 'scope, so a few power supplies later I found that the
problem was caused by the transient response of the power supply.
It would overshoot on removal of all loads at once. The linear final
regulators slew rate limited resulting in a triangular output transient just
large enough to trigger a thyristor crowbar. This caused the power supply to
oscillate at a much higher frequency which exploded the resistor in a
snubber network.
Fortunately, mechanical constraints meant that in normal service it was not
possible to unplug the psu from the rack without first removing the 48V,
so the design didn't need to be changed.
After that I got moved on to more interesting things like testing radar
target simulators.
John