labrad / servers

LabRAD servers

labrad

Repository for LabRAD tutorials and resources sharing.

Contributing

For instructions on how to contribute to labrad, see contributing.md.

servers's Issues

Qubit Server Documentation

Every time I go back to the qubit server I have to re-remember its class structure. In addition to the auto-generated JavaDoc, it needs an intro/readme/whatever.

Many servers have broken units

Branch created units_fix_servers to fix these problems in. Currently I have tested/fixed the following servers:

gpib_bus
gpib_device_manager
lakeshore370 (ruox)
lakeshore218 (diodes)
mks_gauge_server

VNA Server has a VISA timeout error when the number of VNA averages is too large

It might also have to do with the sweep settings (such as number of points, and IF bandwidth).

Here is the error report:

FPGA server swallowing setup packets errors

For some reason the exception raised here:

https://github.com/martinisgroup/servers/blob/master/GHzDACs/ghz_fpga_server.py#L815

is not getting propagated back to the user and instead things hang. I don't know why, but if I put in a print statement before I can see the message.

Datavault undefined local variable

When trying to cd to an as-yet non-existing directory:

exceptions.UnboundLocalError: local variable 'create' referenced before assignment

What is the 'Vince' branch and why is it the active branch on Trench?

I am very confused by this. Can someone who was doing experiments in Trench (in the trenches?) before the APS meeting give me a clue?

What is a DacRunner and why do I need one?

I thought we were almost there with the jump table stuff, and then I realized I have no idea how run_sequence actually works. So now I'm wondering how much of the DacRunner stuff is going to need to be changed for the JT. Are there any gotchas here I should be aware of? (For DacRunners or run_sequence as a whole or anything else.)

Time out setup state in GHz FPGA server

Currently, the GHZ FPGA server keeps track of a hardware state, and decides whether to run the setup packets based on whether the current scan is using the same settings as the previous ones. This avoids resending packets to slow devices such as the GPIB bus on every sequence. However, it has no way to tell if I manually change the settings from the front panel of a signal generator.

What it should do is time-out that state after (say) 60 seconds idle. Thus, as long as a scan is running, the hardware configuration is changed only when necessary. We assume that users are not changing the GPIB devices during a scan. However, if the system is idle, we assume someone might have made manual changes and we reprogram the hardware before starting up again. Since this will happen at most 1/minute, it will have negligible impact on performance.

Assigning @DanielSank because he is familiar with the GHZ FPGA server, but this would be a good small project for an FPGA server padawan to get familiar with that rather complicated piece of code.

Jump table spec sheet needs a diagram of how the jump table works

I'll do this right now.

Separate board group registry entries

...so people don't step on each other's toes.

What happened to the new non MS .doc fpga documentation?

Julian/Peter?

ADR GUI scrolling up / move it to servers / add me to pyle

Peter.

Values should be converted to DAC units in the FPGA server, not the DAC calibration server.

AFAICT, the deconvolution server is what converts the full scale range (-1, 1) to the DAC range (0, 2**14).

This line: https://github.com/martinisgroup/servers/blob/master/ghzdac/correction.py#L852

This should be done in the GHz FPGA server. It would be nice to e.g. be able to plot the corrected data.

Make ghz_dac_calibration command line instead of semi-gui

Qubit sequencer should support receiving DAC'ified data.

Currently the only way to give pre-deconvolved data to the qubit sequencer is if you give it time domain data. If we're going to do deconvolutions in pyle, it should support receiving deconvolved frequency domain data as well.

MKS gagues not always automatically detected

Supermonitor on Vince currently running with only 'still' and ''return' pressures.

Qubit Server Refactoring--memory commands and jump table commands

Most commands issued to the qubit sequencer are issued to a particular channel. The memory commands, however, are a bit different because they are handled inside FpgaModelDac, but sometimes issued to a particular channel (which forwards the command to its FpgaModelDac instance), and sometimes issued to the whole experiment (which sends a command to each FpgaModelDac).

The jump table commands, on the other hand, are specific to a channel, with the one exception that for analog boards, the two channels must have identical jump tables. FpgaModelDac has two subclasses, FpgaModelMicrowave and FpgaModelAnalog.

Since we want to support both old and new boards, I'm trying to figure out the best way of refactoring the FpgaModel structure.

Current ideas are:

1. We have FpgaMicrowaveMemory, FpgaMicrowaveJumpTable, FpgaAnalogMemory, FpgaAnalogJumpTable, which I don't like because however we do the inheritance we'll be duplicating either the memory/JT handling code or the microwave/analog code.
2. Mixins seem like they might be the solution, but Java doesn't do mixins.
3. Instead we just use object composition, i.e. give the FpgaModelDac base class a "Controller" object that would be either MemoryController or JumpTableController and put the relevant functions in there.

I think the problem is that (1) memory<->jump table is not a one-for-one mapping because generally the memory sequences are the same for all the boards, but not necessarily for the jump tables (but maybe they should be) and (2) I'm probably overthinking this.

Basically I was hoping @maffoo would state the obvious answer I'm missing.

GHz_fpga_server times out

2015-03-18 16:38:10-0700 [ServerProtocol,client] GHz FPGAs now serving

2015-03-18 16:54:32-0700 [ServerProtocol,client] Traceback (most recent call las

t):

2015-03-18 16:54:32-0700 [ServerProtocol,client] Failure: labrad.types.Error: (0

) Operation timed out [payload=None]

2015-03-18 16:54:32-0700 [ServerProtocol,client] RECOVERING FROM TIMEOUT

2015-03-18 16:54:33-0700 [ServerProtocol,client] 'executionCounter'

Leaves buffered packets in direct ethernet server

HTTP stuff

@joshmutus -- what's the status of the http stuff? It doesn't have to be completed but it would be good to consolidate it down to one branch.

Compressor Server Temperatures - Incorrect Ordering and/or Temperatures

The cp2800_compressor server is outputting temperatures which are either incorrect or in the wrong order for Ivan.

In particular, according to the server documentation (at it appears code), the order should be:
[(Water in CURRENT, Water in MAX, Water in MIN), (Water out CURRENT, Water out MAX, Water out MIN), (Helium CURRENT, Helium MAX, Helium MIN), (Oil CURRENT, Oil MAX, Oil MIN)]. However, the current readings (according to the front of the compressor) seem to be given by the middle of each triplet (i.e., the one that is supposed to be MAX).

Further, there is no permutation of (CURRENT, MIN, MAX) such that MIN<=CURRENT<=MAX for all four temps. For example,

In [12]: cp.temperatures()
Out[12]: [(Value(303.64999999999998, 'K'), Value(290.64999999999998, 'K'), Value
(285.34999999999997, 'K')), (Value(293.44999999999999, 'K'), Value(298.949999999
99999, 'K'), Value(289.04999999999995, 'K')), (Value(302.64999999999998, 'K'), V
alue(342.75, 'K'), Value(291.54999999999995, 'K')), (Value(344.75, 'K'), Value(3
00.64999999999998, 'K'), Value(292.34999999999997, 'K'))]

Note that the temperatures from the front of the compressor are (translated to K) [291K,299K,343K,301K]. Hence, I'm guessing that the MIN and MAX temperatures are garbage.

Note: ADR/compressor_server.py is same as in branch f4bba31. However, the actual (apparently uncommitted) branch of Vince is d8b2c28.

FPGA timeout from dac calibration server

At some point in the qubit stack of code a request is made to the dac calibration server to calculation corrections for the dac waveforms. If this calculation takes too long the ghz_fpga_server seems to go through a catastrophic timeout which lags running code and prevents the dac boards from successfully being brought up until they are power cycled.

Session level pipelining for qubit sequencer

Right now, we allow sequences from multiple scans to be interleved via the same system we use for pipelining requests from a single scan.

This is really flexible, but somewhat inefficient, as the fastbias and anritsus must be programmed every time we switch between scans. So I propose adding a more coarse grained exclusion mechanism in the qubit server. The idea is that each scan would request a 'sequence group ID' token. The qubit sequencer would then run only sequences from that group until it completes, or for up to a set period of time on the order of a couple of minutes. Then the next scan would run for a couple of minutes, and so forth.

The upshot of this would be that short scans (rabihigh) will just run in order with no interleaving. However, a running long scan can be preempted by a short scan, which will run to completion and then resume the long scan. Long scans will be interleved, but on longer intervals to avoid the overhead of switching the hardware configuration.

This could be enhanced by adding priority hints like "low priority / long scan", or "high priority / short scan" or "uninterruptable scan" (for things like the ramsey oscilloscope that need precise timing", but I think the initial implementation can make some reasonable defaults and have it 'just work'

What do people think? Any suggestions?

Sequence time for jump table boards

In the FPGA server, there are calls to the figure out the sequence time from the memory sequence. This no longer applies for the jump table boards. I think the sequence time is needed for figuring out what the timeout should be (?). For the JT boards we can't know the sequence time even in principle (I guess the JT's aren't Turing complete but we've got a halting problem nonetheless).

Thoughts on this?

dac_calibration_server.py as .asarray when it shouldn't

Let's get rid of this.

HTTP Server should pull data from the datavault

Right now it goes looking for individual servers, and if different DRs use different servers (which is probably an issue in and of itself?) then it crashes.

Also it could probably in general use an overhaul.

Cryo notifier should have grace period

Right now, the cryo notifier will send an alert if one of the thermometry servers is restarted or otherwise unavailable, or in the case of the lakeshore ruox, if it hasn't yet received valid data for one of the channels. This leads to lots of false positives. Instead, when it detects an error condition on one of the channels it should start a timer. If the condition remains out of spec for a continuous 60 seconds, only then should it trigger an alert.

Jump table spec sheet is somewhat vague about byte order

In the table for the jump table op codes there are columns "byte 1" and "byte 2". This is not clear.

Refactor the jeebus out of the qubit sequencer

There's a fair amount of cruft in there as it is, and many of the additions I made over the past couple years probably appear somewhat haphazard to the casual observer. After the jump table stuff is complete the qubit sequencer should be refactored.

Switch channel type for qubit sequencer

Qubit sequencer should support a "switch" resource for microwave switches.

Consolidate oscilloscope servers

There are as many oscilloscope servers as there are oscilloscope models, which is ridiculous. There should be a common interface provided by single serve which produces the appropriate command strings for each model of scope.

Serial server not able to talk to MKS gauges on Vince

At some point on Thursday, MKS gauge server lost contact with the hardware. @JulianSKelly might know more about when/how this happened.

In debugging, we tried writing and reading via the NI MAX software, which worked and gave us the correct pressures. We were also successful using pyvisa. However, we couldn't seem to communicate with the gauges using pyserial. Does anyone know how pyserial and pyvisa interact with the gauges differently?

New Version of Visa (GPIB software) notes

You are now required to put '::INSTR' at the end of names to GPIB devices or they will not be recognized...

Fastbias serial support for qubit sequencer

Qubit sequencer should support programming fastbias over serial connection.

Set up build system for qubit sequencer

Right now, the qubit sequencer source lives here, and we also package up the server as an executable jar and commit the built jar to the repo as well. We should have a real build system that can build this in a reproducible way. I suggest we use sbt for this.

DR Logger needs to be more tolerant of dropped servers

...so that you don't have to restart it if the hardware/network/whatever blips for a bit.

Lakeshore Upgrade?

When filling cryogens it would be nice if we could toggle the lakeshore to read out more rapidly on the mix plate ruox and not on the other channels so we can watch the rise times of things on shorter time scales.

interpol1d_cubic_S in correction.py is not used

It should be nuked.

Supermonitor hangs on last value

Occasionally, the supermonitor will stop updating until restart.

Serial Server

Serial server on Gordy did not start.

Can't run ghz_fpga_server

When Charles and I tried to run ghz_fpga_server from a command line (master branch), it won't start. In particular, I get the following message:

U:\Jim\Code\servers\GHzDACs>ghz_fpga_server.py
Traceback (most recent call last):
  File "U:\Jim\Code\servers\GHzDACs\ghz_fpga_server.py", line 222, in <module>
    import servers.GHzDACs.Cleanup.dac as dac
ImportError: No module named servers.GHzDACs.Cleanup.dac

I then tried running Cleanup\dac.py (which indeed is present!):

U:\Jim\Code\servers\GHzDACs\Cleanup>dac.py
Traceback (most recent call last):
  File "U:\Jim\Code\servers\GHzDACs\Cleanup\dac.py", line 3, in <module>
    import servers.GHzDACs.Cleanup.fpga as fpga
ImportError: No module named servers.GHzDACs.Cleanup.fpga

Upon trying to run fpga.py:

U:\Jim\Code\servers\GHzDACs\Cleanup>fpga.py
Traceback (most recent call last):
  File "U:\Jim\Code\servers\GHzDACs\Cleanup\fpga.py", line 8, in <module>
    from servers.GHzDACs.util import LoggingPacket
ImportError: No module named servers.GHzDACs.util

However, U:\Jim\Code\servers\GHzDACs>util.py does run successfully.

The only way we (actually, Rami) could figure out how to get past this was to move ghz_fpga_server.py to the folder containing servers (here, U:\Jim\Code\), however, it then complains:

U:\Jim\Code>ghz_fpga_server.py
Traceback (most recent call last):
  File "U:\Jim\Code\ghz_fpga_server.py", line 226, in <module>
    from util import TimedLock, LoggingPacket
ImportError: No module named util

Is there any way to get ghz_fpga_server to actually run??!!??

(PS: Please keep Charles in the loop as well.)

Deal with gpib end-of-line characters

What needs to happen:

1. Set up a way for device wrappers to set the newline character used in all gpib writes and reads.
2. Make sure that all of the string literals used as gpib commands in all sever code do NOT have explicit newline characters.
3. Check that pyvisa isn't adding its own characters. If it is, figure out how to turn this off when the gpib bus server creates the pyvisa resource.

GPIB Device Manager's device connected functionality doesn't work with non-*IDN? devices

When the GPIB Device Manager starts it has no problem identifying devices that don't use the standard *IDN? query. When a device is connected after the manager has started, though, it doesn't correctly detect such a device.

This can be seen with the SR770 on trench. The temporary workaround is to restart the GPIB Device Manager in this case.

sr780 server seems to drop bits

When querying the device, say it has a 100 Hz span, the method .span() should return 100

sr.span()
Value(100.0,'Hz')
instead, sometimes a digit will be lost and the following will happen:
sr.span()
Value(00.0,'Hz')
Then that missing '1' is left in the queue, so a gpib_read() will return:
1
when it should have failed since the buffer was empty. I can't generate a test case that will cause this bug every time...

Automatic restarting of servers

We should figure out the best way to keep certain servers up and running.

The FPGA server and associated tools should support the jump table

The order of things to do here is roughly

1. Test jump table with fpgaTest (from pyle) to make sure the FPGA works as advertised.
2. Write DAC subclasses for the jump table build and add necessary settings to the server. This step should be simple as only a few parts of the interface have changed.
3. Update qubit sequencer. This should probably be its own ticket to be created when work on the FPGA server is done.

When this is complete a new set of tickets should be generated in pyle specifying how fpgaseq and the gatecompiler will be modified.

GPIB bus server's `.refresh_device` setting doesn't work.

lakeshore 370 server has bad units handling

The lakeshore 370 server expects the calibration data from the registry to be stored as floats, not with units. This only applies to the INTERPOLATION type calibration.

GPIB chokes on non-ascii response

The sampling scope responds to "*IDN?" with '\xff' (I don't know why). The updated version of pyvisa apparently tries to decode everything into ASCII and chokes on this.

Qubit Sequencer context hangs on to last error

When the qubit sequencer returns an error, e.g. conflicting microwave configurations, it will continue to return this error until a new python session is started. (context).

DataVault multihead unbound local error

Sometimes trying to do a datavault cd I get the following error:

File "data_vault_multihead.py", line 1029, in cd
if not Session.exists(temp) and not create: