search

labscript-suite / labscript-devices

A modular and extensible plugin architecture to control experiment hardware using the 𝘭𝘢𝘣𝘴𝘤𝘳𝘪𝘱𝘵 𝘴𝘶𝘪𝘵𝘦.
http://labscriptsuite.org
Other
5 stars 58 forks source link

Novatech DDS9m digital-gate being inappropriately held to DDS table pseudoclock #35

Closed philipstarkey closed 5 years ago

philipstarkey commented 5 years ago

Original report (archived issue) by Lincoln Turner (Bitbucket: lincolndturner, GitHub: lincolnturner).

Background

Our novatech dds9m based DDS devices (supernovae et al) have
freq/amp/phase points stepped through by a pseudoclock. This
pseudoclock is rate-limited to 9990 updates/sec, and labscript
enforces this.

Unlike our other DDSes, our novatech boxes have a TTL enable line,
which gates the output rf. This is NOT necessarily off the same
pseudoclock, and for example could come from an NI DO clocked off a
faster pseudoclock.

The digital line connected to enable is set in the connection table
constructor line as a dict-kwarg with key 'digital_gate'.

This allows the labscript DDS-object to have a enable/disable
methods. For example MOT.enable().

Issue

In "previous versions" (under python 2, and before recent py3isation)
the enable/disable methods could be called with less than 100us
between them. Calling .setfreq(), .setamp() or .setphase() with <100us
spacing did raise a Labscript exception.

However, with latest labscript and latest labscript_devices, having a
10us delay between MOT.enable() and MOT.disable() triggers a timing
error (pseudoclock ticking too fast):

'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))) labscript.labscript.LabscriptError:
Commands have been issued to devices attached to
pulseblaster_0_pseudoclock at t= 19.9632 s and 19.9633 s. One or more
connected devices on ClockLine pulseblaster_0_novatech_clock cannot
support update delays shorter than 0.0001001001001001001 sec.
philipstarkey commented 5 years ago

Original comment by Chris Billington (Bitbucket: cbillington, GitHub: chrisjbillington).

Thank for the report.

There are definitely timing bugs in labscript still, I had labscript generate instructions too fast for an NI DAQmx device the other day and had to just lie to labscript about the capabilities of the DAQmx device to make it not generate too fast instructions. Probably not related to the bug you're reporting, but I'm not looking forward to trying to fix any more timing bugs until the timing code gets an overhaul (which is in the works).

However I don't think your issue is precisely what you describe, or if it is it is triggered only in certain situations. This minimal example, which is what you described, works for me:

from labscript import start, stop, DDS, ClockLine, labscript_init, DigitalOut
from labscript_devices.NovaTechDDS9M import NovaTechDDS9M
from labscript_devices.PulseBlaster import PulseBlaster
from labscript_devices.NI_DAQmx.labscript_devices import NI_PCIe_6363

labscript_init('test.h5', new=True, overwrite=True)
PulseBlaster('pulseblaster')
ClockLine('dds_clock', pulseblaster.pseudoclock, 'flag 1')
ClockLine('gate_clock', pulseblaster.pseudoclock, 'flag 2')

NovaTechDDS9M('novatech', dds_clock)
NI_PCIe_6363('ni_pcie_6363', gate_clock, clock_terminal='PFI0')

DDS(
    'dds',
    novatech,
    'dds 0',
    digital_gate={'device': ni_pcie_6363, 'connection': 'port0/line0'},
)

# Must have an even number of DOs on an NI DAQmx device
DigitalOut('dummy_do', ni_pcie_6363, 'port0/line1')

start()
t = 0
dds.enable(t)
t += 5e-6
dds.disable(t)
t += 1
stop(t)

And your exception implies an update interval of exactly 100us was requested somewhere, whereas the min update interval is 1.001us (though obviously the bug could be such that the exception can't be trusted). But if the exception is right, it seems like this is caused by requested update rates close to the 100us interval, and not a 10us update interval.

Do you have an example which breaks (even if it is not a minimal one)? I don't doubt that there could be bugs causing this, but I'm skeptical that it has to do with the digital gate.

philipstarkey commented 5 years ago

Original comment by Chris Billington (Bitbucket: cbillington, GitHub: chrisjbillington).

The most recent merge commit in labscript was a bugfix to some timing code. If you are up-to-date in labscript, you might try reverting to the last commit in the default branch before that merge, in case that change caused a regression affecting your scripts.

philipstarkey commented 5 years ago

Original comment by Lincoln Turner (Bitbucket: lincolndturner, GitHub: lincolnturner).

Thanks Chris. I’ll try your MWE in a minute, and the reversion, but for now I’m documenting the error I am seeing…

The labscript output is: 

t = 19.973200000 s: Stern-Gerlach kick
WARNING: State of digital quantity MOT_repump_gate at t=19.9622s has already been set to low. Overwriting to high. (note: all values in base units where relevant)
t = 19.963200000 s: fluorescence exposure
t = 20.073310000 s: Close MOT shutter after fluorescence probe pulse
t = 20.163310000 s: Zeeman loaded MOT
t = 20.163310000 s: LF + HF amps active
t = 23.243310000 s: Open Faraday shutter for alignment purposes...
t = 23.243310000 s: experiment ends
Traceback (most recent call last):
File "crossed_beam_bec.py", line 963, in <module>
File "C:\labscript_suite\labscript\labscript.py", line 2350, in stop
generate_code()
File "C:\labscript_suite\labscript\labscript.py", line 2226, in generate_code
device.generate_code(hdf5_file)
File "C:\labscript_suite\labscript_devices\PulseBlaster.py", line 610, in generate_code
PseudoclockDevice.generate_code(self, hdf5_file)
File "C:\labscript_suite\labscript\labscript.py", line 1097, in generate_code
Device.generate_code(self, hdf5_file)
File "C:\labscript_suite\labscript\labscript.py", line 477, in generate_code
device.generate_code(hdf5_file)
File "C:\labscript_suite\labscript\labscript.py", line 920, in generate_code
self.generate_clock()
File "C:\labscript_suite\labscript\labscript.py", line 890, in generate_clock
all_change_times, change_times = self.collect_change_times(all_outputs, outputs_by_clockline)
File "C:\labscript_suite\labscript\labscript.py", line 679, in collect_change_times
'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)))
labscript.labscript.LabscriptError: Commands have been issued to devices attached to pulseblaster_0_pseudoclock at t= 19.9632 s and 19.96324 s. One or more connected devices on ClockLine pulseblaster_0_novatech_clock cannot support update delays shorter than 0.0001001001001001001 sec.
Compilation aborted.

This happens at 19.9632s, which is at the time we print “fluorescence exposure” (line 3). The relevant labscript is:

 # fluorescence exposure
    print_time(t, 'fluorescence exposure')
    avt_makog030b_0.expose('fluorescence', t, 'fluorescence', exposure_time=fluoro_exposure_time)
    MOT_shutter.open(t-shutter_buffer)
    MOT.setamp(t, MOT_imaging_amplitude)
    MOT.setfreq(t, MOT_imaging_detuning, 'd_MHz') # go on resonance
    #t += 10e-6
    MOT.enable(t)
    t += fluoro_exposure_time
    MOT.disable(t-10e-6)
    MOT_repump.disable(t-10e-6)

Indeed, the traceback clearly complains about times 19.963200 and 19.963240 s, i.e. separation by 40us.

That corresponds to line 8,9,10 in the labscript above. fluoro_exposure_time in this test was equal to 50us, and so the delay between MOT.enable() and MOT.disable() was 40us.

However, the following works fine:

‌

    ## MOT.setamp(t, MOT_imaging_amplitude)
    ## MOT.setfreq(t, MOT_imaging_detuning, 'd_MHz') # go on resonance
    ## t += 10e-6
    MOT.enable(t)
    t += fluoro_exposure_time
    MOT.disable(t-10e-6)
    ## MOT_repump.disable(t-10e-6)

So it is not simply the short fluoro_exposure_time (50us) on the enable line. This is consistent with Chris’s MWE.

Uncommenting the ## MOT.setamp(…) line in the above then fails to compile as above.

Putting t+=1e-3 above or below that setamp line doesn’t help.

And, worse, the times mentioned in the traceback become intermediate times that t is never set set to in the code…

philipstarkey commented 5 years ago

Original comment by Lincoln Turner (Bitbucket: lincolndturner, GitHub: lincolnturner).

This made me suspicious that it was a deep-seated timing problem in labscript, as Chris alluded to the most recent bugfix.

So I reverted to labscript-suite/labscript@f4405d8a8ad5aedacf37ae2dc282d529a0b9b21f, removing the GatedClocks-bugfix merge.

Then all is well!

Shots compile. And better, they run and produce nice fluoroscence images!

And indeed @philipstarkey 's commit labscript-suite/labscript@56184458fbfdf04e5f3da6c9e19267c4e1d796b4 does seem to edit code in and around this error message…

philipstarkey commented 5 years ago

Original comment by Lincoln Turner (Bitbucket: lincolndturner, GitHub: lincolnturner).

Not a labscript_devices issue.

But is a labscript issue.

Reposting there.