Page 1 of 1

Confirmation dialog on Park

Posted: Mon Sep 09, 2024 3:29 am
by scotticus
Hi there

I love the park feature, but it's wedged in right near the arrow buttons and it's super easy to fat-finger it.

Today I was working on a sunspot at high magnification, and I wanted to adjust the panning speed but hit the park by accident. There doesn't seem to be a way to cancel it--everything in the mount control area was grayed out.

Please consider adding a confirmation dialog before issuing park.

Thanks
Scott

Re: Confirmation dialog on Park

Posted: Mon Sep 09, 2024 2:29 pm
by kaymann
Actually the popup should include a cancel/emergency stop if cable snags are encountered and a stop is needed. The popup could disappear or change to "Park Completed" to signal it okay to move on the next procedure for shutting down eg. closing the dome etc.

I concur right now it is hard to know that the Park command was accepted, initiated, completed...

Re: Confirmation dialog on Park

Posted: Mon Sep 09, 2024 6:28 pm
by Tom°Dresden
I also had already problems with park. It is sometimes not clear if it is finished, and you can switch off mount in the middle of park sequence.
IMHO you can see in ASCOM the mount steps "Starting" "Slew to park" and "Finished" or "ERROR" .
It would be nice to see if park is really finished.
But IMHO it is not possible to stop park once it is started. Some other programs / ASCOM hub etc. show always a warning that you can not cancel a started park sequence.

Re: Confirmation dialog on Park

Posted: Mon Sep 09, 2024 8:35 pm
by admin
Hi,

thanks for the suggestion - I have been thinking about changes to this area, and confirmation and progress on park is a nice idea (oddly, as far as I can work out, there is no need to confirm for 'unpark' - that would probably just be annoying!).

There doesn't actually seem to be a documented way to cancel a park operation under ASCOM, so that part is tricky. It's possible that some of the things like cancelling a slew might work to cancel a park operation, but it would end up being dependent on the implementation of the individual ASCOM driver rather than something that would always work :(

cheers,

Robin