Open EastEriq opened 5 months ago
Since that, all http requests to the mount address time out after 10 seconds; both via the uvicorn webby and via matlab (even after deleting and recreating M=obs.api.makeHttpApi('Location','LAST.1.unit11.mount');
.
got it again today after sending the mount to .goTo(...'eq')
, which is also a blocking function which may take ~20 sec
Why is .goTo() blocking?
Specifically now, because set.RA
is based on a tight polling loop. It is to ascertain whether I can achieve a comparable pointing precision switching to a timed polling, which would free the main loop and make it responsive to further lipp messages. There would be also the issue of preventing probing commands because polling communication with the controllers is in progress. Legitimate issues which call for some thoughts of redesign.
In general, though, I think that long response times are possible, since i/o is involved. I see no better solution than deciding, device by device, what is the tolerated timeout before declaring the device problematic, and trigger counteractions. Also this needs some thought on my side. However, in the first place I think that a non-responding driver process should not cause json errors, and ultimately bailout (which I suppose is what is happening as of now); no response should just be recorded as such.
All these thoughts are very wonderful, but the design is for things to be launched and not waited for. I vividly remember we were both in the same room when we both decided that was the way to go. Musing now about long per-device timeouts is somewhat futile, isn't it?
It is not musing, it is simply getting to one case situation where an implementation which was empirically acceptable for interactive use needs to be rethought (how to ensure reliable pointing prediction with timers, how to inform the probing function not to interfere with ongoing communication) (actitvity bits may be a solution). I'm not complaining about them, but about the disrupting json error.
don't know what this is. Speculation, because
.park
takes longer than the http timeout?In stdout, the log still shows periodically
"AnswersToProbe":true
for the mount probe.