Shared Communications Bus - RS-422 or RS-485

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:

formatting link
Danke,

Reply to
Don
Loading thread data ...

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.

Reply to
Ricky

No question of that.

I can't argue with that.

You mention hard wiring to the DUT. Maybe I'm not

Generally, those are synonyms.

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.

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>
Reply to
Les Cargill

Sorry, I have no idea what you are talking about. Why on earth do I need wires???

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.

Reply to
Ricky

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.

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.

Additional, unnecessary work.

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!

And absurd at this level.

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.

formatting link

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.

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.

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.

Reply to
Ricky

I meant to post the drawing of the chassis, to give people a better idea of what I'm building.

formatting link

Reply to
Ricky

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.