Best option for a toggled device

[juliomateoslangerak]

I'd like to implement a group of flipper mirrors controlled through microscope and used through cockpit and I cannot find the right (obvious) type of device. It could be easily implemented as a FilterWheel with two positions but it is confusing. Would we need a device for this? A toggle device Mixin and a flipper. It is a priory a trigger device but somehow in a different way.

[iandobbie]

I have long planned to add the piDio device which does digital IO and temperature measuring as a microscope device but never got around to it. However, this does not do synchronous IO so the states can't be flipped in a reliably times manner during experiments. What exactly is your use case? Do you plan to have this as experiment compatible digital IO device or just to enable state changes outside experiments?

[iandobbie]

Re-reading your question, I think we need a generic digital IO device, and I think we should also enable it to be a log value source for things like temperature readings (see the linkam device for the revised log value source as this is the only current device). Then we need some kind of interface that allows the digital IO device to have a gui and be able to affect things like light paths, so possibly flip filters, change excitation sources etc....

[juliomateoslangerak]

My use case is a simple pair of flip mirrors to swap between SIM and WF paths and an additional activation of a rotating diffuser in the WF path (also digitally controlled on/off). So a priory nothing that has to be synchronous IO. Surely I'd like to be able to implement it in experiments with some guessed wait time.

Another application might be in the near future the implementation of some microfluidics. While this might be a more complex problem looking forward, it might be just enough to start/stop pumping. I might know more in a week.

So yes, a generic IO device should be good. I do not understand, though, the link to a temperature logger. That would be a datadevice, right...?

[iandobbie]

The link to the data logger is slightly an aspect of the current implementation which is not in microscope, which runs on a Raspberry Pi and has a code to read a couple of different I2C temperature sensors. However, applications such as microfluidics would also benefit from some way to log factors such as flow rates, pressures temperatures etc... to match up to the experiment timing.

[iandobbie]

As I see it a basic device would need some config, maybe a basic GUI for testing, and then a few basic exposed calls. Off the top of my head I think:

init How many lines available read state one line write state one line read state many/all lines write state many/all lines

Maybe an option to set a line to input or output. simplest approach would set this at init and not be able to change this dynamically.

[iandobbie]

Then there will need to be a related chunk of code in cockpit to present a GUI interface and allow the devices to do what you want them to. I have started a cockpit issue related to this at https://github.com/MicronOxford/cockpit/issues/824

[iandobbie]

I have started to code this beginning with the abc for the class in https://github.com/iandobbie/microscope/tree/DIO

[iandobbie]

I plan an initial concrete implementation on a raspberry pi based on my ancient piDIO code and it probably needs a simulated implementation as well for testing.

[iandobbie]

My DIO branch (https://github.com/iandobbie/microscope/tree/DIO) has the initial implementation based on my thoughts above and a simulated device to enable testing etc....

[iandobbie]

Having looked at the piDIO code from both cockpit and the raspberry pi code (https://github.com/iandobbie/pi-DIO) it is mostly covered.

The raspberry pi code does the hardware setup, just for output data, no digital in, and also setup up possible temperature sensors. Another section of the code is for running it as a linux service to start at boot. I don't think we should include this for now, maybe we need some way to run a device_server in this way? The temp sensor code we can ignore for a first version and think about how best to add this, is it part of the Digital IO device or a separate device?

[iandobbie]

I have done some more work on this but I am a bit unsure about what to call my functions. I currently using set_line to set the line as input or output and set_output to set a specific state. I don't think these names are clear. I think I should use

read_line and write_line to read and write data to a given line, but what is a good name for a function that sets a given line to input or output?

[iandobbie]

I have a working first implementation in https://github.com/iandobbie/microscope/tree/DIO. It has a component in abc and a simulator that should allow basic testing. I will try to implement the cockpit end next so we can test more and also write a real implementation on the Rapsberry PI.

[iandobbie]

I have written the very basic raspberry pi implementation but not yet tested it. I'll try to find the setup pi I lost somewhere in the move and debug the implementation so far.

[iandobbie]

I have this working but am still playing with the cockpit end of. I will wait until I am happy with both the microscope and cockpit components before I commit them to the main branches to ensure the implementation is complete.

[iandobbie]

I have done some more work a few minor issues revealed by simulation and concrete implementation and then getting it to work with the GUI in cockpit. Was all pulled into master in e790a499a2c41db4b22268073fc0fd7f406d0bc1 . Closing this issue will add new issues for updates or improvements.