philipstarkey
commented
5 years ago Original comment by Philip Starkey (Bitbucket: philipstarkey, GitHub: philipstarkey).
Hi David,
I think in general adding a enum output type makes sense (but not sure if it is what you want for this device or not)
However, if these are just configuration settings, they probably shouldn’t be integrated with the output types of BLACS and labscript. In such a case I would probably suggest just adding additional widgets to your device’s BLACS tab as, for example, the PulseBlaster does for status widgets.
But, assuming it makes sense to go down the route of integrating it as an “output type”, here is the information you need to know!
BLACS
The fundamental level is the AO/DO/DDS/Image output classes. Instances of these we call “output objects” and are ultimately what store the front panel value, interact with saving/restoring settings and trigger events to reprogram the device via the statemachine and worker process. Think of these as a datastore (one per output channel). They are created by the DeviceTab.create_XX_outputs methods.
Widgets can then be created and linked to the output object. We provide the DeviceTab.auto_create_widgets and AO.create_widget (and equivalent for the other classes) methods to streamline this, but actually any appropriate widget can be connected in to the output object (datastore), see the add_widget method of each output class. A BLACS tab can use whatever method it likes to create the widget, it just needs to call appropriate methods to link the widget to the output object. Each output object can have an arbitrary number of widgets connected to it, and they’ll all update together when one changes.
We then have a method to automatically place widgets in collapsible groups (DeviceTab.auto_place_widgets). This is completely optional as you can place widgets in the tab however you like (or do both like the PulseBlaster).
So for your situation, you probably want to create an Enum output class in output_classes.py, update DeviceTab to handle the new output type. You can then opt to create widgets manually, or using the newly created automatic methods, and place them in a custom layout of your choosing for a particular device by bypassing auto_place_widgets.
labscript
On the labscript side you will want to subclass Output and create an EnumOut and StaticEnumOut classes. These would be similar to DigitalOut I guess, but have more states.
To be honest I’m not sure if it makes sense to treat them as output types or not…it almost seems like not (they seem more like labscript device instantiation arguments?), but in that case BLACS has no machinery for allowing device configuration to be modified in manual mode. It all has to be implemented separately in each device tab, which doesn’t seem ideal.
Original report (archived issue) by David Meyer (Bitbucket: dihm, GitHub: dihm).
When programming devices with physical front panels, it is often the case that a control I’d like to manipulate with labscript (at a static level) is best described as an enum (looking at you SRS). I propose we add a basic combobox based widget (like AnalogOutput or DigitalOutput) that can be stuffed with a dictionary of labels and programming values at runtime from the device blacs tab. These controls do not always have an associated output or input class associated with them, rather being a device level setting that influences general operation.
I’m happy to work on this one since we have a current need, but I’d like a bit of guidance on how to integrate with the rest of the BLACS auto-creation of widgets magic. If I have understood correctly, the current paradigm for an AnalogOutput widget is to have the device_tab call a widget auto-populating function which creates AnalogOutput widgets which in turn links to the labscript AO class. This ensures settings from the connection table and blacs tab can configure each output correctly. What is the best way to modify this paradigm?
My initial thought is to drop auto-populating in the blacs_tab in favor writing something akin to ddsoutput.py for any (often conglomerate) control that would be device specific and kept in the device folder. I’m a little less clear on how to handle enum settings at the AO class level. Should I create a commensurate class that behaves as a StaticAO with discrete values set by dictionary?
Anyway, this is starting to get long and likely confusing since I don’t really know what I’m talking about. So I’ll end by describing what our need is and what I would like to see.
We have an RF Signal Generator (SRS SG386) that has modulation controls. The controllable options include: Enable (on/off), Type (AM/FM/PM/Sweep), Function (Sine, Triangle, Square, External), Deviation (float), Depth (float), and External Coupling (AC/DC). Since all of these controls are inter-related and operate on the same function, it would be nice to create a monolithic control widget that groups them together in the BLACS tab and allows user control while enforcing allowable settings. Slightly beyond the scope of this discussion, when writing an experiment script; having corresponding SG386.mod(Enable) and/or SG386.mod.Depth(1MHz) commands would be great. Getting started, StaticAO/DO covers the boolean and float options just fine. But I need an enum for everything else.