Experiment timing limited by slow component

[neutrinonerd3333]

In our lab, we are trying to run a sequence in which we set an analog output at time $t$ (on an NI 6739 card) followed by a digital output (on a PulseBlaster) at a short time $\Delta t$ later. The PulseBlaster is our primary pseudoclock.

On compiling, labscript complains as follows:

labscript.labscript.LabscriptError:
Commands have been issued to devices attached to pb_pseudoclock at t=0.79504 and t=0.795041.
One or more connected devices on ClockLine clockline_6739
cannot support clock ticks with a digital high time shorter than 1.25e-06
which is more than half the available time
between the event at t=0.79504 on ClockLine clockline_6739
and the next event on another ClockLine.

This even though the 6739 does not need to receive the trigger at $t + \Delta t$.
I came across this discussion from 2022 suggesting that:

• the PulseBlaster only outputs one pseudoclock signal (even though its channels are all independently settable), so every device pseudoclocked by the PulseBlaster will receive every trigger
• the PulseBlaster trigger spacing is thus limited by the device requiring the slowest delay between triggers
• to get distinct pseudoclock signals, the encouraged resolution was to set up a secondary pseudoclock (PrawnBlaster).

Is all this still accurate / timely — still the best way to get the desired timing?

[dihm]

I suspect that understanding/advice is still generally accurate, with two minor additions.

The first point is only approximately correct. Labscript has a concept of gated clocks to help ease this problem. You can have multiple clocklines attached to a single pseudoclock (generally how the pulseblaster functions) and if nothing is happening on one clockline, labscript will gate it even though other clocklines on the pseudoclock are ticking. This feature is largely responsible for why most experiments don't see these issues all day every day. The tricky bit here is likely that the direct outputs of the pulseblaster don't get gated in the same way.

Second, I would now much more strongly suggest you just replace the pulseblaster with a prawnblaster/prawndo set. The prawnblaster provides 4 completely independent pseudoclocks (ie not clocklines) and the prawndo is a simple addition board to provide those easy digital outputs at the same timing resolution. We wrote an RSI detailing the usage if you are interested in more info before committing.

[neutrinonerd3333]

Okay, thanks for the clarification, and apologies for the late reply. I didn't really find a lot of documentation on the scheme of gated clocks (though I recall seeing this in some discussion threads) on the official labscript docs, so perhaps that would be a useful addition.

We'll look into the prawnblaster/prawndo combination for an upcoming setup we are building. At the moment, we're not quite ready to make this switch in our existing setup. Is there an easy way to get the PulseBlaster digital-outs treated in the exact same manner? This seem a purely software limitation that shouldn't be too bad to resolve, but I'm not too familiar with the PulseBlaster code in Labscript.

[dihm]

Is there an easy way to get the PulseBlaster digital-outs treated in the exact same manner? This seem a purely software limitation that shouldn't be too bad to resolve

Famous last words, to be sure. Honestly, given how clocklines are implemented, I wouldn't be surprised if the gating feature was already working for the direct outputs (at least I can't think of a reason it would have been excepted from the functionality). I'm not familiar with the gated clocks logic for how the code decides to gate some pulses but not others, but I suspect it may not have the granularity required to accomplish your goal easily. Put another way, I think the clock gating may actually already be working, but activity nearby your trouble point may be circumventing it.

More specific advice would require example scripts that others can compile easily, and I'm not sure I have the time at the moment anyway. That said, I try hard to assist new contributors so if you take a stab keep me in the loop.

[neutrinonerd3333]

Famous last words, to be sure.

Indeed!