You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
If an AnalogOutput on Clockline1 does a ramp and another DigitaOut on Clockline2 should change its state during the ramp (at t=t2), the compile process adds an instruction to both clocklines at t=t2. This additional clock-tick may lead to clock ticks on ClockLine1 which the AnalogOutput card cannot handle
In order to fix this issue the ramp could be split into multiple sections, in which the ClockLine1 emmits pulses at the appropriate ramp samplerate, stop at t2, emmit a single clocktick on Clockline2 and continue ticking an ClockLine1 with the ramp samplerate.
I wrote a (maybe hacky) solution, but it seems to work (see attachment).
In Line 486 "def self.collect_change_times(...)" I collect all times which are during a ramp and return them as list in a dict with the clockline.name as key.
In Line 596: def expand_change_times(), I analyse the split times and check if multiple times belong to the same "split" ( mutliple times are in between two ramp ticks). Also I analyse if a split time is simultaneous to a ramp tick, so the pseudoclock has to emmit clock signals on both ClockLines.
Then the actual ramp instructions are added to the clock list. Afterwards the other instructions are inserted at the correct list index, to keep time ordering.
I also calculate the correct step size for all the clock instructions.
I also attached a runviewer screenshot of a compiled example script. (don't be confused about the short graphs for Cooler_TTL and Oszi_Trigger. This seems to be a bug in our runviewer implementation)
A1_clockline and D1_clockline are the both clocklines. A1_clockline for the AnalogOut TiSa1_Amplitude, D1_clockline for the DigitalOuts Cooler_TTL and Oszi_Trigger.
TiSa1_Amplitude does the ramp.
Cooler_TTL and Oszi_Trigger change their states during the ramp.
I don't think this is the best or cleanest solution, but maybe you can use the idea ;-)
The text was updated successfully, but these errors were encountered:
Original report (archived issue) by ReneKolb (Bitbucket: ReneKolb).
The original report had attachments: labscript.py, screenshot_ramping2_schoen_cropped_harder.png
If an AnalogOutput on Clockline1 does a ramp and another DigitaOut on Clockline2 should change its state during the ramp (at t=t2), the compile process adds an instruction to both clocklines at t=t2. This additional clock-tick may lead to clock ticks on ClockLine1 which the AnalogOutput card cannot handle
In order to fix this issue the ramp could be split into multiple sections, in which the ClockLine1 emmits pulses at the appropriate ramp samplerate, stop at t2, emmit a single clocktick on Clockline2 and continue ticking an ClockLine1 with the ramp samplerate.
I wrote a (maybe hacky) solution, but it seems to work (see attachment).
In Line 486 "def self.collect_change_times(...)" I collect all times which are during a ramp and return them as list in a dict with the clockline.name as key.
In Line 596: def expand_change_times(), I analyse the split times and check if multiple times belong to the same "split" ( mutliple times are in between two ramp ticks). Also I analyse if a split time is simultaneous to a ramp tick, so the pseudoclock has to emmit clock signals on both ClockLines.
Then the actual ramp instructions are added to the clock list. Afterwards the other instructions are inserted at the correct list index, to keep time ordering.
I also calculate the correct step size for all the clock instructions.
I also attached a runviewer screenshot of a compiled example script. (don't be confused about the short graphs for Cooler_TTL and Oszi_Trigger. This seems to be a bug in our runviewer implementation)
A1_clockline and D1_clockline are the both clocklines. A1_clockline for the AnalogOut TiSa1_Amplitude, D1_clockline for the DigitalOuts Cooler_TTL and Oszi_Trigger.
TiSa1_Amplitude does the ramp.
Cooler_TTL and Oszi_Trigger change their states during the ramp.
I don't think this is the best or cleanest solution, but maybe you can use the idea ;-)
The text was updated successfully, but these errors were encountered: