python-microscope
Deepstar comms issues
Following on from MicronOxford/cockpit#369.
Julio finds that the Deepstar comms work only if he adds a 0.2s delay into write, but at a point where it should have no real effect. Without this delay, it looks like responses are either echos of the laser command (e.g. see the 'power response' lines in the loging output posted at MicronOxford/microscope#369), or junk.
I've asked him to test it without the delay, with a microscope version at or after 849316ec897132825068d0601fbe4714bc5be02a.
If it works, great - the problem was resolved by 849316ec897132825068d0601fbe4714bc5be02a.
If it doesn't work, my suspicion is that it's something to do with either the comms config that Julio is using (does his USB serial adapter do some local echo thing?), or with the DeepStar's three-state business (although I've no idea why it works fine at Oxford, in that case):
- state 0, S0, an error state - expects 16-byte commands incl. CR/LF
- state 1, S1, state after successful boot/reset - expects 16-byte commands incl. CR/LF
- state 2, S2, state after successful LASER ON - expects 7-byte commands incl. CR/LF
If Julio's test is not successful, then we need to keep track of laser state, and pad the command strings to the appropriate width ... although how do you decide what width string to send when you first fire up the software and don't know the laser state?
This issue is biting me back now. See https://github.com/microscope-cockpit/cockpit/issues/887
Would this be an acceptable alternative to the current implementation of the function getting the power on the deepstar?
def _do_get_power(self) -> float:
if not self.enabled:
return 0.0
if self._has_apc:
self._write(b"P?")
answer = self._readline()
if not answer.startswith(query):
raise microscope.DeviceError(
"failed to read power from '%s'" % answer.decode()
)
level = int(answer[1:], 16)
return float(level) / float(0xCCC)
else:
return self._set_point
Seems reasonable so long as the maths is correct, sorry I dont have a deepstar here so cant verify the code:
level = int(answer[1:], 16)
return float(level) / float(0xCCC)
Other than confirming that the rest seems sensible.
Well, actually I did not change the math.
I changed the first two lines to call self.enabled in stead of self.get_is_on(), which requests the laser state. As, in the case of the deepstar being "enabled" and "on" seem to be the same thing, getting the "cached" status seems reasonable.
The second change is if the laser has no APC. Previously the function was requesting the set power, which is, by definition the _set_point.
I'm happy to keep these changes just for me if nobody else has the slow response of the Deepstar.
I was still thinking if this might be an issue related to the serial interface taking 16bytes when on and 7 when off.
On a side note, looking back into the code, it seems to me as if we are assuming a lot of the usage mode of the deepstar. eg when turning on we put it into digital modulation mode and other things. I guess that is the history of the code there, but we might think about making from those settings.
I didn't look at the existing code, I'm sure its fine. We can ask Tom to test the Diamond system which does have DeepStars. There is definitely an assumption that the lasers are only being operated in digital mode which was how we were using them in Oxford/Diamond. Yes this could easily be config based but would need some planning to ensure that Diamond system continued to work as expected.