"DIY instrumentation bus" (or DIB)

[jeremy]

It’s true that you would need a micro on both ends. An arduino pro micro can be had for US$3 on aliexpres (I use them like crazy at that price!), or a wiznet chip for <$10 to do the Ethernet part. Something like a raspberry Pi could sit on the other end, or you just plug it in to your PC. This is the approach taken by NI with their PXI chassis; you can either put in a CPU card (essentially just an embedded PC), or instead use that slot to connect it to a desktop PC where it runs over PCIe.

The NI virtual bench, which seems similar to what you are trying to do, minus the modular part, also uses USB/Ethernet and even recommends python. (Ignore the part about the crime against humanity aka labview )

I’ve done a fair amount of test equipment automation, and I have actually never needed two instruments to communicate peer to peer except for trigger/sync; they all talk to some PC software which coordinates them. So I’m not sure why you would want to avoid a central controller? 

[Mr. Scram]

I would also recommend using SCPI or another existing solution to base your design on. Yet another standard isn't going to help things. I love that can plug in all my SCPI devices and talk to it over USB, the serial port or whatever I like.

[prasimix]

I’ve done a fair amount of test equipment automation, and I have actually never needed two instruments to communicate peer to peer except for trigger/sync; they all talk to some PC software which coordinates them. So I’m not sure why you would want to avoid a central controller? 

Oh, quite contrary, I'd like to have central controller but possibly built-in my chassis with backplane (slot #0) that could work with or without connected PC. It's sort of DVD/Media player vs. PC-only solution: the former usually provide faster/easier startup and maintenance while later gives more freedom and choice but also demands more skills and attention.

[prasimix]

I would also recommend using SCPI or another existing solution to base your design on. Yet another standard isn't going to help things. I love that can plug in all my SCPI devices and talk to it over USB, the serial port or whatever I like.

Yes, on software/firmware SCPI is a no-brainer to me. What I'm trying to do here is to downscale "beefy" PXI/VXI hardware part of the story. Therefore all your suggestions and comments are welcome.

[jeremy]

Oh, quite contrary, I'd like to have central controller but possibly built-in my chassis with backplane (slot #0) that could work with or without connected PC.

Yes, this is essentially the MXI option: https://www.ni.com/pxi/mxiexpress/

You just take the embedded controller card out of slot #0 and put in a “dummy” which feeds the important signals out to the PC. If you must have both at once (and don’t want to use something as simple as a mechanical switch to jump between the two), I suppose you also could use a device which has both USB slave and host like the beaglebone black, but then you have to mess around with forwarding data and such.

[David Hess]

On the hardware side, I am not interested unless the instrument bus provides galvanic isolation.  There are lots of instrument buses which do not have this so why would I need another one?  While isolation can be provided inside the instrument, this is also a performance and safety issue.

Ethernet between instruments allows for the possibility of using standard ethernet switches and bridges and even operation over the internet.  That it includes galvanic isolation on both ends, is inexpensive to implement, and has a relatively high data rate is icing on the cake.

What I have done in the past is to use optically isolated asynchronous serial like the old MIDI bus and for the lowest cost designs I think this is the best way.

Provisions should be made for a galvanically isolated out of band trigger signal.  I am not sure how best to do this on the hardware side.

[jeremy]

On the hardware side, I am not interested unless the instrument bus provides galvanic isolation.  There are lots of instrument buses which do not have this so why would I need another one?  While isolation can be provided inside the instrument, this is also a performance and safety issue.

Ethernet between instruments allows for the possibility of using standard ethernet switches and bridges and even operation over the internet.  That it includes galvanic isolation on both ends, is inexpensive to implement, and has a relatively high data rate is icing on the cake.

What I have done in the past is to use optically isolated asynchronous serial like the old MIDI bus and for the lowest cost designs I think this is the best way.

Provisions should be made for a galvanically isolated out of band trigger signal.  I am not sure how best to do this on the hardware side.

But you would also need an isolated power supply for each slot, wouldn’t you?

[David Hess]

On the hardware side, I am not interested unless the instrument bus provides galvanic isolation.  There are lots of instrument buses which do not have this so why would I need another one?  While isolation can be provided inside the instrument, this is also a performance and safety issue.

Ethernet between instruments allows for the possibility of using standard ethernet switches and bridges and even operation over the internet.  That it includes galvanic isolation on both ends, is inexpensive to implement, and has a relatively high data rate is icing on the cake.

What I have done in the past is to use optically isolated asynchronous serial like the old MIDI bus and for the lowest cost designs I think this is the best way.

Provisions should be made for a galvanically isolated out of band trigger signal.  I am not sure how best to do this on the hardware side.

But you would also need an isolated power supply for each slot, wouldn’t you?

That is how the old Tektronix TM500/TM5000 series of modular test instruments works.  Each instrument has a pair of isolated 25VAC transformer secondaries and an NPN/PNP pair of isolated power transistors available to it from the mainframe.

For a lower cost and more flexible solution, separate instruments with just the *isolated* instrumentation bus connection are more suitable.  And if the instrument bus is isolated, it becomes irrelevant if each instrument uses an isolated power supply unless the user requires it.  For instance I might have a pile of small instruments which run off of 12 volt DC power but in this case, galvanic isolation of the instrument bus is doubly important to prevent ground loops and safety issues if the power ground fails.  I have seen PC motherboards and some laptops killed by this when using RS-232.

[prasimix]

On the hardware side, I am not interested unless the instrument bus provides galvanic isolation.  There are lots of instrument buses which do not have this so why would I need another one?  While isolation can be provided inside the instrument, this is also a performance and safety issue.

Ethernet between instruments allows for the possibility of using standard ethernet switches and bridges and even operation over the internet.  That it includes galvanic isolation on both ends, is inexpensive to implement, and has a relatively high data rate is icing on the cake.

What I have done in the past is to use optically isolated asynchronous serial like the old MIDI bus and for the lowest cost designs I think this is the best way.

Provisions should be made for a galvanically isolated out of band trigger signal.  I am not sure how best to do this on the hardware side.

Ethernet sounds good, it's well established, but by default require "intelligent" peripheral module. I'm not per se against adding MCU on that side, but that rise a concern about multiple MCU firmware updating. That can be annoying for many people, and we can count here with very live and dynamic environment when firmware can be updated more frequently then in proprietary/closed/patented system where firmware upload is quite often connected with additional cost.

As you can see in post #43 bus isolation is mentioned but to isolate a whole bus will need more the single Silabs isolator (that it btw excellent for fair price comparing with some competitive devices). In that case Ethernet is clearly a winner and I didn't heard yet of anything else that could provide isolation and high bandwidth.

But you would also need an isolated power supply for each slot, wouldn’t you?

Yes, that's why we discussed about introducing another DC bus voltage (possibly 24 if 48 is too high) that can be used for on-board DC-DC conversion.

[Gribo]

What about PXI/MXI? From all this discussion here, I have a feeling that you are trying to reinvent the wheel. Instead of this, how about designing open source reference designs for PXI?

[prasimix]

What about PXI/MXI? From all this discussion here, I have a feeling that you are trying to reinvent the wheel. Instead of this, how about designing open source reference designs for PXI?

No, I'd like to make a thing simpler and fill the huge gap between professional multi thousands $$$ solution and DIY creations where even two instruments/devices from same author for various reason cannot be easily inter-connected and controlled .

I presume that you took a look on PXI specification: just parallel data and address buses make them expensive and unattractive. Just connectors for such backplane could cost few hundreds. I'd rather follow some standard with serial bus like PCI Express, but it's also overkill my many means (if nothing else their connectors are cheap and even PCB alone is used at the one end, and there you can find a great expansion mechanism based on lanes).

[David Hess]

Ethernet sounds good, it's well established, but by default require "intelligent" peripheral module. I'm not per se against adding MCU on that side, but that rise a concern about multiple MCU firmware updating. That can be annoying for many people, and we can count here with very live and dynamic environment when firmware can be updated more frequently then in proprietary/closed/patented system where firmware upload is quite often connected with additional cost.

Ethernet is definitely complicated on the MAC side requiring a processor of some type and programming.

What about designing a universal open hardware and software ethernet to USART bridge which supports SPI, I2C, and asynchronous serial on the USART side?  Then the user device just needs to deal with some sort of serial connection which is likely a built in capability and SPI and asynchronous serial can be pretty fast although not normally 100 Mbit/second fast.

Would this meet the requirements of SCPI over Ethernet?

Something similar could be done for USB with isolation provided on the USB or USART side of the bridge but I think Ethernet would be better because USB lacks the ease of networking.  Having an instrument which I can plug into any Ethernet port within say the broadcast domain and just have work really appeals to me.

In that case Ethernet is clearly a winner and I didn't heard yet of anything else that could provide isolation and high bandwidth.

USB up to 12 Mbits/second is easy to isolate but I suspect more expensive than Ethernet at 100 Mbits/sec and it loses the easy to use networking capability of Ethernet.

But you would also need an isolated power supply for each slot, wouldn’t you?

Yes, that's why we discussed about introducing another DC bus voltage (possibly 24 if 48 is too high) that can be used for on-board DC-DC conversion.

One of the solutions I have seen used is to provide a regulated high frequency, 20 kHz or higher anyway, high power square wave drive which the separate instruments can use to provide multiple isolated power rails via a simple inverter transformer and diode rectification.  This can be surprisingly low noise and provides a high power factor if a square wave is used.

If the lowest noise is required, then controlling the slew rate of the square wave edges can be done or sinewave drive can be used with a loss of power factor which is likely irrelevant.

[David Hess]

What about PXI/MXI? From all this discussion here, I have a feeling that you are trying to reinvent the wheel. Instead of this, how about designing open source reference designs for PXI?

These standards exemplify everything that I do not want.  If they were acceptable to me, then I could use GPIB and GPIB is not acceptable to me.

[prasimix]

Ethernet sounds good, it's well established, but by default require "intelligent" peripheral module. I'm not per se against adding MCU on that side, but that rise a concern about multiple MCU firmware updating. That can be annoying for many people, and we can count here with very live and dynamic environment when firmware can be updated more frequently then in proprietary/closed/patented system where firmware upload is quite often connected with additional cost.

Ethernet is definitely complicated on the MAC side requiring a processor of some type and programming.

What about designing a universal open hardware and software ethernet to USART bridge which supports SPI, I2C, and asynchronous serial on the USART side?  Then the user device just needs to deal with some sort of serial connection which is likely a built in capability and SPI and asynchronous serial can be pretty fast although not normally 100 Mbit/second fast.

Would this meet the requirements of SCPI over Ethernet?

Something similar could be done for USB with isolation provided on the USB or USART side of the bridge but I think Ethernet would be better because USB lacks the ease of networking.  Having an instrument which I can plug into any Ethernet port within say the broadcast domain and just have work really appeals to me.

Huh, a sort of Ethernet-to-SPI (master) bridge as single-chip solution could be really nice. Eventually some cheap MCU+Ethernet PHY controller with firmware that is uploaded once and don't need further attention. Although I'm not sure if cheap MCU and Ethernet speed communication could coexist together .

I'm thinking here that actually for speed of up to 100 Mbit/s (and isolated), probably a low cost/low count BOM solution could be again xCORE entry level MCU that has built-in SerDes and could work internally with amazing speed (and without jitter), can be inter-connected using their xCONNECT and then we can use affordable Silabs isolators that offer 100 Mbit/s bandwidth. In this case we'll need one MCU per module, but their complier and firmware uploading and bootstrap mechanism offer that everything could be done from single point. But, that makes a whole thing vendor-specific what is not so attractive. Additionally if no daisy-chaining is acceptable (and I really don't like it since failure of one module could jeopardize a whole system), a two xCONNECT links is needed what asks for more isolators. Phew, that is not good.

In that case Ethernet is clearly a winner and I didn't heard yet of anything else that could provide isolation and high bandwidth.

USB up to 12 Mbits/second is easy to isolate but I suspect more expensive than Ethernet at 100 Mbits/sec and it loses the easy to use networking capability of Ethernet.

Yes, it's easy to isolate but it's still costly (around 2.5-3x the price of a 6-line Silabs isolator ) and USB 2.0 is still out of question since only one hardly-sourced isolator exists AFAIK. 

But you would also need an isolated power supply for each slot, wouldn’t you?

Yes, that's why we discussed about introducing another DC bus voltage (possibly 24 if 48 is too high) that can be used for on-board DC-DC conversion.

One of the solutions I have seen used is to provide a regulated high frequency, 20 kHz or higher anyway, high power square wave drive which the separate instruments can use to provide multiple isolated power rails via a simple inverter transformer and diode rectification.  This can be surprisingly low noise and provides a high power factor if a square wave is used.

If the lowest noise is required, then controlling the slew rate of the square wave edges can be done or sinewave drive can be used with a loss of power factor which is likely irrelevant.

That sounds like a great idea and could lower the overall complexity and cost especially if we succeed to find some ready-made small transformers that can be used on all isolated modules, e.g. with single secondary for +3.3 V or +5 V, dual secondary for +/-12 V only, or triple/quadruple secondary for all of them.

[C]

The problem is cheap leads to poor.

serial , spi, i2c are all built with a master in control, at some point a master can not do the job.
In addition serial adds huge encode/decode problem which slows speed and increases program complications.

If you want to spread control such that overload of one is harder then there are two current systems ethernet and can. With both being packet based less encode/decode problem.

Cheap leads to stupid when just a little increase in cost gives you CAN at cost of hardware driver($1). Proper microcontroller selection gives firmware program/update over CAN.
 
Look at world, how many real time control systems are CAN based and how many are Ethernet based.

CAN does some things that are harder do do on Ethernet, priority small packets. Think of interrupts over network with little delay due to small packet size. Think of software functions where many different parts of hardware are evolved.

You build test equipment out of simple modules. Too simple/dumb increases costs and problems. While a AVR can control a power supply, by using an ARM base you can cheaply have ARM scope & awg added again at little cost.

Think of simple word changes
David Hess, suggests a regulated high frequency.
Go a step further and you have a Motor Drive acting like a high frequency supply. This could have noise feedback used to adjust wave shape.

At some point the ability to hot-plug will be wanted.

Differential signals to remove ground loops and improve signals. Adding differential to something that exists can be hard/costly, done at start could be cheap & simple.

There is no one size fits all. Best to have many choices that can build to greater things.

Think
  Ethernet is better at bulk and poorer at real-time.
  CAN is better at real-time and poorer at bulk.
To get better real-time then CAN you need separate signals.
To get better Bulk you need more point to point but could use a shared buss like SATA & SAS.

[David Hess]

That sounds like a great idea and could lower the overall complexity and cost especially if we succeed to find some ready-made small transformers that can be used on all isolated modules, e.g. with single secondary for +3.3 V or +5 V, dual secondary for +/-12 V only, or triple/quadruple secondary for all of them.

Off the shelf isolation and gate drive transformers are suitable but will not provide the correct winding ratios to produce exact output voltages unless the primary side voltage is selected specifically for them.  This is not a problem if a secondary side switching regulator is included.  High frequency operation of the inverter transformer makes for a good power density and easy ripple filtering.

[prasimix]

That sounds like a great idea and could lower the overall complexity and cost especially if we succeed to find some ready-made small transformers that can be used on all isolated modules, e.g. with single secondary for +3.3 V or +5 V, dual secondary for +/-12 V only, or triple/quadruple secondary for all of them.

Off the shelf isolation and gate drive transformers are suitable but will not provide the correct winding ratios to produce exact output voltages unless the primary side voltage is selected specifically for them.  This is not a problem if a secondary side switching regulator is included.  High frequency operation of the inverter transformer makes for a good power density and easy ripple filtering.

Gate transformers makes sense to some extend, if more power is needed designer can search for something bigger. But, there is another possible issue with providing switched/pulsed power that can be used for step-down (with or without further regulation): what SMPS topology to use that tolerate connection of various inductive loads (on-board isolation transformers)?

Additionally, if this approach is going to be selected I'd like to step-down in the first phase mains voltage (115/230 Vac, with or without PFC) to e.g. 24 V unrectified with let say one mandatory "load" to close NFB loop. I'm to sure how variable number of connected transformers could affect stability.

I also find a schematic of mentioned Tek mainframe (3-slot in this case), it seems to me that they were using mains transformer with multiple isolated secondaries (two per module) instead of hi-freq switching output that can be used on module:

[prasimix]

The problem is cheap leads to poor.

Right, and I'm not interesting into cutting a cost at all cost and trying to stay in "jelly bean component" zone. As I already mentioned, my stance is that a huge gap exists between professional and DIY/hobbyist solution and today with global suppliers with multi-million parts stock and overnight delivery if you wish, we are not limited to what we have somewhere on the shelf. Additionally, if some stuff ends up to be pricey I believe that accompanying open-source software/firmware will make a complete solution still very attractive/desirable.

serial , spi, i2c are all built with a master in control, at some point a master can not do the job.

Yes, and in one moment you need more master to do the proper job: that's why xCORE and Propeller MCUs with parallel processing looks quite appealing to me. It's not like bringing more single-core MCU together, since that approach require a special attention to synchronize tasks. I think that multi-core MCU is a proper building block for point-to-point or star topology that already exists in my proposal.

In addition serial adds huge encode/decode problem which slows speed and increases program complications.

If you want to spread control such that overload of one is harder then there are two current systems ethernet and can. With both being packet based less encode/decode problem.

Cheap leads to stupid when just a little increase in cost gives you CAN at cost of hardware driver($1). Proper microcontroller selection gives firmware program/update over CAN.
 
Look at world, how many real time control systems are CAN based and how many are Ethernet based.

CAN does some things that are harder do do on Ethernet, priority small packets. Think of interrupts over network with little delay due to small packet size. Think of software functions where many different parts of hardware are evolved.

You build test equipment out of simple modules. Too simple/dumb increases costs and problems. While a AVR can control a power supply, by using an ARM base you can cheaply have ARM scope & awg added again at little cost.

I didn't consider CAN yet due to limited speed, but I'll take another look and check what is possible with it.

Think of simple word changes
David Hess, suggests a regulated high frequency.
Go a step further and you have a Motor Drive acting like a high frequency supply. This could have noise feedback used to adjust wave shape.

Hm, motor drive could be a solution, but not sure if it can be used for "preparing" mains voltage, too (see my previous post).

At some point the ability to hot-plug will be wanted.

Differential signals to remove ground loops and improve signals. Adding differential to something that exists can be hard/costly, done at start could be cheap & simple.

There is no one size fits all. Best to have many choices that can build to greater things.

Think
  Ethernet is better at bulk and poorer at real-time.
  CAN is better at real-time and poorer at bulk.
To get better real-time then CAN you need separate signals.
To get better Bulk you need more point to point but could use a shared buss like SATA & SAS.

I presume that hot swapping could be implemented quite successfully in the future even without specially designed connector, but differential signaling is quite different story, and if not included in the first specification it will require adding an additional connector.

[C]

Yes, and in one moment you need more master to do the proper job: that's why xCORE and Propeller MCUs with parallel processing looks quite appealing to me. It's not like bringing more single-core MCU together, since that approach require a special attention to synchronize tasks. I think that multi-core MCU is a proper building block for point-to-point or star topology that already exists in my proposal.

I see this as a waste of time and a limit/fail just waiting to happen.
First this is not main stream so no main stream support.
Look at ARM
At the low cheap end you have parts that have a CAN interface. In place of one MPU, many could be cheaply used. At the high end you have ARM & FPGA, This lets a designer not locked in to ONE or MASTER to solve a problem/task with many. Needs idea of many at the start and simple hardware/software to make many easy. Big problem here is changing how designers look at a problem. Distributed control is just that Distributed.   

I didn't consider CAN yet due to limited speed, but I'll take another look and check what is possible with it.

You are also missing other parts. You can have many CAN buses and have much less encode/decode if used properly. Need to remember that a computer is binary and should work in binary not a human version of binary.

I presume that hot swapping could be implemented quite successfully in the future even without specially designed connector, but differential signaling is quite different story, and if not included in the first specification it will require adding an additional connector.

Short answer is NO
Do you see many hot-swap pci around? Was not designed in at start.
Even with SATA,SAS where hot-swap is designed in to drives, you have controlers that do not support hot-swap.
Suggest you read up on how it is done.

[xani]

On the hardware side, I am not interested unless the instrument bus provides galvanic isolation.  There are lots of instrument buses which do not have this so why would I need another one?  While isolation can be provided inside the instrument, this is also a performance and safety issue.

Ethernet between instruments allows for the possibility of using standard ethernet switches and bridges and even operation over the internet.  That it includes galvanic isolation on both ends, is inexpensive to implement, and has a relatively high data rate is icing on the cake.

What I have done in the past is to use optically isolated asynchronous serial like the old MIDI bus and for the lowest cost designs I think this is the best way.

Provisions should be made for a galvanically isolated out of band trigger signal.  I am not sure how best to do this on the hardware side.

Ethernet sounds good, it's well established, but by default require "intelligent" peripheral module. I'm not per se against adding MCU on that side, but that rise a concern about multiple MCU firmware updating. That can be annoying for many people, and we can count here with very live and dynamic environment when firmware can be updated more frequently then in proprietary/closed/patented system where firmware upload is quite often connected with additional cost.

Maybe hybrid approach ? Chassis controller (basically whatever lands in slot 0) connects to modules via serial and exposes them via LAN. It would be trivial on Linux (via some cheapo ARM board) to run it and even do one-ip-per-slot so each device in chassis could be talked with separately.

Then have controller talk with modules via SCPI over serial, or even directly over USB.

[prasimix]

We can name it hybrid approach too, but currently the main concern is what to lay down on the chassis backplane with enough flexibility and speed and can be easily isolated. Later requirement makes USB a bad candidate but that can be addressed with applying isolation indirectly i.e. not on the USB lines but on the other side of USB interface chip (e.g. UART, SPI, etc.).

[C]

We can name it hybrid approach too, but currently the main concern is what to lay down on the chassis backplane with enough flexibility and speed and can be easily isolated. Later requirement makes USB a bad candidate but that can be addressed with applying isolation indirectly i.e. not on the USB lines but on the other side of USB interface chip (e.g. UART, SPI, etc.).

Currently I see no benefits to using a chassis backplane and a lot of problems and costs.
Something with nothing to offer is just that noting.
 

[David Hess]

Gate transformers makes sense to some extend, if more power is needed designer can search for something bigger. But, there is another possible issue with providing switched/pulsed power that can be used for step-down (with or without further regulation): what SMPS topology to use that tolerate connection of various inductive loads (on-board isolation transformers)?

Transformer loads are primarily their secondary loads transformed by the turns ratio; the inductive magnetizing current of the transformer itself is only a minor component.  So the typical rectifier and capacitor input filter on the secondary still looks like a rectifier and capacitor input filter on the primary and some extra series resistance but with a different ratio of voltage to current unless the transformer windings have a 1:1 ratio.

Generating the differential square wave is trivial with an H-bridge driven by pair of square waves 180 degrees out of phase and non-overlapping.  Some switching regulator controllers can generate this waveform directly when their feedback connection is broken like the TL594 which Tektronix used to do this in their 2225 oscilloscope power supply.  Their 24xx series of analog oscilloscopes shows another way using flip-flops and gates.  Jim Williams published some application notes showing other ways to do this.

Additionally, if this approach is going to be selected I'd like to step-down in the first phase mains voltage (115/230 Vac, with or without PFC) to e.g. 24 V unrectified with let say one mandatory "load" to close NFB loop. I'm to sure how variable number of connected transformers could affect stability.

If the primary side is regulated, then many loads can get by without regulation on the secondary side simplifying things so a low, say 24 to 48 volts, but regulated primary side voltage makes perfect sense and that is how Tektronix commonly did it.

I also find a schematic of mentioned Tek mainframe (3-slot in this case), it seems to me that they were using mains transformer with multiple isolated secondaries (two per module) instead of hi-freq switching output that can be used on module:

I just used the TM500/TM5000 mainframes as an example where fully isolated transformer secondaries were provided to each slot.  I suggested using a much higher frequency to improve power density and make filtering easier but only because the needed transformers are readily available at least for low power loads.

Incidentally, Vicor makes isolated fixed ratio power modules which implement all of the above in one module effectively acting like unregulated DC to DC converters.

[xani]

I was thinking about it a bit and I thought of an idea.

Isolation on chassis level would be complex and not needed by everyone (for example for my use cases just having whole chassis be ground-lifted, but still sharing ground would be enough)

Isolation on module level just makes every module much more complex to deal with (especially when/if USB would be involved)

So just... have 2 chassis designs, one which has all of the bells and whistles required to isolate the module like separate isolated power for each module and isolated data/control lines.

And the other without it, just simple shared power. Could probably be basically same PCB design, just with some 0 ohm resistors fitted on isolation-less version

As for busses, I think there are basically 2 requirements to cover, low (measuring voltages/frequency)/mid speed measurements (scanning a bunch of input channels), and high data rate that is usually sampled (logic analyzer/Oscilloscope) or streamed (SDR), with most of devices being in the first category. So ~500kbit (assuming 5k measurements/sec * 10 bytes per measurement) vs tens/hundreds

Therefore I wonder if it would be worth it to have 2 busses, low (say serial so modules itself can just talk via SCPI over serial), and high-data rate, with latter one being optional. So minimal implementation would be just micro with serial interface but that would still allow putting some more beefy modules in.

We can name it hybrid approach too, but currently the main concern is what to lay down on the chassis backplane with enough flexibility and speed and can be easily isolated. Later requirement makes USB a bad candidate but that can be addressed with applying isolation indirectly i.e. not on the USB lines but on the other side of USB interface chip (e.g. UART, SPI, etc.).

Currently I see no benefits to using a chassis backplane and a lot of problems and costs.
Something with nothing to offer is just that noting.

Then, considering whole thread is about having some kind of chassis or backplane, it is probably not for you.

But in theory it would be simple to just have 1 socket "DIB to USB" adapter (as it is just power + whatever bus it uses to talk) where you can plug any module in.

[prasimix]

Thanks a lot for more inputs. It seems that many of us can agree that a graded/staged or multi-level spec makes a lot of sense. Regarding the isolation we don't necessary need to think about extremes like all modules have to be isolated or none of them are isolated. At least modules with sourcing/sinking capability (power supply, el. load) especially when more then one exists in the same chassis asks for isolation. That still don't dictate that rest of the modules need isolation. Therefore I think that non-isolated power lines (i.e. +3.3, +5, +/-12 V) should remain with additional "pulsed" input of e.g. 24 Vpp that can be used to drive on-board isolation transformer with rectifying/filtering and eventually regulation to achieve needed voltage. Additionally we could provide another/separate path for 24 Vdc i.e. which is already regulated and can be used for powering industry-standard 24 V or as input for on-board push-pull converter if designer is not willing to implement generation of pulsed source as @David Hess proposed.

I'd like to highlight once again that what I have in mind is not just a "blind" chassis but one with "user console" on the front panel: a concept of "standalone DVD player" i.e. power it and play, with min. hassle that can arise when establishing communication with PC (wired or wireless), loading software, etc. That could be of great help when you need to frequently move your "instrumentation set" back and forth, when frequent interaction is expected, etc. Depending of user habits and demands that could be a primary and not just a backup user interface. Such feature is not mandatory, it should be a feature of processor board #0, but from other side will affect min. mechanical dimensions since any combination of e.g. TFT display, encoders, switches and I/O connectors asks for wider #0 slot space (currently its set to max. 8 HP or ~40 mm). From other side, since display is slim, that leave enough room inside the chassis to place e.g. AC distribution/filtering, AC/DC section, bigger backup battery and/or DC input if needed, etc.