wx.timer polling power from my deepstar makes cockpit sluggish

[juliomateoslangerak]

I used to have an issue on my deepstar reading the power. For some reason that I never identified it was taking time to get an answer. Tired of troubleshooting this, I just put a sleep(.1) and done. However, now cockpit is very sluggish after last merges. I found that the gui is polling the power every 500 msec and that is calling that sleep. If I remove the sleep, things are not much better as there are errors thrown back. As I see I have a 2 options.

• Try to figure out what the issue is with my Deepstar (I really checked the code and it is identical to master apart from the sleep). Anyone had a similar issue? I already tried connecting it through another (newer) PC to see if it had something to do with that.
• Not checking from the laser the power but just returning the set point (the laser does not have the APC option anyway). Do the Deepstars at Oxford have this APC? might that be a reason why mine is slower to return power?

Any other idea?

Maybe more of a microscope issue after all

[juliomateoslangerak]

Actually I'm not sure of my interpretation. I made the deepstar return the power set-point without asking anything but the gui continues to be "shuttered".

[juliomateoslangerak]

Let’s put a hold on this. It seems that this is not an issue when I start cockpit from the terminal. i have to look further into this.

[iandobbie]

I cant remember if the Oxford deepstars had the ability to return power levels, but having it interrogated that often does seem a bit excessive. The idea is to have a valid number on the interface but probably once per s would be plenty, even then it might be better to think about doing it rapidly if you see or expect a chnage and then having less frequent polling.

[juliomateoslangerak]

So I check on this and indeed running through the terminal is not sluggish cause it uses the installed cockpit version and not the development branch. So the issue is valid.

I'll try to change the polling to 1 per sec to see if this changes behavior.

[juliomateoslangerak]

I spent some time over this and for some reason, my deepstar is unreliable returning data. At least when getting on state and getting the power. When cockpit polls power every 500 msec it calls get_power which calls get_is_on to return 0.0 in case the laser is not on. This call fails exactly every second time to get the real state. I replaced the call with the buffered enabled property, then the call to the power fails every second time. Putting some sleeps solves this problem but cockpit remains sluggish.

The only solution I see is to, as my laser does not have the APC, is to return the buffered power. My minimal _do_get_power function looks like this

    def _do_get_power(self) -> float:
        if not self.enabled:
            return 0.0
        else:
            return self._set_point

This is really a microscope issue so I can transfer it over there.

[juliomateoslangerak]

Follow up on https://github.com/python-microscope/microscope/issues/58

[iandobbie]

I agree that the deepstar sluggishness is contributing to this issue but is it sensible to be reading laser power every 500ms? Why not every 5s, unless we have changed it and actually want to kmnow which could be included in the enable code if needed.

[juliomateoslangerak]

We may indeed reduce the frequency of polling. Still, it is worth considering why this is freezing the GUI. Are alternatives to this (eg, async). There might be some slow devices to answer or many devices.

[iandobbie]

The current setup it pretty simplistic. I think a async call would be much more sensible. I will have a tink about how to set it up.

Current code is at line 78 of gui/mainPanels.py just for reference