Continuous Engage

[philipstarkey]

Original report (archived issue) by Kevin Cox (Bitbucket: kccox).

---

Hi Guys,

I'm a postdoc working in the lab with David Meyer. I'm starting up an atom-cavity QED experiment (not BEC). I want to add a control to continuously compile and run the labscript. David hinted at our desire to do this in issue #44. But what might be easiest, is just to add a button to runmanager that will "engage" every "x" seconds. I'm thinking about adding this in our code presently. After a quick google search, it looks like we could just use the QTimer class to call the engage event over and over. Is this a decent idea? Do you have any advice on how to do this the best way?

Further, what would make this functionality even better (but probably isn't absolutely critical for us right away), is for runmanager to check and make sure blacs has finished before engaging again, so the queue doesn't keep filling up and to make sure the experiment rep rate is actually what you want (that is, x). But it seems like this would require changing blacs as well, to communicate with runmanager about when runs are finished, or maybe if the queue is empty. We may pursue adding this in our code as well.

Overall, I think for higher rep-rate experiments, having a continuous compile and run is an important functionality. It allows the person running the experiments to tweak things and do feedback on the fly, without having to hit engage over and over again. So, if we get this working well, would you like us to make a pull request?

[philipstarkey]

Original comment by Chris Billington (Bitbucket: cbillington, GitHub: chrisjbillington).

---

Hi Kevin,

Whilst you're free to implement something quickly to get this working for your purposes, this functionality would also be provided by my plans to add a "compile queue" to runmanager. In order to have per-shot feedback, I'm going to have to introduce requests from BLACS saying "My queue is empty now, please compile and send me the next shot!" or perhaps "I have only one more shot in my queue, please compile and send me the next shot" if you want to "pipeline" with a buffer of one shot to ensure the compilation isn't decreasing your duty-cycle (at a cost of the feedback only taking effect the shot after next rather than the next shot).

If I do this, then the runmanager compile queue will gain a "repeat final" mode just like the BLACS queue - and perhaps will simply inherit the setting from BLACS and not have its own (or perhaps vice-versa) - in which case you'd get the functionality you want, including avoiding producing a backlog in the BLACS queue.

So implement what you like to solve your immediate problem, but I think it's unlikely to make it into the mainline if you made a pull request. In which case you needn't make it be a quality implementation, if it's going to be superseded!

Although I've been juggling all the pull requests coming in lately and the push for Qt5 support, my priority with labscript development otherwise has been to make the JQI fork and mainline converge, which would entail this feedback business and a compilation queue for runmanager. So that's just a way of saying that it's a priority - I can't even use mainline labscript in my own lab until it's done!

So if the 3rd party pull requests calm down, as it looks like they will, I'll have more time to move things along with getting the JQI features into mainline, and this is next on the list!

[philipstarkey]

Original comment by Jan Werkmann (Bitbucket: PhyNerd, GitHub: PhyNerd).

---

I broadly support something along the lines of
continuous engage. We have a very bad implementation of something like this (which needs changes to all devices) running in our lab right now with a even worse implementation of issue #44. I'm working to replace both with Pull request 12 in combination with BLACS's repeat last feature, delete repeated shots and some key combination to compile quickly while in editing mode of a global.

However I'm stuck at the quick edit of globals. Which is kind of unfortunate, but @chrisjbillington indicated that he would help there.

@chrisjbillington I still have quite a long list of things that our lab wants implemented, but those will probably take time. So at least from my side of things there should be not to many pull requests in the near future.

[philipstarkey]

Original comment by Kevin Cox (Bitbucket: kccox).

---

Hey Chris,
That all sounds great. We continue to benefit from your hard work. Here's what we will do. If you think you will have a pull request for the new stuff in the next week or two, we will just wait for that. If you think it may be a little longer, we will go ahead and do something quick and temporary in our own code. Just let me know if you have a rough estimate for your timeline. Also, let us know if there is any way we can help you.

[philipstarkey]

Original comment by Chris Billington (Bitbucket: cbillington, GitHub: chrisjbillington).

---

I think it will be a little longer than that unfortunately! I'd say about 1-2 months. So do with that what you will, and I'll let you know if it's looking likely to materialise sooner. Realistically it will be done over the course of a few days, but I don't expect to get to it for at least 2 weeks, and more likely longer - so 1-2 months might be a reasonable estimate.

[philipstarkey]

Original comment by David Meyer (Bitbucket: dihm, GitHub: dihm).

---

Finally got around to putting our hack together for this today and figured I'd post the diffs here in case anybody else desperately needs the functionality while we patiently and graciously await your work on the more complete compile queue. It is simple, but effective.

In main.py

#!diff

@@ -1350,8 +1350,24 @@
             # Defer this until 50ms after the window has shown,
             # so that the GUI pops up faster in the meantime
             self.ui.firstPaint.connect(lambda: QtCore.QTimer.singleShot(50, load_the_config_file))
+            
+        # add a timer to check cycling status every X seconds
+        self.timer = QtCore.QTimer()
+        self.timer.timeout.connect(self.cycler)
+        # start timer with default time, set in main.ui to be 1s (1000ms)
+        self.cycle_time = int(self.ui.doubleSpinBox_cycle_time.value()*1000)
+        self.timer.start(self.cycle_time)
 
         self.ui.show()
+        
+    def cycler(self):
+        # every timeout check if engage should be sent and update timer timeout
+        if self.ui.checkBox_cycle.isChecked():
+            self.ui.pushButton_engage.click()            
+        
+        self.cycle_time = int(self.ui.doubleSpinBox_cycle_time.value()*1000)
+        if self.cycle_time != self.timer.interval():
+            self.timer.start(self.cycle_time)
 
     def setup_config(self):
         required_config_params = {"DEFAULT": ["experiment_name"],

And in main.ui

#!diff

@@ -274,6 +274,72 @@
            </property>
           </widget>
          </item>
+         <item>
+          <layout class="QHBoxLayout" name="cycle_layout">
+           <property name="spacing">
+            <number>0</number>
+           </property>
+           <item>
+            <widget class="QCheckBox" name="checkBox_cycle">
+             <property name="toolTip">
+              <string>Auto-Engage Every X seconds</string>
+             </property>
+             <property name="text">
+              <string>Cycle every</string>
+             </property>
+            </widget>
+           </item>
+           <item>
+            <widget class="QDoubleSpinBox" name="doubleSpinBox_cycle_time">
+             <property name="sizePolicy">
+              <sizepolicy hsizetype="Minimum" vsizetype="Fixed">
+               <horstretch>0</horstretch>
+               <verstretch>0</verstretch>
+              </sizepolicy>
+             </property>
+             <property name="baseSize">
+              <size>
+               <width>0</width>
+               <height>0</height>
+              </size>
+             </property>
+             <property name="toolTip">
+              <string>Cycle Time in seconds</string>
+             </property>
+             <property name="buttonSymbols">
+              <enum>QAbstractSpinBox::UpDownArrows</enum>
+             </property>
+             <property name="specialValueText">
+              <string/>
+             </property>
+             <property name="correctionMode">
+              <enum>QAbstractSpinBox::CorrectToNearestValue</enum>
+             </property>
+             <property name="prefix">
+              <string/>
+             </property>
+             <property name="suffix">
+              <string>s</string>
+             </property>
+             <property name="decimals">
+              <number>1</number>
+             </property>
+             <property name="minimum">
+              <double>0.100000000000000</double>
+             </property>
+             <property name="maximum">
+              <double>99.900000000000006</double>
+             </property>
+             <property name="singleStep">
+              <double>0.100000000000000</double>
+             </property>
+             <property name="value">
+              <double>1.63eba9501d1b4a63288ea4c1d672beca39f284f1</double>
+             </property>
+            </widget>
+           </item>
+          </layout>
+         </item>
         </layout>
        </widget>
       </item>