The labscript Python library provides a translation from simple Python code to complex hardware instructions. The library is used to construct a "connection table" containing information about what hardware is being used and how it is interconnected. Devices described in this connection table can then have their outputs set by using a range of functions, including arbitrary ramps.
BSD 2-Clause "Simplified" License
0
stars
0
forks
source link
A clockline's clock_limit is effectively limited by another's while that other clockline is ramping. #6
There are two clocklines on a pseudoclock; clockline_a and clockline_b. The clock_limits of these two clocklines are significantly less than the maximum update rate of the pseudoclock. There is a channel on clockline_a that is ramping. During this ramp, there is a channel on clockline_b which is being issued "constant" commands.
Currently, the constant commands will result in the ramp being broken into several parts, with the first clock_tick of each ramp/loop being used to also update clockline_b to its next constant value.
This means that clockline_b is effectively limited to the update rate of clockline_a while clockline_a is ramping. There is however, no reason why the pseudoclock loop couldn't be broken, a command issued to tick clockline_b, and later the loop for clockline_a resumed. As long as the pseudoclock update rate is fast enough, you can effectively have the clocklines independently tick of each other in many circumstances.
Original report (archived issue) by Philip Starkey (Bitbucket: pstarkey, GitHub: philipstarkey).
Consider the following scenario.
There are two clocklines on a pseudoclock; clockline_a and clockline_b. The clock_limits of these two clocklines are significantly less than the maximum update rate of the pseudoclock. There is a channel on clockline_a that is ramping. During this ramp, there is a channel on clockline_b which is being issued "constant" commands.
Currently, the constant commands will result in the ramp being broken into several parts, with the first clock_tick of each ramp/loop being used to also update clockline_b to its next constant value.
This means that clockline_b is effectively limited to the update rate of clockline_a while clockline_a is ramping. There is however, no reason why the pseudoclock loop couldn't be broken, a command issued to tick clockline_b, and later the loop for clockline_a resumed. As long as the pseudoclock update rate is fast enough, you can effectively have the clocklines independently tick of each other in many circumstances.