ADRV-5 Timebase Implementation Error With Labscript

[Alex M.]

Hello,

We will use ADRV-5 Timebase AOM controllers to control our AOMs and EOMs, and we hope to use it with labscript. I am currently using the device class written by Johannes Schabbauer to do this, and have successfully established a TCP/LAN connection between our control computer and the Timebases using port 8081. However, the Blacs tab throws an error saying that it recieved no remote values for the channel to which it was connected.


For context, these AOM drivers have 5 channels, and I only had the first channel turned on outputting a frequency and amplitude that I read in a spectrum analyzer. Despite this, the Blacs error read "Got no remote values for channel 1, is it connected?"

I pinged the device/port successfully, and looking at the Blacs_worker.py file it seems the issue is due to the check_remote_values function (I have linked the file below). Following the logic defined in the code, it seems that the client establishes a connection with the TCP server, then recieves a message containing the values on the display panel of the channel (e.g. frequency, amplitude, etc.), and then converts them into a dictionary. If there is no particular value in the list, then it raises the aforementioned error.

Has anyone used this device class and experienced this or a similar error before?

best,

Alex

[Schabbauer, Johannes]

Hey Alex,

It's nice to hear that you can use this code. Do you get a response from the AOM driver for the "Gpar" command for this/each channel? If not I would check if the BLACS worker uses the right channel names as set on the device. If the channel names set in the labscript_devices file does not match with the ones on the device, the command from self.client.send(ch.encode()+b"|Gpar\r\n") will be probably ignored by the AOM driver. You could also try send this command and read the response in a small separate python script (or other TCP connection) and check if the response makes sense.

Best wishes,
Johannes

Alex --
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, visit https://groups.google.com/d/msgid/labscriptsuite/dc2bad06-4eb9-47b4-9e48-44bc4331e5dbn%40googlegroups.com.

[Alex M.]

Hello Johannes,

I tried establishing a TCP connection with the driver. According to the manual, the driver works as a TCP server on port 8081. I tried manually sending the Gpar command to channel 1, and it only returned the status as "connected", rather than listing the parameters. I did this while that channel was both enabled and disabled, but the timebase itself was on during the entire test. Is it possible that despite the driver working as a TCP server on port 8081, that this port is not the control port? I could not find any other ones in the manual, and I have attached a screenshot of the TCP connection and commands I sent.

Also, I looked in the labscript_devices file, but it doesn't seem to define the channels explicitly. The only thing I changed in the Blacs worker file was the fact that on the Timebase control panel, the channel names are capitalized "CH" and not lowercase "ch", but this change did not lead to success. Could you please clarify what you meant by checking if the channel names set in the labscript_devices/Blacs worker file match the ones on the device?

best, 

Alex

[Schabbauer, Johannes]

Hi Alex,

In your screenshot the connection to the TCP server seems to be fine, because the response "CONNECTED" is sent when the Client connects in the beginning of your script. Your reasd command might only read a single line, so to get the response of the Gpar command you can try just reading again. 

The channel names are what is shown on the panel of the Timebase device (you can also change them in the settings at "custom names"), so in your case probably also "CH-1" etc.
This is the name you have to use in labscript when you define the AOM channels in the "connection" keyword of the device.

I'm also not familiar with doing that in Powershell, so you could also test using the same python syntax as in the BLACS worker, like this:

import socket

client = socket.create_connection(("192.168.0.100",8081), timeout=2)

print(client.recv(200).decode()) # this prints "CONNECTED"

client.send(b"CH-1|Gpar\r\n")

print(client.recv(1000).decode()) # this should print the parameters of CH-1

Best wishes,
Johannes

--
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, visit https://groups.google.com/d/msgid/labscriptsuite/CABg%3DbWWw2zAzWzxkjYezfS-N7BusvBmt0Wt0HE6gTPhdhVtiQg%40mail.gmail.com.

[Alex M.]

Hello Johannes,

I see, the channel names in my connection table had an extra dash in them. I was able to successfully implement the Timebases in labscript, and perform an increasing linear frequency ramp. However, when I tried performing a linear decreasing frequency ramp, I noticed that the labscript_devices folder the ramp function is defined in only allows positive frequency steps, and suggests to use mode 2 for ramping down. I tried to use mode 2 to ramp down over the entire timebase frequency range (initial frequency=10 MHz final frequency=400 MHz, with the assumption that the triangle ramp would start at the final and go down to the initial), but instead got an increasing ramp, just as I had when I used mode 4. Were you able to implement decreasing linear ramps using this inverted logic?

Many thanks for the help,

Alex

To view this discussion, visit https://groups.google.com/d/msgid/labscriptsuite/8e037cb0-8281-4933-b2db-ee63462c2e10%40tuwien.ac.at.

[Schabbauer, Johannes]

I think the triangle ramp can only start at the lower frequency, and the first sweep will always be up. If you want to go down (again), you have to first ramp upwards and then set the digital output to low by calling TimeBaseFreqSweepTrigger.go_low(t) in your labscript experiment. The ramp function was just meant as a "wrapper" to set the ramp parameters all in a single function with the same parameters as in the AnalogOut class (which is not necessary). However, these parameters are static so you could only define a single type of ramp per experiment and channel, unlike the ramps one can do with AnalogOut channels. You could also set start, stop, step size, step time and mode once individually end then just use "go_high(t)" and "go_low(t)" without ever calling the "ramp" function. You could also extend the "ramp" that you can call it multiple times where each time the digital output is changed but the parameters are set only when you call the function the first time.

To view this discussion, visit https://groups.google.com/d/msgid/labscriptsuite/CABg%3DbWX5_zuTWsj4OMgUtyLzJ3yJzF4Rv%2B4A_nMHcWLS%2BcLo%2Bg%40mail.gmail.com.

[Alex M.]

Hello Johannes,

If I'm understanding correctly, we can define an initial increasing linear ramp using the ramp function for some time, and then call .go_low(t) at any t before the ramp ends. So effectively, a ramp can be set lasting the entire experiment, and then just call go_high(t) and go_low(t) whenever an increasing or decreasing ramp is necessary. I tried to implement this in the following code I have attached, but still observed a monotonic increase in frequency (however, this may be due to the nature of how spectrum analyzer records frequency vs. amplitude and not time) 

best,

Alex

To view this discussion, visit https://groups.google.com/d/msgid/labscriptsuite/d74b87e0-f129-456b-aee3-2556307890bc%40tuwien.ac.at.