Integration of non-tiggerable devices

[Nick Jacob Sauerwein]

Hey Labscipters,

My name is Nick and I am a PhD student in the Lab of Quantum Gases at EPFL Lausanne, Switzerland. In our experiment we extensively use Labscript. Recently, we bought a Rohde&Schwarz signal generator. Unfortunately, this devices cannot operate in a triggered mode. We therefore have to send instructions over the Ethernet connection whenever we want to change the settings of the devices (like changing amplitude or frequency). For this specific device timing better than the ms range is not required, therefore in principle sending just an Ethernet instruction should not pose a problem.

Here now my question: 

What is the most elegant way to implement a non-tiggerable (without pseudo-clock) device? And how can we make sure that the operations are executed at the right time in the sequence? I saw that in the experiment_queue.py file there are callbacks like 'science_starting'. Could these be used to initialize the device?

Thanks in advance for your help. The labscipt code is just great!

Enjoy your weekend!

[Ian B. Spielman]

Nick,

I have for a long time wanted labscript to have a software timed pseudoclock that sent out zmq events as triggers at defined times (or some similar mechanism). This would solve your problem. Otherwise I would get write a driver for raspberry pi setup to take triggers and send commands from a table to your device.

Have fun!

— 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/1d28aa64-ff3e-4d4d-a131-dbbccd1eea08n%40googlegroups.com.

[Nick Jacob Sauerwein]

Ian,

Thanks for the quick answer. 

Setting up a zmq event trigger would be perfect. What would be the way you would like to implement it? In the end a single trigger at the beginning of the sequence would be sufficient. Just before the Masterclock is started.

I was already thinking about the second option. It seems a bit hacked. Do you know anyone that had implemented something similar before? 

Thanks.

Nick

[Ian B. Spielman]

Nick,

In the end, the big picture idea would be to extend most static output devices to be able to accept ZMQ triggers during the sequence so they could behave as triggerable devices, subject to the latency of ZMQ triggering an the accuracy of a software clock.

* The clock itself would be started like any other device by labscript and would start ticking as soon as blacs sent a start signal. Then it would dispatch ZMQ messages as per its internal table of events.

* The biggest issue I see right now is interfacing with waits since this clock would need to respect labscript time, not wall time. My first idea here was going to be to use a digital input to learn the status of wait, but Chris Billington had some idea of having the device monitoring waits dispatch start-wait and end-wait signals over ZMQ to all listeners.

Like I said, I soft clock would be a great addition to labscript, but it could be a time sink.

— 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

> To view this discussion on the web, visit https://groups.google.com/d/msgid/labscriptsuite/540d7691-1c9c-4c21-a8aa-3060dd2fd289n%40googlegroups.com.

[Philip Starkey]

Hi Nick,

We did do something with a raspberry pi at Monash a few years ago. The code is archived here. This was to control a Zaber translation stage during an experiment using a digital trigger. Unfortunately all the code is in a single file so it's not hugely clear (this was developed before labscript device code could be split across multiple files). The first half of the file contains labscript device classes and the second half contains the code to run on the Raspberry Pi. It was set up to only switch between two positions so it would need to be adapted to handle a table of values (as well as updating for whatever device you are wanting to control). Probably the most relevant parts are the ZaberWorker and ExperimentServer classes which show a pattern for communication between the BLACS device worker and the Raspberry Pi.

Not sure how useful this is for you but hopefully it gives you a starting point at least. I certainly think it would be feasible for you to develop something similar for your own device.

Cheers,

Phil

To view this discussion on the web, visit https://groups.google.com/d/msgid/labscriptsuite/2889B229-E1DA-447F-80AE-333A4CEC2C4B%40umd.edu.

--

Dr Philip Starkey

Senior Technician (Lightboard developer)

School of Physics & Astronomy

Monash University

10 College Walk, Clayton Campus

Victoria 3800, Australia

[Ivan Herrera]

Hi Nick,

I wrote a Labscript device code to control a Rohde&Schwarz signal generator. This, apart from control in static the instrument,  saves into a list memory different values of amplitude or frequency, we can go through the list by a trigger input of the instrument. I don't know if your R&S has this capability,  our signal generator is an SMB100A model. Maybe your model is similar, in that case, I can share with you the code that I wrote.

If you want to change state via Ethernet/serial commands, this action is slow and with some jitter in time, maybe in the order of 100 ms. Don't know if that suits you

.

In order to be more deterministic, this doesn't save you from slow communication times. I'll suggest something more real-time, simple microcontrollers, these have capabilities of communicating via ethernet/serial, and interrupts (trigger) pretty fast, us,  with nothing in their tasks to create any indeterminate lag. If you are not familiar with them my suggestion is to use something in the Arduino environment, the learning curve is not steep and there are tons of libraries. These have interrupt (trigger) capabilities pretty fast, us. 

Cheers,

Ivan

[Nick Jacob Sauerwein]

Thanks, Ian, Philip, and Ivan,

All your suggestions are very helpful. 

@Ivan: Unfortunately, the device we are using (R&S   SGS100A) doesn't have the list mode feature. We use this feature with another Rohde&Schwarz in the lab. The SGS100A has a fast setting feature over Ethernet and PCIe (well below 0.3 ms setting time). Of course, the question of latency remains. I will write a test script to see how much latency I can expect. 100 ms sounds a bit too much to me. If it would be in the 10 ms range, I could easily use it in the experiment.

@Ian: I totally agree with your plan. I will investigate a bit and do some tests on how to implement a SoftwarePseudoClock. Let's hope it doesn't eat all of my time.

@Philip: Thanks for the code. Do you remember what the latencies were? How fast did you manage to send the commands with the RPi?

Enjoy your days,

Nick

[Philip Starkey]

Hi Nick,

We never benchmarked the latencies. It was moving a lens on a translation stage so it was slow, and I think it needed significant settling time afterwards (and we had ~10s to do it in) so communication latency wasn't really relevant for our use case.

I'd be interested in seeing a software pseudoclock for the labscript suite but I suspect that Ivan's suggestion of using an Arduino microcontroller to hold the table would be ultimately easier (and more performant) than something running on a PC. Generally PC interrupts will have at least 15ms jitter at best unless you are running a RTOS. Using an Arduino, you could base the labscript suite code on the novatech device and then you just need to write a simple Arduino program to accept serial or ethernet commands from BLACS and send out Ethernet commands to your signal generator on a digital trigger edge (that comes from a pseudoclock into the Arduino).

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/cebd9ece-369e-4805-8372-31e99492239fn%40googlegroups.com.