BLACS, part of the labscript suite, provides an interface to hardware used to control a buffered experiment. It manages a queue of shots to be run as well as providing manual control over devices between shots.
Other
0
stars
0
forks
source link
BLACS should check the labscript version used to compile the connection table #4
Ran into a bug today where I tried to open BLACS (1.1.0-dev/gated-clocks) with a connection table compiled pre gated-clocks. BLACS threw an obtuse error about a variable being a string object and not having the 'name' attribute (hint: it shouldn't have been a string!)
I've fixed the specific issue (PulseBlaster code was overriding a method and returning a non-empty string) but it occurs to me that if you launch a newly upgraded version of BLACS/labscript, it should probably prompt you to update and recompile the connection table before launching BLACS.
Of course, all our code should be backwards compatible to some degree (BLACS should always be able to start) but the thing that won't be is the saving/restoring BLACS front panel state. A bunch of outputs may get reset to 0 if they can't be found in the connection table because the hierarchy of devices has changed (as it did in gated-clocks). This could be a pain for people (eg for us, PulseBlasters trigger on a digital low)
Should we do this checking and prompt for recompilation, or classify this as a "wont fix" and make people deal with the consequences for the few times where the devices hierarchy of labscript changes significantly?
Original report (archived issue) by Philip Starkey (Bitbucket: pstarkey, GitHub: pstarkey).
Ran into a bug today where I tried to open BLACS (1.1.0-dev/gated-clocks) with a connection table compiled pre gated-clocks. BLACS threw an obtuse error about a variable being a string object and not having the 'name' attribute (hint: it shouldn't have been a string!)
I've fixed the specific issue (PulseBlaster code was overriding a method and returning a non-empty string) but it occurs to me that if you launch a newly upgraded version of BLACS/labscript, it should probably prompt you to update and recompile the connection table before launching BLACS.
Of course, all our code should be backwards compatible to some degree (BLACS should always be able to start) but the thing that won't be is the saving/restoring BLACS front panel state. A bunch of outputs may get reset to 0 if they can't be found in the connection table because the hierarchy of devices has changed (as it did in gated-clocks). This could be a pain for people (eg for us, PulseBlasters trigger on a digital low)
Should we do this checking and prompt for recompilation, or classify this as a "wont fix" and make people deal with the consequences for the few times where the devices hierarchy of labscript changes significantly?