-
I've done several hobby and professional automated test engineering projects, and signal MUX'ing is always an challenge.
For my home projects, I wanted a scanner-card system that could work with my HP34401A, and for the professional projects I needed to MUX signal generator outputs and low-frequency oscilloscope inputs.
Over the last couple years I've developed a generic 20:1 relay MUX card that is stackable and controlled via SPI. For control I've used STM32 nucleo boards and Labjacks, and I've developed a python library for controlling the MUX's with a labjack. The cards can be stacked for hundreds of I/O. One stack can have several groups, each feeding a different instrument.
One significant hurdle was preventing inputs from being short-circuited together. One way is to arrange the relays in a binary tree, but for large numbers of IO that multiplies the relay's thermal EMF errors, and it's harder to scale up by stacking cards. The other option is to connect all the relays in parallel, but make sure that only one is turned on at a time. This could have easily been done with an MCU, but for whatever reason I developed a fully analog and logic based protection circuit. It works well, even if it made the boards a little bigger than they needed to be.
Another cool feature is that measurements can be taken as 2-pole measurements for maximum accuracy, but also as single-pole measurements to a common pin. This lets me get up to 20 single-pole channels from a single card, or 1 2-pole channels, or any mix of both. The choice between single and 2-pole is just based on the command, so they can be re-configured on the fly.
I also added a current channel input for measuring currents up to about 500mA when the MUX is being used with a DMM. I needed this specifically for measuring 4-20mA signals. The early version of the MUX cards had two of these current channels, but later I dropped it down to one in order to fit other features.
I have a full write up with schematics and block diagrams on my personal website: https://eedesignpro.com/projects/dmm-scanner-card/ -
Hi trtr6842,
thank you for sharing.
After you've teased us, give some data please: Max. Voltage, max. current, Leakage etc.....
Best regards
-
Subscribing to thread.
-
Cool project. Few tricks, when I made a project like this:
The DMM has a "VM complete" and a "Trig" coax on the back. If you connect that to your relay board, you can do many things with it. The VM complete can be used to set the relays to the next channel, and then the Trig can be triggered with a delay. So the next measurement can be taken without any communication to set it up on the relay board.
The other trick with a 34401A is the serial port. You can connect it to something other than a computer's USB port.
The relay's thermal EMF can be reduced if you use relays that are latching. Because the coils don't heat up internally. -
Max voltage is 150VDC / 100VAC.
The voltage channels are not designed to carry much current, but should be safe up to at least 50mA or so.
The current channel is good for up to 500mA.
The relays have an insulation resistance of >1GΩ each, and the 150V spacing on the PCB should lead to very low PCB leakages. Overall system insulation resistance should be on the order of >100MΩ, but I don't have the equipment required to verify that precisely, and it will vary with installation.
So far it's made a great general purpose MUX. One installation has five of these cards plus a control-only version of the card in a stack to make a:
40:1 DMM MUX,
20:1 Signal Generator CH1 MUX,
20:1 Signal Generator CH2 MUX,
20:1 Scope CH1 MUX,
20:1 Scope CH2 MUX,
14:1 Power relay MUX Controller,
All of which are controlled by one SPI port.
Switching time is about 20ms, but that can only be accomplished with microcontroller control, python with a labjack tends to be a bit slower, about 50-100ms to switch.
Full schematics and more details are available here!
I also have a full KiCad footprint for the card, so designing it onto a motherboard is like dropping in one large component. The schematics get a little tricky to understand, but pretty simple as far as layout is concerned.
-
Cool project. Few tricks, when I made a project like this:
The DMM has a "VM complete" and a "Trig" coax on the back. If you connect that to your relay board, you can do many things with it. The VM complete can be used to set the relays to the next channel, and then the Trig can be triggered with a delay. So the next measurement can be taken without any communication to set it up on the relay board.
The other trick with a 34401A is the serial port. You can connect it to something other than a computer's USB port.
The relay's thermal EMF can be reduced if you use relays that are latching. Because the coils don't heat up internally.
These scanner cards wouldn't be able to use those signals directly, since they are just controlled via SPI. But whatever host controller is running the SPI interface could easily use those signals!
For my applications I've always connected the test PC directly to the DMM, but I could see some applications where instead connecting it to a MCU or SBC could be helpful.
I considered using latching relays, but the miniature ones were not stocked, and they required a full-bride coil drive circuit. Then significant effort is required to ensure thay stay in a known state. If they are used in a binary tree, then it's not critical, but then you introduce a lot more series contacts. In a parallel architecture, suddently it becomes safety-critical to ensure that all relays get properly reset before turning on a different channel. That would definitely require an MCU on every card to safely control. If I ever need a metrology-grade MUX I would definitely go that route though, but for this project I kept it more suitable for general purpose use, and I was able to keep the costs down. -
Are you aware of these other scan cards:
https://www.eevblog.com/forum/circuit-studio/example-project-relay-scan-card-for-k2000-dmm/
https://www.eevblog.com/forum/circuit-studio/example-project-20-channel-solid-state-scan-card-for-k2000-dmm/
They have full schematic and PCB layout, and I think I once imported one of them into KiCad too. -
Are you aware of these other scan cards:
https://www.eevblog.com/forum/circuit-studio/example-project-relay-scan-card-for-k2000-dmm/
https://www.eevblog.com/forum/circuit-studio/example-project-20-channel-solid-state-scan-card-for-k2000-dmm/
They have full schematic and PCB layout, and I think I once imported one of them into KiCad too.
I have seen those! For my specific applications they were missing a few key features. I needed to use these in fairly high-noise environments, so ensuring that all relays are commanded safely even with SPI control line glitches was important. Also, using an IDC header for the inputs instead of screw terminals made installation in my ATE rack units simpler since they could be connected directly to a panel mount DB-25 connector with just ribbon cable. -
Very nice, thanks for sharing.
I wonder if a 1-to-many decoder like e.g. 74*4514 (4-to-16, latching) or 74*138 (3-to-8) could've simplified your design ? That is of course if you trust those to only assert one line at a time.
But then I notice you also enforce 'only 1 relay' for the whole stack, not just one card, so it may not help much at all. -
Very nice, thanks for sharing.
I wonder if a 1-to-many decoder like e.g. 74*4514 (4-to-16, latching) or 74*138 (3-to-8) could've simplified your design ? That is of course if you trust those to only assert one line at a time.
But then I notice you also enforce 'only 1 relay' for the whole stack, not just one card, so it may not help much at all.
I did not consider those, as I've never used them before. At first glance, I think I could have replaced two of the shift registers with these. Instead of using the outputs of the 3 shift registers directly, I could decode the output of just one shift register. I still think I would need the D-flops to check the decoded command bits before committing them to the relays, since that is required to prevent conflicts between multiple cards. I probably could have removed the card's local summing node, as the decoders would guarantee that only one command is active locally, and then I could leave the multi-card summing node and checks as-is.
Thanks for bringing that up! I may use those for another revision.