Closed philipstarkey closed 6 years ago
Original comment by Chris Billington (Bitbucket: cbillington, GitHub: chrisjbillington).
labscript 3 (in progress, to be resumed post-thesis-submission) has a solution to this by quantising correctly based on the time since the wait preceding a given instruction.
To do similar here, one might want to modify quantise_to_pseudoclock()
to partition the change times based on which wait preceded them, and then quantise them in terms of the time since the last wait, rather than the time since t=0.
The wait times themselves, when quantised to how long its been since themselves, will remain unchanged, which is what should resolve the root cause of this issue.
Original comment by Russell Anderson (Bitbucket: rpanderson, GitHub: rpanderson).
Original comment by Philip Starkey (Bitbucket: pstarkey, GitHub: philipstarkey).
While I agree that modifying the code to quantise relative to each trigger point (as if t=0 each trigger time) is the best solution to resolving the issue, I suspect it's more practical to leave that until the next major version of labscript.
I actually think the bug might just be that we quantise the stop time and don't quantise the trigger times here. I'm not sure if there would be a lingering issue with the fact that the outputs offset their instructions times using pre-quantised trigger times (and then quantise after the subtraction) but I suspect that the rounding to 0.1ns we do everywhere probably prevents issues with that (by removing floating point rounding errors).
Russ, do you want to try adding self.trigger_times = self.quantise_to_pseudoclock(self.trigger_times)
at the bottom of PseudoclockDevice.offset_instructions_from_trigger
to see if it fixes it?
Original comment by Chris Billington (Bitbucket: cbillington, GitHub: chrisjbillington).
Absolutely happy with the quickest solution that resolves immediate problems, if this solves it!
Original comment by Russell Anderson (Bitbucket: rpanderson, GitHub: rpanderson).
... try adding
self.trigger_times = self.quantise_to_pseudoclock(self.trigger_times)
at the bottom ofPseudoclockDevice.offset_instructions_from_trigger
to see if it fixes it?
This fixed it.
Original comment by Chris Billington (Bitbucket: cbillington, GitHub: chrisjbillington).
Resolves issue #47, where WAIT instructions were not issued to a clock.
→ \<\<cset fe191967e3a6d37c1793ddb0ca877479d9822f9f>>
Original report (archived issue) by Russell Anderson (Bitbucket: rpanderson, GitHub: rpanderson).
The quantisation of change times via
quantise_to_pseudoclock
(pull request #14) has introduced a bug to waits. Wait instructions are not always appended to the clock instructions, as:clock.append('WAIT')
being run is contingent on the equality of two floats, an element ofall_change_times
and an element ofself.parent_device.trigger_times[1:]
.all_change_times
has hadquantise_to_psuedoclock
applied, whereasself.parent_device.trigger_times
has not.This bug arises in the following (using 1f04a62168fd74de95d16027b26b97f7a24ebafa) for various values of
t_wait
:The bug can be detected by adding a print statement before/after
clock.append('WAIT')
in labscript.py, or by appending the following to the above labscript (afterstop(t)
):It seems to be that non-integer multiples of
1/ni_pcie_6363_0.clock_limit
reliably result in the missingWAIT
instruction. A potential solution is to quantise the trigger times before checking each element ofall_change_times
for membership ofself.parent_device.trigger_times[1:]
:... or check for proximity of the differently conditioned times rather than equality.