Added pixel_size and magnification attributes to imaqdxcamera

[ispielma]

We are in the process of setting up a new system and in the process of calibrating the camera it became clear that the best place to store information about the pixel size and magnification are as device attributes. So this pull request adds pixel_size and magnification as attributes to IMAQdxCamera.

A follow up on this would be to have the real-time display in blacs use these to compute the axes in real units.

[dihm]

This is a pretty simple change, so I'm happy to merge as is.

A follow up on this would be to have the real-time display in blacs use these to compute the axes in real units.

If you are serious about this in the near-ish future, we may actually want to put these attributes as connection_table_properties instead. Let me see if I can clearly explain why (mostly for posterity since a lot of this detail isn't really documented anywhere).

To begin, despite the names, both device_properties and connection_table_properties are properties of the specific device (another way I might put it, connection_table_properties refers to where the device property is stored, not what it is a property of). The differences between them come down to where they are stored in the h5 file and how they are accessed.

• connection_table_properties are stored in the connection table, and therefore are compared against when comparing the connection table of a shot with the connection table of BLACS. This also means that changes to them require re-compiling the connection-table.
  • You access these values (from the BLACS connection_table) using a labscript_utils.connections.ConnectionTable object, which is provided as an instantiation argument to the BLACSTab. The Tab can be written to pass these values to the BLACSWorker as arguments when the tab starts the worker process(es).
• device_properties are stored as attributes of the device in a shot file. These can change from shot to shot without recompiling the connection table.
  • These are accessed (from each shot) by using labscript_utils.properties which takes the shot h5 file path as an argument. As such, it's really only practical to access these values in the worker transition_to_buffered or transition_to_manual where that path is provided.

So, in short, the general intended design of these is for connection_table_properties to be used for things that don't/shouldn't change from shot to shot, and can be used as arguments to instantiate the BLACSTab and/or BLACSWorker dynamically at runtime. device_properties is for things that can change from shot-to-shot and only need to be accessed when transitioning in and out of buffered.

For this PR, I think a case could be made that these properties really shouldn't change from shot to shot. And it could be nice to use them when defining the Tab so the axis transform could be applied to raw data as already sent from the Worker. Of course, if this is just book-keeping or you would rather the axis transforms happen in the Worker and have the axis ranges communicated to the Tab with the raw data, that's fine too.

Ultimately, just wanted to make sure the choice was made now such that it didn't need to be changed in the near future, and also take advantage of the opportunity to document a more subtle feature somewhere online so I can find it next time I need to remind myself of how all this works.

[ispielma]

David,

I guess I am happy either will solve the problem I am facing. I think there is a case with zoom lenses that the magnification might actually be something that could change from shot to shot. In this niche use case probably the runmanager variable that actually controls the device would not be magnification and would anyway be computed in lyse.

So all said, connection_table_properties make a lot of sense.

— Ian

Ian B. Spielman

Fellow, Joint Quantum Institute National Institute of Standards and Technology and the University of Maryland

----- WEB ----- http://ultracold.jqi.umd.edu

----- EMAIL ----- @.***

----- ZOOM ----- https://umd.zoom.us/j/7984811536

----- PHONE ----- (301) 246-2482

----- MAIL ----- UMD: 2207 Computer & Space Sciences Bldg. College Park, MD 20742

NIST: 100 Bureau Drive, Stop 8424 Gaithersburg, MD 20899-8424 USA

----- OFFICE ----- UMD: Physical Sciences Complex, Room 2153 NIST: Building 216, Room B131

On Feb 16, 2022, at 09:37, David Meyer @.***> wrote:

This is a pretty simple change, so I'm happy to merge as is.

A follow up on this would be to have the real-time display in blacs use these to compute the axes in real units.

If you are serious about this in the near-ish future, we may actually want to put these attributes as connection_table_properties instead. Let me see if I can clearly explain why (mostly for posterity since a lot of this detail isn't really documented anywhere).

To begin, despite the names, both device_properties and connection_table_properties are properties of the specific device (another way I might put it, connection_table_properties refers to where the device property is stored, not what it is a property of). The differences between them come down to where they are stored in the h5 file and how they are accessed.

• connection_table_properties are stored in the connection table, and therefore are compared against when comparing the connection table of a shot with the connection table of BLACS. This also means that changes to them require re-compiling the connection-table. • You access these values (from the BLACS connection_table) using a labscript_utils.connections.ConnectionTable object, which is provided as an instantiation argument to the BLACSTab. The Tab can be written to pass these values to the BLACSWorker as arguments when the tab starts the worker process(es). • device_properties are stored as attributes of the device in a shot file. These can change from shot to shot without recompiling the connection table. • These are accessed (from each shot) by using labscript_utils.properties which takes the shot h5 file path as an argument. As such, it's really only practical to access these values in the worker transition_to_buffered or transition_to_manual where that path is provided. So, in short, the general intended design of these is for connection_table_properties to be used for things that don't/shouldn't change from shot to shot, and can be used as arguments to instantiate the BLACSTab and/or BLACSWorker dynamically at runtime. device_properties is for things that can change from shot-to-shot and only need to be accessed when transitioning in and out of buffered.

For this PR, I think a case could be made that these properties really shouldn't change from shot to shot. And it could be nice to use them when defining the Tab so the axis transform could be applied to raw data as already sent from the Worker. Of course, if this is just book-keeping or you would rather the axis transforms happen in the Worker and have the axis ranges communicated to the Tab with the raw data, that's fine too.

Ultimately, just wanted to make sure the choice was made now such that it didn't need to be changed in the near future, and also take advantage of the opportunity to document a more subtle feature somewhere online so I can find it next time I need to remind myself of how all this works.

— Reply to this email directly, view it on GitHub, or unsubscribe. Triage notifications on the go with GitHub Mobile for iOS or Android. You are receiving this because you authored the thread.

[dihm]

Ian, sorry I let this fall off my radar. Do you want to send a commit to move the new properties to connection_table_properties? If not, I'm pretty sure I can do it (depending on your github settings) though I'm pretty sure that involves me sending commits to your fork directly which I'm not a super fan of.

I'm happy to merge when that's done.

[ispielma]

David,

I finally updated this pull request to store the information as connection table properties.

-- Ian

[dihm]

Thanks! Merging.