novatech limiting all digital lines' timing

[Trey Porto]

hi All,

We are migrating an old Labview based computer control and data acquisition setup to a labscript based system. After some effort we have everything installed and nominally working correctly with the hardware (consisting of a PulseBlaster, some NovaTechs and some NI-DAQ devises).

On our very first test script, we asked for a pulseblaster pulse simultaneous to a novatech update. If the PulseBlaster pulse width is less than ~100us, the system errors with:

"Commands have been issued to devices attached to pulseblaster_0_pseudoclock at t= 0.0 s and 1e-05 s. One or more connected devices on ClockLine NovaTech_2_clock cannot support update delays shorter than 0.0001001001001001001 sec.

Compilation aborted"

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

[Chris Billington]

Hi Trey,

This is a known issue, and the latest discussion (with links to previous discussions) is from Ian here: https://github.com/labscript-suite/labscript/issues/85, with a reply from Phil here: https://groups.google.com/g/labscriptsuite/c/XECwdgruYl0

This limitation didn't used to exist, but some error checking designed to solve a related issue introduced it. A proper fix is still forthcoming, but in the meantime you can remove the limitation by reverting this commit:

https://github.com/labscript-suite/labscript/commit/957af9352b89a67beb7e5a824ba618736f908fe5

(Or just replace the "raise LabscriptError" line with print("warning: ") or similar instead). This will very likely cause no problems for you.

I had that commit reverted in most of the UMD/NIST labs I had anything to do with, but never got around to reverting it (or replacing with a warning) in the main repository. I'll take a look soon and at the very least replace it with a warning if I or anyone else doesn't have the time to implement the correct fix in the near future.

Regards,

Chris

--
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.

[Philip Starkey]

Hi Trey,

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...).

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.

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.

Cheers,
Phil

To view this discussion on the web, visit https://groups.google.com/d/msgid/labscriptsuite/CAKy3cVuG6S5YfJe5tROTvyDry6jKYjLyqALxwJL66EPXYeAoDg%40mail.gmail.com.

--

Dr Philip Starkey

Senior Technician (Lightboard developer)

School of Physics & Astronomy

Monash University

10 College Walk, Clayton Campus

Victoria 3800, Australia

[Trey Porto]

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....) 

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...).

 no, that was ok. 

 

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.

 

Thank you for your patience with a newbie,

Trey

[Philip Starkey]

Hi Trey,

No worries, I'll try and provide some more details of how the labscript algorithms were designed.

A pseudoclock in labscript is a device that produces a single, variable frequency clock. While the frequency of the clock can change, it's duty cycle is always 50%. For simplicity, we have not attempted to implement more than one pseudoclock output on a device if it can only be programmed with one set of hardware instructions. The PulseBlaster is programmed with one set of instructions so it has 1 pseudoclock. This is the case for all pseudoclocks except the PrawnBlaster, which can be programmed with up to 4 independent instruction sets (so it can have up to 4 pseudoclocks).

To mitigate this limitation, we support secondary pseudoclocks (triggered by a device clocked by the primary pseudoclock). We also allow a variable frequency clock to be output on multiple digital lines, and to gate those lines (where, roughly speaking, the gating on a particular line can turn on/off at the times where the clock frequency changes).

The rate required for the pseudoclock is pretty straight forward for analog ramps. It's whatever rate you want to sample the ramp at.

For single value updates (e.g. calls to channel.constant(...) or similar), the pseudoclock rate at that point in time is related to the time between the update and the next ramp or single value update. Once stop() is called in the labscript experiment logic file, we look at all the times outputs have been requested to change, and ensure that the variable frequency clock will not tick too fast for the devices (like NovaTechs/NI Cards) to detect.

As labscript assumes a 50% duty cycle for the clock, and the Novatech can't be updated faster than about 10kHz, we enforce a time of 100us between an update to the NovaTech and whatever comes next, in order to provide sufficient time for the (50us high, 50us low) clock tick that labscript believes is required for the NovaTech to register the clock signal.

This makes sense for many devices, but the NovaTech can actually detect much shorter "high" times (I think possibly as short as 100ns?). It still can't be updated faster than 10kHz though regardless.

So before the change in the code Chris pointed you to, you could take advantage of the bug in labscript to trigger the NovaTech with shorter pulses, but only as long as you were manually keeping track of how fast you were changing the NovaTech's output. If you requested changes in NovaTech output state that were only 10us apart, labscript would not warn you that this was beyond the capabilities of the device, and the changes in NovaTech output would be offset temporally resulting in wildly unpredictable behaviour (e.g. you might end up with the amplitude/frequency you intended to set between times T1 and T2 actually come out between T2 and T3, which could be very different lengths of time and at the wrong point in your experiment cycle).

I hope this makes sense so far.

The additional bit of information I haven't covered is that the PulseBlaster outputs can also be used as DigitalOuts, not ClockLines. However, to simplify the generation of the PulseBlaster instruction set, we treat state changes on these digital outputs as if they were connected to the Pseudoclock. This way we don't have to try and generate complex PulseBlaster instruction sets. There is an optimisation in place to relax this restriction if a PulseBlaster is not being used to generate a pseudoclock signal (e.g. just being used for digital outputs).

So in theory, your original issue could be solved by either adding support for asymmetric pseudoclock pulses, or more complex instruction optimisation for the PulseBlaster so that digital lines can be commanded asynchronously to the Pseudoclock ticks. But these have not been a priority for anyone yet (I believe support for asymmetric clock ticks is on Chris's development roadmap though).

I hope that explains things in more details. I've also attempted short answer to your explicit questions below. I think a lot of your questions are answered by the above (I tried to include this information in direct answers to your questions but it was seeming even more confusing so I just broke it out into the single explanation above!). If I've missed something, or you'd like further clarification, let me know!

Cheers,
Phil

On Wed, 2 Feb 2022 at 22:22, Trey Porto <po...@umd.edu> wrote:

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....) 

No worries, happy to explain as much as I can. 

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.)

 

Correct, I was speaking about pseudoclock pulses only. You can definitely create complex overlapping pulse sequences with an NI card clocked by the PulseBlaster. By "pulse" I mean(t) a single cycle of a 50% duty cycle square wave (apologies for the inaccurate name. I probably should have said "clock tick").

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). 

Yes, but at the cost of a lot of hardware instructions in the pseudoclock (or you'd require complex Python code required to optimise it down). The PulseBlasters we designed for only have a couple of thousand instructions, which was barely sufficient IIRC. Most other devices that can generate pseudoclocks for the labscript suite are single output as well.

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.

I hope I've explained this sufficiently above. The NovaTech has a maximum update rate of 100us, but a minimum pulse time of much less than half of that. This is unusual at least for devices the labscript suite supports. The labscript algorithms were written assuming pseudoclock ticks were symmetric (equal high and low time) - e.g. a clock with a 50% duty cycle.

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.

Understandable. We we're farming a GPS locked 10MHz around for multiple reasons anyway, so much of our previous development direction assumed a low barrier to adding additional secondary pseudoclocks.

To view this discussion on the web, visit https://groups.google.com/d/msgid/labscriptsuite/69e7f50c-569c-4158-8188-3c000d502485n%40googlegroups.com.

[Ian B. Spielman]

Phil, Trey and all,
.

>
> So before the change in the code Chris pointed you to, you could take advantage of the bug in labscript to trigger the NovaTech with shorter pulses, but only as long as you were manually keeping track of how fast you were changing the NovaTech's output. If you requested changes in NovaTech output state that were only 10us apart, labscript would not warn you that this was beyond the capabilities of the device, and the changes in NovaTech output would be offset temporally resulting in wildly unpredictable behaviour (e.g. you might end up with the amplitude/frequency you intended to set between times T1 and T2 actually come out between T2 and T3, which could be very different lengths of time and at the wrong point in your experiment cycle).

This isn’t actually quite true. There are two relevant error checks going on in the code. The first one confirms than on a single line of the pseudoclock that there are no requested updates that are too fast (thus verifying that the novatech is not triggered too fast), then there is a second check that makes sure that _no_ other outputs of the pseudoclock are triggered faster than the novatech can accept. It is this second check that makes no sense in this context since the output of these other channels is irrelevant to the novatech.

Here is the code at line 826 that is relevant


# Check that no two instructions are too close together:
for i, t in enumerate(change_time_list[:-1]):
dt = change_time_list[i+1] - t
if dt < 1.0/clock_line.clock_limit:
raise LabscriptError('Commands have been issued to devices attached to clockline %s at t= %s s and %s s. '%(clock_line.name, str(t),str(change_time_list[i+1])) +
'One or more connected devices on ClockLine %s cannot support update delays shorter than %s sec.'%(clock_line.name, str(1.0/clock_line.clock_limit)))

all_change_times_len = len(all_change_times)
# increment j until we reach the current time
while all_change_times[j] < t and j < all_change_times_len-1:
j += 1
# j should now index all_change_times at "t"
# Check that the next all change_time is not too close (and thus would force this clock tick to be faster than the clock_limit)
dt = all_change_times[j+1] - t
if dt < 1.0/clock_line.clock_limit:
raise LabscriptError('Commands have been issued to devices attached to %s at t= %s s and %s s. '%(self.name, str(t),str(all_change_times[j+1])) +
'One or more connected devices on ClockLine %s cannot support update delays shorter than %s sec.'%(clock_line.name, str(1.0/clock_line.clock_limit)))

now reading through we see that this code chunk the first error check:

dt = change_time_list[i+1] - t
if dt < 1.0/clock_line.clock_limit:
raise LabscriptError('Commands have been issued to devices attached to clockline %s at t= %s s and %s s. '%(clock_line.name, str(t),str(change_time_list[i+1])) +
'One or more connected devices on ClockLine %s cannot support update delays shorter than %s sec.'%(clock_line.name, str(1.0/clock_line.clock_limit)))

this one does the check that makes sense which is that there are no invalided updates on the same channel. But this next statement

dt = all_change_times[j+1] - t
if dt < 1.0/clock_line.clock_limit:
raise LabscriptError('Commands have been issued to devices attached to %s at t= %s s and %s s. '%(self.name, str(t),str(all_change_times[j+1])) +
'One or more connected devices on ClockLine %s cannot support update delays shorter than %s sec.'%(clock_line.name, str(1.0/clock_line.clock_limit)))

makes sure that there are no “invalid” updates on any other line. I am with Trey in that I can’t see _any_ reason for this check.

— Ian

[Philip Starkey]

Hi Ian,

This isn’t actually quite true

You are correct. That example should have been a change in NovaTech output followed by a change on another device on the same pseudoclock, where the time between changes was much much less than 100us.

 I am with Trey in that I can’t see _any_ reason for this check.

Consider the following user request for a change in output. Let's assume the NovaTech is changing at T1 and an NI card is changing at T2, and they are on separate clock lines (but the same pseudoclock):

Labscript will look at this and generate a pseudoclock signal as follows:

Now even if the pseudoclock tick for event T2 is gated so it is not sent to the NovaTech, it's temporal position still determines the length of the previous pulse sent to the NovaTech to trigger the event a T1. This is because both the clockline for the novatech and the clockline for the NI card are on the same pseudoclock. Gating a pseudoclock doesn't mean labscript starts internally generating more than one pseudoclock. It's just changing when the one pseudoclock is output on different clocklines.

So because the change at T2 effects the length of the clock tick for event T1, we need to check to make sure that time between T1, and the next change time (T2), is long enough to generate a clock tick long enough for the device(s) being changed at T1 to detect. This is regardless of what clockline the event at T2 is on. If T2 is too close to T1, even if it's not being sent to a NovaTech, it can cause the clock tick for T1 to be too quick (I'm specifically referring to the high time here....the low time is determined by whether subsequent clock ticks are gated or not). This is the reason that the second check is there.

The problem comes in that labscript has no actual knowledge of how short the high time (that’s (T2-T1)/2 - T1) can be (while still having the device detect the clock tick). Labscript infers it from the maximum update rate of the device assuming a 50% duty cycle. As covered previously, this has been a good assumption for every device except the NovaTech.

In summary, the first check you pointed to ensures the high + low time is not too short. The second check ensures the high time is not too short. The latter depends on what other clocklines are doing (because labscript does not have the capability to hold a clock line high, and later transition it low, while another clock line is ticking, unless they are on separate pseudoclocks). I hope that sufficiently explains why the second check is necessary.

As it stands, I believe I've just worked out a way to quickly hack in support for defining minimum clock tick high times as long as it's defined as less than 50% of the time between updates at the fastest rate the device supports. This should in theory solve the issue with the NovaTech for everyone, even if it's not proper asymmetric clock support (which would require a major rewrite of labscript).

Cheers,
Phil

--
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.

[Ian B. Spielman]

Thanks Phil!

That was a really useful answer. It seems to me that for the second check labscript should be asking a different question which is “low long of a clock trigger is needed trigger a specific device.” In my experience this has absolutely nothing to do with the max clock rate of a device. For example in our labs we configure the pulseblaster pseudoclocks to send pulses of the minimum possible length rather than use the 50% duty cycle model (we find this gives better timing in most cases), and in the past 15 years I have encountered only one device for which this was a problem (it was a cheap DMD that needs at minimum 1 us triggers, but can be clocked only every 250 us).

So my proposal would be to add a new attribute to every device which its minimum trigger duration. In this case the error check would make perfect sense in the 50% duty cycle model (and even in a future arbitrary trigger duration model a similar error check would be needed), and since---like most devices---the novatech can accept ~50 ns triggers the error we are seeing would be eliminated in all practical cases.

— Ian

Ian B. Spielman

Fellow, Joint Quantum Institute
National Institute of Standards and Technology and the University of Maryland

----- WEB -----
http://ultracold.jqi.umd.edu

----- EMAIL -----
spie...@jqi.umd.edu

----- ZOOM -----
https://umd.zoom.us/j/7984811536

----- PHONE -----
(301) 246-2482

----- MAIL -----
UMD:
2207 Computer & Space Sciences Bldg.
College Park, MD 20742

NIST:
100 Bureau Drive, Stop 8424
Gaithersburg, MD 20899-8424 USA

----- OFFICE -----
UMD: Physical Sciences Complex, Room 2153
NIST: Building 216, Room B131

> On Feb 4, 2022, at 20:24, 'Philip Starkey' via the labscript suite <labscri...@googlegroups.com> wrote:
>
> Hi Ian,
>
> This isn’t actually quite true
>
> You are correct. That example should have been a change in NovaTech output followed by a change on another device on the same pseudoclock, where the time between changes was much much less than 100us.
>
> I am with Trey in that I can’t see _any_ reason for this check.
>
> Consider the following user request for a change in output. Let's assume the NovaTech is changing at T1 and an NI card is changing at T2, and they are on separate clock lines (but the same pseudoclock):
>

> <image.png>
>
> Labscript will look at this and generate a pseudoclock signal as follows:
>

> To view this discussion on the web, visit https://groups.google.com/d/msgid/labscriptsuite/CAAZq5f4bbM4Ri%2BDA%2B3%2B3C%3DcfHrxiRuSFtTsLhQF9x1Aya6jz4w%40mail.gmail.com.

[Philip Starkey]

Hi Ian,

Great! I'm glad we're on the same page now. Your suggestion is what I alluded to as a fix in my last email. I've already created a Pull Request on GitHub today with that change for labscript: https://github.com/labscript-suite/labscript/pull/88 

It currently defaults to setting the minimum time to half of the inverse of the fastest update rate for backwards compatibility (as this is what it was implicitly previously).

There's also one for labscript devices (https://github.com/labscript-suite/labscript-devices/pull/94 ) where I explicitly set this minimum duration for the NovaTech to something more sensible. I've set it to 1us for the moment because I have a suspicion that the tri-state buffer the Monash labs use between the clock and the NovaTech might limit how fast you can trigger it and I don't want to reintroduce the bug for them that I was originally fixing. If that's not fast enough for you, it can be overridden after import at the top of the connection table.

If you or Trey have time to test I'd welcome your feedback.

Cheers,

Phil

To view this discussion on the web, visit https://groups.google.com/d/msgid/labscriptsuite/FFF62F8A-82AA-41E7-A359-13E96A8A27E1%40umd.edu.

[Trey Porto]

Thanks for the through discussions.

I think I understand better the underlying pseudo clock operation: conceptually there is  single pseudoclock that is a variable frequency clock with 50% duty cycle.  It contains every clock output needed for every device attached to the device, regardless of how many separate clock outputs are used. The separate devices are gated to only see their own clock transitions.

I assume that this structure is defined and implemented in software, because the hardware programming of e.g. a pulseblaster, looks nothing like this variable-frequency-pseudoclock with gated-output-lines-to-select-transition-edges.

In any event, it seems to me that this second problem, the minimum pulse duration that can trigger a device, will never be a problem for us.  I have never seen a device that a 100ns pulse is too short of a trigger, and the pulse blaster’s minimum pulse duration is 100ns: it is simply not capable of making a pulse too short. You are basically hardware protected. 

Cheers, 

Trey

—
Dr. Trey Porto

Fellow, Joint Quantum Institute
National Institute of Standards and Technology
and the University of Maryland

College Park, MD 20742
UMD Office: PSC 2147
UMD Phone: 301-405-0854
Preferred e-mail: po...@jqi.umd.edu
Official NIST Business: tr...@nist.gov

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.