UI become slow/unresponsive when connected to an Alpaca cover

[admin]

Hi Julien,

I do have OmniSim installed and have just had another go at getting it to act as if there is no calibrator present, but it isn't behaving as I would expect - if I set the status to 'NotPresent' in the settings page for the simulated cover/calibrator then it still reports 'Off' when connected in SharpCap (or in the web UI for the simulators). I will try updating my ASCOM platform just in case that is a bug that has been fixed, but it's odd.

I have a Linux box that I can run a bit of python on to test out your own Alpaca driver (or, I expect that WSL Linux on Windows would probably be fine).

cheers,

Robin

[julien.t]

Hi,

OK, I also get strange behaviours with the Omni-Simulator. I only manage to get two different values :

4 (Unknown) when the driver is not connected. Which is, according to the documentation, incorrect. I should get an error/exception.
0 (NotPresent) in every other case when connected. Even if I set "Off" I get 0

My project is here : https://github.com/elendil-software/MiP ... ee/develop

[admin]

Hi,

after replying yesterday, I updated my ASCOM Platform install to 7.1.3, and after that update the OmniSim cover behaved as I would expect - I got a result of 'NotPresent' from the calibrator state when I had set up 'NotPresent' in the settings. When I did that, SharpCap behaved as I would expect in that situation - no crash, the UI showed no info for the calibrator.

I have downloaded your source and will test it out later to see if I get the same effect there or if I can repro your problem - will report back soon.

cheers,

Robin

[admin]

Hi,

well, I tried... I got a micropython environment running under ubuntu, I trimmed out parts of the code talking to servos, I installed some packages and downloaded and unzipped others and eventually the code ran to the point of trying to open the socket to listen on it, and I get E_PERM, and then trying to run micropython sudo went weird and I gave up

Can you test out with the SharpCap option to log additional info from Cover/Calibrator hardware communications - if you turn that on in the logging options it will record fairly low level (close to ASCOM driver) the communication between SharpCap and the device. If you can also log the requests on the server side too, it would let me match up the two logs and see what is going on.

cheers,

Robin

[julien.t]

I will try to add logs on the server side. I don't know how to do that yet.

In the meanwhile, I enabled the additional log for the cover.
A few things I noted :
- calibration state seems to be correctly detected, the related buttons are disabled.
- I tried to open/close the cover several times without any issue
- In the log I can see a few errors related to get_connected. But this doesn't prevent to open/close the cover subsequently
- if I tried to change camera ROI, everything go wrong. I didn't managed to send the report, but I have the log file and a few report file I found in the Windows temp directory.

Regards,

Julien

[admin]

Hi Julien,

feel free to send any logs / crash reports to me by email. There is a 'Contact Us' link at the bottom of the forum pages that should work to pop up an email to the forum admin address - that will get to me.

cheers,

Robin

[julien.t]

I have sent the logs.

I will try to find out why there are connection errors. Maybe there is something wrong with the RPI Pico WIFI connection.

But that's a bit strange that everything seems to be OK until I tried something with the camera. When I change the ROI it crashes every time. When I focus it crashes sometimes, ...

Regards,

Julien

[admin]

Hi,

thanks for sending the logs - I can see a possible way that the scenario that you are seeing might happen, so I will resolve that issue in the next update and hopefully that will be the problem with the cover cured.

Feel free to send me bug report log files relating to the other problems and I will happily look at them.

thanks,

Robin