Is it really true that the trigger of a NovaTech device disables ALL pulseblaster digital operations for +/- 100us, even for digital lines that are independent of the novatech clockline? The hardware can trivially handle pulsing one output faster than a different output, it is hard to believe the software would be thus limited.
Thanks,
Trey
--
You received this message because you are subscribed to the Google Groups "the labscript suite" group.
To unsubscribe from this group and stop receiving emails from it, send an email to labscriptsuit...@googlegroups.com.
To view this discussion on the web, visit https://groups.google.com/d/msgid/labscriptsuite/478ad9a2-08e3-4696-b1cd-4048f51958a5n%40googlegroups.com.
Is it really true that the trigger of a NovaTech device disables ALL pulseblaster digital operations for +/- 100us, even for digital lines that are independent of the novatech clockline? The hardware can trivially handle pulsing one output faster than a different output, it is hard to believe the software would be thus limited.
To view this discussion on the web, visit https://groups.google.com/d/msgid/labscriptsuite/CAKy3cVuG6S5YfJe5tROTvyDry6jKYjLyqALxwJL66EPXYeAoDg%40mail.gmail.com.
Before I get into specifics, can I check that you are not explicitly requesting output at t=0? That error message is also common to setups that have secondary pseudoclocks that need to be triggered (done automatically by labscript), but where the script tries to command output at t=0 instead of t = start(). It looks like our example script makes this mistake too (but coincidentally avoids an exception by specifying an explicit initial trigger time for the secondary pseudoclock...).
In short, yes. Due to the complex abstract clock generation system we developed, we don't support overlapping pulses of different lengths unless they're on independent pseudoclocks (where independent pseudoclocks implies that the instruction set for each is separable). Pulses within ramps on a single pseudoclock are fine as long as they are not faster than the maximum update rate of the ramping device. Faster pulses are also allowed if you aren't trying to simultaneously command the slower device.
As you point out, the PulseBlaster hardware can support overlapping pulses of different lengths when not ramping (not generating an instruction loop with op-codes), but as far as I know, it's the only pseudoclock device supported by the labscript suite that would support it. We didn't want to vendor-lock to the PulseBlaster when developing labscript and special-casing it would be a lot of work (but not impossible if someone wanted to do it).
As Chris linked, the NovaTech is a bit of a special case in the labscript suite as it's maximum update rate is not actually linked to the minimum pulse length by a 50% duty cycle as labscript assumes. This has lead to the issue where early versions of labscript allowed you to update the NovaTech so fast it would miss instructions (potentially randomly) without raising any error, but later versions of labscript prevent you from updating other devices on shared pseudoclocks as fast as you technically can without skipping NovaTech instructions. If you are happy with the protection removed, you can revert the commit Chris linked to.
Personally, given the development and price reduction of pseudoclocks, I'm in favour of clocking NovaTechs with separate pseudoclocks. The PrawnBlaster, for example, can clock up to 4 NovaTechs independently for $4USD (and can be easily synchronised to a 10-100MHz LVTTL external reference). As far as I'm aware, this would work around all lingering issues with labscript and the NovaTech update rate.
Thanks, Chris and Phil for the quick responses. I'm glad there is a quick fix.I'm new to labscript, so forgive me if these questions are answered somewhere obvious. (I should probably read the original paper....)
In short, yes. Due to the complex abstract clock generation system we developed, we don't support overlapping pulses of different lengths unless they're on independent pseudoclocks (where independent pseudoclocks implies that the instruction set for each is separable). Pulses within ramps on a single pseudoclock are fine as long as they are not faster than the maximum update rate of the ramping device. Faster pulses are also allowed if you aren't trying to simultaneously command the slower device.I'm confused as to how the software pulse generator works. At the hardware level, a pseudoclock has an underlying timebase clock which sets the times at which the digital output can change states, but it can output any digital state on a given timebase clock transition. In order for two outputs to have pulses with different lengths, the pseudoclock merely commands the line with the longer pulse to "stay high" when the shorter pulse line "goes low":(00) --> (11) --> (01)--> (00)When you say "we don't support overlapping pulses of different lengths", I assume you mean the clock lines triggering child devices, not the digital output lines. (otherwise you couldn't hold open a shutter for 5ms while you provided a 100us pulse of imaging light.)
As you point out, the PulseBlaster hardware can support overlapping pulses of different lengths when not ramping (not generating an instruction loop with op-codes), but as far as I know, it's the only pseudoclock device supported by the labscript suite that would support it. We didn't want to vendor-lock to the PulseBlaster when developing labscript and special-casing it would be a lot of work (but not impossible if someone wanted to do it).When you say the pulseblaster is "the only pseudoclock device supported by the labscript suite that would support" pulses of different lengths, I don't understand how a pseudoclock could physically work without being capable of supporting overlapping pulses of different lengths. Limited only by the underlying timebase clock period T, a digital output device requesting, e.g.(00)-->(01) -->(11)-->(10)-->(00) or(00)-->(01) -->(11)-->(01)-->(00)could output two overlapping pulses with arbitrary start times and widths (modulo T).
As Chris linked, the NovaTech is a bit of a special case in the labscript suite as it's maximum update rate is not actually linked to the minimum pulse length by a 50% duty cycle as labscript assumes. This has lead to the issue where early versions of labscript allowed you to update the NovaTech so fast it would miss instructions (potentially randomly) without raising any error, but later versions of labscript prevent you from updating other devices on shared pseudoclocks as fast as you technically can without skipping NovaTech instructions. If you are happy with the protection removed, you can revert the commit Chris linked to.What does "it's maximum update rate is not actually linked to the minimum pulse length by a 50% duty cycle" mean? Perhaps my confusion is based on not understanding what labscript calls a "pulse". I understand a pseudoclock device to be a digital word generator for which you specify the digital outputs and the times at which those outputs change. A "pulse" on any given line is the total time between that lines' "gohigh" transition and "golow" transition. Within that framework, I don't understand what "50% duty cycle" means.
Personally, given the development and price reduction of pseudoclocks, I'm in favour of clocking NovaTechs with separate pseudoclocks. The PrawnBlaster, for example, can clock up to 4 NovaTechs independently for $4USD (and can be easily synchronised to a 10-100MHz LVTTL external reference). As far as I'm aware, this would work around all lingering issues with labscript and the NovaTech update rate.That is certainly a cost effective solution we will explore. Its just that we had a working software solution, and the existing hardware is capable of doing it. Our original design had a single pseudoclock device in part so that we didn't have to farm around a separate timebase for all the devices.
To view this discussion on the web, visit https://groups.google.com/d/msgid/labscriptsuite/69e7f50c-569c-4158-8188-3c000d502485n%40googlegroups.com.
This isn’t actually quite true
I am with Trey in that I can’t see _any_ reason for this check.
--
You received this message because you are subscribed to the Google Groups "the labscript suite" group.
To unsubscribe from this group and stop receiving emails from it, send an email to labscriptsuit...@googlegroups.com.
To view this discussion on the web, visit https://groups.google.com/d/msgid/labscriptsuite/42CA9AD0-E661-4646-A013-71AFCD241BC3%40umd.edu.
To view this discussion on the web, visit https://groups.google.com/d/msgid/labscriptsuite/FFF62F8A-82AA-41E7-A359-13E96A8A27E1%40umd.edu.
You received this message because you are subscribed to a topic in the Google Groups "the labscript suite" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/labscriptsuite/QdW6gUGNwQ0/unsubscribe.
To unsubscribe from this group and all its topics, send an email to labscriptsuit...@googlegroups.com.
To view this discussion on the web, visit https://groups.google.com/d/msgid/labscriptsuite/FFF62F8A-82AA-41E7-A359-13E96A8A27E1%40umd.edu.