Module containing labscript suite hardware compatibility, separate from the main programs. Device compatibility is implemented with a plugin architecture, for modularity and extensibility. Each file in this module contains a labscript device class, a BLACS tab class, a BLACS worker class and a runviewer parser class for a particular device. These implement functionality for the device which the programs in question call on when they encounter each device in user labscript code, hdf5 files, or connection tables.
0
stars
0
forks
source link
Pulseblaster with 2323 firmware turns off all outputs during programming #23
We have two pulseblasters in the lab with firmwares 2323 and 3338. For whatever reason the 2323 firmware version disables all digital outputs when pb_start_programming() is called and it appears they don't re-enable until pb_start(). There isn't really anything we can do about that in particular, but it would be nice if pb_start_programming() wasn't called unnecessarily (for the sake of compatibility with the STOP programming method) so my digital lines could stay high between most of my shots, keeping the experiment warm.
I'm using the following diff without issue so far. Am I missing any other edge cases?
#!diff
@@ -341,18 +341,13 @@
pulse_program = group['PULSE_PROGRAM'][2:]
#Let's get the final state of the pulseblaster. z's are the args we don't need:
- flags,z,z,z = pulse_program[-1]
-
- # Always call start_programming regardless of whether we are going to do any
- # programming or not. This is so that is the programming_scheme is 'pb_stop_programming/STOP'
- # we are ready to be triggered by a call to pb_stop_programming() even if no programming
- # occurred due to smart programming:
- pb_start_programming(PULSE_PROGRAM)
+ flags,z,z,z = pulse_program[-1]
if fresh or (self.smart_cache['initial_values'] != initial_values) or \
(len(self.smart_cache['pulse_program']) != len(pulse_program)) or \
(self.smart_cache['pulse_program'] != pulse_program).any() or \
not self.smart_cache['ready_to_go']:
+ pb_start_programming(PULSE_PROGRAM)
self.smart_cache['ready_to_go'] = True
self.smart_cache['initial_values'] = initial_values
@@ -385,17 +380,22 @@
for args in pulse_program:
pb_inst_pbonly(*args)
- if self.programming_scheme == 'pb_start/BRANCH':
- # We will be triggered by pb_start() if we are are the master pseudoclock or a single hardware trigger
- # from the master if we are not:
- pb_stop_programming()
+ if self.programming_scheme == 'pb_start/BRANCH':
+ # We will be triggered by pb_start() if we are are the master pseudoclock or a single hardware trigger
+ # from the master if we are not:
+ pb_stop_programming()
+ elif self.programming_scheme == 'pb_stop_programming/STOP':
+ # Don't call pb_stop_programming(). We don't want to pulseblaster to respond to hardware
+ # triggers (such as 50/60Hz line triggers) until we are ready to run.
+ # Our start_method will call pb_stop_programming() when we are ready
+ pass
+ else:
+ raise ValueError('invalid programming_scheme %s'%str(self.programming_scheme))
elif self.programming_scheme == 'pb_stop_programming/STOP':
- # Don't call pb_stop_programming(). We don't want to pulseblaster to respond to hardware
- # triggers (such as 50/60Hz line triggers) until we are ready to run.
- # Our start_method will call pb_stop_programming() when we are ready
- pass
- else:
- raise ValueError('invalid programming_scheme %s'%str(self.programming_scheme))
+ # Ensure start_programming called if the programming_scheme is 'pb_stop_programming/STOP'
+ # so we are ready to be triggered by a call to pb_stop_programming()
+ # even if no programming occurred due to smart programming:
+ pb_start_programming(PULSE_PROGRAM)
# Are there waits in use in this experiment? The monitor waiting for the end of
# the experiment will need to know:
Original report (archived issue) by David Meyer (Bitbucket: dihm, GitHub: dihm).
We have two pulseblasters in the lab with firmwares 2323 and 3338. For whatever reason the 2323 firmware version disables all digital outputs when pb_start_programming() is called and it appears they don't re-enable until pb_start(). There isn't really anything we can do about that in particular, but it would be nice if pb_start_programming() wasn't called unnecessarily (for the sake of compatibility with the STOP programming method) so my digital lines could stay high between most of my shots, keeping the experiment warm.
I'm using the following diff without issue so far. Am I missing any other edge cases?