You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We should save all of the device attributes if they are relevant down stream. For example, things like clock_resolution, wait_delay, trigger_delay, etc. of PseudoclockDevices should be stored so that they can be accessed by runmanager. I think these should probably be stored in the device properties in the base class definitions (PseudoclockDevice and IntermediateDevice), leaving it up to the device class maintainer to decide if they should also be saved in the connection table properties (which would force connection table recompilation and prevention of old shots from being re-run if something in the class was updated).
runviewer and BLACS would then access this information rather than relying on the labscript using the same version of the device class, with the same parameters, as runviewer and BLACS (which could even be running on separate PC's)
The text was updated successfully, but these errors were encountered:
…l request labscript-suite#29)
Configurable trigger slope for the timeout trigger device of a wait monitor
Approved-by: Chris Billington <[email protected]>
Original report (archived issue) by Philip Starkey (Bitbucket: pstarkey, GitHub: philipstarkey).
We should save all of the device attributes if they are relevant down stream. For example, things like
clock_resolution
,wait_delay
,trigger_delay
, etc. ofPseudoclockDevice
s should be stored so that they can be accessed by runmanager. I think these should probably be stored in the device properties in the base class definitions (PseudoclockDevice
andIntermediateDevice
), leaving it up to the device class maintainer to decide if they should also be saved in the connection table properties (which would force connection table recompilation and prevention of old shots from being re-run if something in the class was updated).runviewer and BLACS would then access this information rather than relying on the labscript using the same version of the device class, with the same parameters, as runviewer and BLACS (which could even be running on separate PC's)
The text was updated successfully, but these errors were encountered: