Additional column in the connection table

[philipstarkey]

Original report (archived issue) by Philip Starkey (Bitbucket: pstarkey, GitHub: philipstarkey).

---

We need an additional column in the connection table for comparing parameters/configurations of specific devices/channels. I propose we have a column for generic "other" data that is stored as the repr of a dictionary.

Current examples of where this is needed:

• If a NovaTech DDS9m is referenced to an external clock, frequency values need to be scaled depending on the reference clock frequency. This reference clock frequency should be stored in the connection table and compared at the usual comparison points.
• I'm currently writing an SLM class for labscript where a given SLM can be split into segments (which will be child devices of the SLM device). The size and position of these segments should be compared as part of the connection table check.

This could possibly be merged in with the BLACS_connection column, however for backwards compatibility I would probably suggest we add a new column in addition to the existing BLACS_connection column.

[philipstarkey]

Original comment by Philip Starkey (Bitbucket: pstarkey, GitHub: philipstarkey).

---

Further thoughts,

We add some methods to the Device class of labscript which allow you to set arbitrary key/value pairs for "Device Properties" that will be stored in the connection table and compared as part of the usual connection table comparisons. This dict is put through repr and stored in a new "device_properties" column of the connection table.

Alternatively, we could just have an attribute containing a dictionary that people directly access, but I'm growing fond of explicit methods to set information like this (so that we can build in type checking, overwriting checking, etc, into those functions)

[philipstarkey]

Original comment by Chris Billington (Bitbucket: cbillington, GitHub: chrisjbillington).

---

• changed assignee_account_id from "557058:cbf1bc43-1dc2-477b-9e25-1a8f40fd7ee3" to "557058:2f99420c-1dbd-4837-952c-82c421b8fbdd"
• changed assignee from "cbillington (Bitbucket: cbillington, GitHub: chrisjbillington)" to "philipstarkey (Bitbucket: philipstarkey, GitHub: philipstarkey)"

Copying from the email thread for the record:

This seems totally fine to me, it makes sense that we want a spot to put arbitrary data that if changed should invalidate the connection table. And a generic getter and setter and the device class seems like a good way to implement it.

You could define __setitem__ and __getitem__ to make the device objects behave like a dictionary with the getting and setting of these properties, but that's a bit magical, an explicit get_property(name) and set_property(name, value) would be more obvious and non-magical as to what was going on.

[philipstarkey]

Original comment by Philip Starkey (Bitbucket: pstarkey, GitHub: philipstarkey).

---

This was implemented in changeset: 6e4f2dbd421f4a94f5c5ae806eece83621af2783

The Device class now has get_property(name, [default]) and set_property(name, value, overwrite = False) methods.

set_property is fairly self explanatory. If a property with identifier name is already set, you must explicitly specify the overwrite flag as True.

The implementation of get_property is a little more complex (to allow teh default value to be specified as None). However, the API interface is simple. If you don't specify a default value, and the property you request has not been set, an exception will be raised. If you do specify a default value, that will be returned if the property has not been set.

Properties can be accessed in BLACS through the connection table objects. These objects have a properties attribute which contains a dictionary keyed by the identifiers (name) specified in the labscript calls.

[philipstarkey]

Original comment by Philip Starkey (Bitbucket: pstarkey, GitHub: philipstarkey).

---

• changed state from "new" to "resolved"