Understanding Transition to Buffered

[Lufter Reis]

Hi all,

Is there a way in transition_to_buffered for users to send a command to a device like Arduino at a specific clock time? 

For example, if I've already implemented in generate_code(), storing which command I want to send at a specific clock tick:

command_data = [time0_send_command0, time1_send_command_1, ...]

Then in transition_to_buffered(), I can read in this "command_data" from the decoding the compiled hd5 file. And I can iterate through this "command_data" to send command to the Arduino. But what I don't understand is, doesn't transition_to_buffered() just send commands to the Arduino without caring about the clock ticks? Since there seems no clock information being passed to transition_to_buffered(), how does transition_to_buffered()  know when to send a command to Arduino? 

A related example to this question is the transition_to_buffered() in labscript_devices.NovaTechDDS9M.

# Now program the buffered outputs: 

if table_data is not None: 

    data = table_data 

    for i, line in enumerate(data): 

         for ddsno in range(2): 

             self.connection.write(b't%d %04x %08x,%04x,%04x,ff\r\n'%(ddsno, i,line['freq%d'%ddsno],line['phase%d'%ddsno],line['amp%d'%ddsno]))

From my understanding, what this code does is to read the data which contains a series of output commands, and the program will iterate through every one of them and send the commands to a device. But I don't see why this will allow the NovatecDDS to output a specific value at different times since the program will just iterate through all commands once it sees those codes.

This question has been crowed me for a while and I now seek a chance to understand it. Thank you!

Best,

Lufter

[Johannes Schabbauer]

Hello Lufter,

In the labscript-suite devices usually are timed by getting hardware triggers. So for the Novatech (and other devices) in transition_to_buffered there is just the output table programmed, and during the shot the device steps to the next output whenever a hardware trigger is received (from a Pseudoclock or Trigger). The actual timing is stored and programmed in the Pseuoclock/Clockline or Trigger that is connected to this device.

If you want to pre-program a device (like the Arduino) with timings, you still need at least one hardware trigger that tells is when to start, because only one device is started by software (this is the "Master Pseudoclock"). However, when you time all instructions after the staring trigger internally by the Arduino, you should be careful that the Arduino does not get out of sync with the other devices (e.g. because the time on the Arduino runs a bit slower because calculations take longer).

I hope that helps you a bit.

Best wishes,

Johannes

[Lufter Reis]

Hello Johannes,

Thank you so much for your response! So I guess there is no way to resemble timing mechanism for the user implemented devices as Labscript has done for program_buffered_AO in NI_DAQmx devices. Because some devices in lab doesn't have a proper external trigger access, they only have software access. So I assume to get it properly triggered, I will probably need a MCU that can store commands and receive external triggers just like how people done with those AD9959 eval boards. Now everything becomes clear!

Best,

Lufter

johannes....@gmail.com 在 2024年4月10日 星期三凌晨4:16:27 [UTC-4] 的信中寫道：

[Ian B. Spielman]

Lufter,

Another option would be to write a new labscript device that is a software based pseudoclock which distributes “ticks” over ZMQ to software-trigger based devices. I think getting a basic version of this working would be simple (as long as you can tolerate not so great timing), but integrating with the “waits” that can pause execution of the hardware task seems difficult. I had been thinking that this synchronization might be possible with some updates to the pine/prawn blasters to have them provide near-real time information back to the computer about their current status.

Likely too much work but food for thought,

— 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

> --
> 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/e6a4197c-4ca6-47a8-a0f3-5c96385b42cdn%40googlegroups.com.