Define and standardize connections between devices

[XX-Yin]

@saskiad @dyf @jsiegle @galenlynch @alakunina @hanhou @hagikent @alexpiet

Hi all,

When I was generating the rig.json, I found there is a general question "How to standardize and flexibly define device connections?".

I think there are mainly two components for rig.json. One is the parameters for individual devices, and the other is the connections between devices. The current code handles parameters for individual devices nicely, but it does not capture connections for all devices with a general format. It defines connections for some devices with a specific format (e.g. by DAQChannel and some devices require computer name provided), and I think we can improve it in a more general way.

One possibility is to create a new class connector and add it to all devices. The connector should have different connection interface available (e.g. usb, daq channles, power ...), and contain input and output devices. It should be a list as one device could be connected with multiple devices. Once we have the connector information for each device, we can add code to automatically generate an abstract connection map between all devices. The format of the map could even be diagram and is not limited to text.

The connectivity is a very important feature of the rig to help people inside/outside the institute replicate our setup. And it's the last missing part for me to fully make use of the metadata. Please feel free to give alternative suggestions.

[jsiegle]

It's true that the device-to-device connections are currently under-specified, making it impossible to recover the full rig configuration from the metadata. One possible quick fix would be to allow connections between DaqChannel objects. Right now a DaqChannel can only be connected to a Device, so the channel of that device is ambiguous. This could be solved by adding an optional connected_channel field that points to another DaqChannel.

The path to making this more general requires a broader discussion. For example, if there is a need for a separate Connection class, should this just be used for analog and digital I/O, or also for optical connections and data interfaces? Either way, this would be a big change, so we need as many folks as possible to weigh in.