HP MUX E1476A/E1442A Cards for ref scans

[VNUTDENYER]

Quick (yes/no) question.  Are subject cards, with connection modules, useful for non-latching scans/measuring voltage refs.  Trying to get MUX modules for HP VXI use to scan PX/FX refs, ref sources, KV deviders and some standard cells.  MUX's are form C so may need to mirror connections to reduce errors but only need 8 channels 4 wire so 64 ch should be enough.  Thanks for any non-flame help.

[Echo88]

Id say no: non-latching relays will never have the same low TEMF as latching ones and therefore you wont get the full performance from KVDs and standard cells (even worse due to their low 1.018V compared to the standard 10V from FX/PX), especially with soo many metal connections (card + terminal block) between the relay and your cable.
Apart from the fact that VXI-mainframes like the 8401A are loud and ventilated monsters... i use mine as a pedestal for the pc-monitor.
I suggest Keithley 7057A (nonlatching relays) or better yet a 2001-TCSCAN-card (latching relays) if possible.

[VNUTDENYER]

Thanks, kind of suspected too many connections to be useful, even with mirroring to oppose. Also VXI 7000 mainframe loud but what I have so felt need to use if possible.  Found mention of ADS1256IDB module for 8/4 (non-diff/diff) inputs and will check further. Would really like to log VXI DMM's concurrently but have not found/tested SW yet. Still looking.

[dietert1]

For monitoring the differences between some voltage references a HP3457A with a built-in 44492A may be a good solution, if you can get one.

I also made scanners myself, with small bi-stable relays (Axicom V23079B1201B301). Those relays get 5 msec pulses only. That works quite well. Photo shows one with USB. Still needs thermal protection and wiring. Will probably make something with CAN bus, since USB doesn't scale very well and i am getting blue-screens when using more than 5 or 10 at the same time. Will also try some CMOS analog muxes to see how well they perform.

Regards, Dieter

[alm]

Have you considered Ethernet for scalability? There are cheap Ethernet to UART boards that will act as a TCP client/sever. Scaling Ethernet to dozens of connections should be fine with cheap switches (we're not talking high traffic here), and handling dozens of TCP connections should be trivial for even a small single board computer like a Raspberry Pi.

What is the CPLD doing in your prototype? Decoding the commands, like "Close channel 10", to sending a pulse to relay #10? Or is it also doing autonomous scanning (cycle to next channel every X seconds)?

[dietert1]

As far as i understand making a CAN bus node is much cheaper than an Ethernet node. And like GPIB and VXI it is a real bus, something very economic.

In my DIY MUX the CPLD empties the FTDI fifo slowly, so i can send several commands as a packet. Each byte operates one coil, everything very simple. Before i had made one with 74HCT138 decoders. So i have something like a driver that keeps track of the relays' state and generates the necessary command bytes.
I used the CPLD because it is 5 V tolerant and can operate the coils directly. The 16 relays have 32 coils and i could have wired each coil to a separate pin. In the end i wired a matrix with four additional pull-up buffers. The CPLD remains completely quiet when inactive. It's RC clock starts only when the FTDI interface has data.

Regards, Dieter

[alm]

Thanks for explaining it, I like the solution of the digital clock only running when there is data. Ethernet with TCP/IP is definitely orders of magnitude more complicated than CAN, but both software and hardware is ubiquitous, and you can get modules with UART output for just over $11 from AliExpress. If you want to have some distance between the modules, then running Ethernet cables might be easier. Of course in terms of latency CAN will be far superior, but this struck my as low bandwidth and minimal latency requirements.

Another thing you get for free with Ethernet is galvanic isolation, which can be handy to avoid ground loops.