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?
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.
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.
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.
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?
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?
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?
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.
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.
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?
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.
QuoteIn 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.
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.
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.
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.
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 didn't consider CAN yet due to limited speed, but I'll take another look and check what is possible with it.
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.
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.
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.).
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:
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.