Support for wavemeter lock
Closed this issue · 13 comments
I am trying to get the wavemeter lock working and was hoping there could be some documentation on how the lock works. There does not appear to be a way to turn the lock on or off from the GUI. Is there a reason for this or am I missing a way to turn the lock on and off easily?
We tend to just set it programmatically from ARTIQ anyway, so I wouldn't even know whether there is a UI option. (There probably isn't.) Could be added, though.
We are running 3 labs from the same lasers so having it on the GUI probably makes more sense for us in the near term.
We'll have a go at adding it.
Same for us, but as we have wand set up in the ARTIQ device DB for our experiments anyway (as the setpoints for the PI lasers during loading are slightly different), having the UI be an ARTIQ experiment submission box was just fewer lines of code.
Just adding a modal dialogue box with target offset (and lock owner name, defaulting to gui or something like that) accessible via context menu on each laser should do the trick for you, I guess.
Clearly @dnadlinger and I are now in different time zones ;)
I am trying to get the wavemeter lock working and was hoping there could be some documentation on how the lock works
The lock (like the rest of wand) operates using an ARTIQ rpc interface. The documentation is currently all in docstrings (these are the ones you'll see via the artiq rpc tool). See, e.g.
Lines 231 to 241 in 492e0ba
If anything is still unclear after reading these docs please open a separate issue/PR
In the long run we should move away from the readme.md we currently have and use sphinx to build docs from the code (the readme is already getting out of date and IME the further the docs are from the code the more quickly they rot). I would gladly accept a clean PR to add sphinx docs (see e.g. the way @dnadlinger set it up for ndscan).
We are running 3 labs from the same lasers so having it on the GUI probably makes more sense for us in the near term.
We'll have a go at adding it.
I had originally planned to allow the wavemeter lock to be controlled from the GUI. There are two reasons this didn't happen: limited screen real estate; it turned out not to be very useful for our workflows.
The first of these can be worked around by putting the lock settings in a menu or something. But before doing that I'd like to understand a bit more about what your workflow is.
In my experience the main reason we want to lock a laser is to do something with the experiment like load an ion. In that case it makes most sense (as @dnadlinger said) to lock the laser in the experiment by putting the wand server in the device_db. That has nice features like one can catch the exception that is raised if the laser is already locked by someone else and either wait-retry or bomb out with a clear error message. If you want to automate things down the road then you'll need this anyway. It also removes one more thing that people can forget and not be able to load, which is always good. It's also nice because you can easily add an assert in the code to check if the laser has jumped to the wrong mode and come out of lock.
Another reason to lock lasers is to do some data acquisition (neutral fluorescence or whatever), maybe while scanning the laser. In that case the acquisition is usually being done via a python script or artiq experiment. Again, locking the laser in the data acquisition code tends to make most sense for the reasons above.
If you just want your lasers locked to the right place, the startup script is generally the best approach.
If all else fails, you can use a python terminal and rpc tool to send a lock instruction.
My question is what you're doing that doesn't fall into one of the above categories so that locking via the GUI is the best approach. Essentially, I'm happy to add new functionality if it's genuinely useful, but the codebase here is already big enough to impose a decent maintenance burden and I want to avoid adding more features/code unless there is a demonstrated use-case for them.
The first of these can be worked around by putting the lock settings in a menu or something. But before doing that I'd like to understand a bit more about what your workflow is.
It's more that we don't have a workflow yet because we are still setting up parts of the lab in relative isolation. We wanted to fire up and test our locks and we were like 'why is the lock box greyed out and unclickable?'.
Now we have an idea of how you actually ended use this in real life and where the docs are at, we'll see if we can live without the button.
Is there some minimal ARTIQ example code that could go in the docs to get people started or do you think it would end up with too many lab-specific idiosyncrasies to be useful?
Is there some minimal ARTIQ example code that could go in the docs to get people started or do you think it would end up with too many lab-specific idiosyncrasies to be useful?
@dnadlinger can maybe post some. But, what I'd say here is that the magic of RPC is that as soon as you stick the wand server in your device db you get access to the interface I linked above, so you can directly call any of those methods from your experiment.
otherwise, have a play with rpc_tool (it's ace!)
Yes, I'm sure you're right. It's the usual problem with all of ARTIQ - the tools are powerful and documented, but it's hard for students fairly new to all this to see how they can build them into their workflow. To be honest, just paraphrasing your comments above in the readme would be a start. Like, 'here is some cool ideas for how to integrate WAND in your lab'.
yes, artiq is actually one of the best documented projects I've used...for the bits where the documentation exists (e.g. not applets). One thing it is sorely missing is a bit of high-level context.
Anyway, PRs for documentation improvements welcome here. The usual paradox is that the only people with enthusiasm for writing docs are the ones who haven't understood the project yet.
shall we close this and open a new issue if you have further comments/questions after some playing?
Sure. We'll have a play with Sphinx too. Thanks.
@dtcallcock: It's literally just something like
class Enable1033Lock(EnvExperiment):
"""Enable 1033 wavemeter locker"""
def build(self):
self.setattr_argument("detuning", NumberValue(default=-600 * MHz, unit="MHz"))
self.setattr_device("wavemeter_lab1")
def run(self):
self.wavemeter_lab1.lock("lab1_1033",
set_point=self.detuning,
name=NAME,
timeout=None)Some docs that mention how to do this using sipyco_rpctool would certainly be appropriate, though.