Original report (archived issue) by Philip Starkey (Bitbucket: pstarkey, GitHub: philipstarkey).

There is a bug in labscript where the non-looping clock ticks can be too short.

This is because ramps (a looping clock) is broken up into two pseudoclock instructions*, the first where non-looping clocks and looping clocks tick, and then second where only looping clocks tick. However, the maximum rate is calculated based on the fastest ramp, and the maximum allowed ramping rate (the local_clock_limit) determined by ramping clockline. This then ignores the clock limit for clocklines that are not ramping, but need updating during the first tick of the ramp.

I'm not sure what the fix should be. We have options like:

1. Force the maximum ramp rate to be limited by the clock limit of any non-ramping clocks that are commanded at the start/end or during a ramp (this is likely to make everyone's existing labscript files fail to compile)

2. Somehow break the ramps at the pseudoclock device instruction level so that non-looping clocks have a period that matches the length of the looping clock ramp (this seems quite complicated to implement though as I think it breaks the current structure of the internal representation of pseudoclock instructions). Effectively this would mean we revert to the slow/fast clock system we had a long time ago (but it would be better because the slow/fast determination is made on a per ramp basis, and we'd still maintain gating)

3. ??

Looking for other better suggestions!

Notes:

* by this I mean the internal labscript dictionary that describes the pseudoclock instructions, which may translate to more pseudoclock device instructions depending on how many device instructions you need per clock tick