Yes Jasem, that is the root issue.
For me park is required to get to a fixed point to take flats and let the scope 'sleep', for other there are different reasons.
Andrew

So I added preliminary parking functionality to the sky sensor driver. After installing the nightly PPA tomorrow you can test parking. From KStars, select a point to park to from the sky map, and you should have an option "Slew to and Park here". After parking, it is set to LAND mode so hopefully that is enough to stop it from tracking. Try then later to unpark, it should put it to EQUATORIAL mode. I'm not sure if any of this would work so give it a go.

Mr. Jasem

Rather, the opposite.
Installing a park on a mount without a parking function will not function safely unless the above items are satisfied.

Otherwise it will be a very dangerous function.

My SkyWathcer Alt-Az is currently not working properly with both park and park off buttons.
The initial park setting of the driver is not functioning properly.
If you press the park button, the controller operation will not be performed properly.
So, I use it without using the buttons in the park.

The most problem at present

1. INDI has only one park setting file. (Using the same configuration file for EQ mount and Alt - Az mount is a source of trouble.)
Each driver needs its own park setting file.

2. The home position as the reference value is not registered in the park file. (I think that calculation is required for each of EQ mount and Alt - Az mount.)

The mount that the park normally uses memorizes the necessary information of the hand controller, so you can safely use the park function.
(I think that EQMOD has the information stored by the hand controller by software.)

As with Barker's suggested script, the driver needs to have information that can use the park safely.

The number of people using INDI, Ekos will increase more and more in the future.

Many of them expect to introduce it in expectation of a complete remote environment.

If you use a mount without a parking function, using this function increases the possibility of destroying the mount.
(If trouble occurs using the park by remote control, it is after trouble occurs that it notices ...)

Thanks Jasem, I'll try to test this weekend.

But as T-Studio points out there is a wider need (other drivers) and requirement for personalisation (Alt-Az park point). For example you've given functionality to select a point on Kstar sky map (Ra Dec), but we need a fixed know land (Alt-Az) point, i.e. Input box "Park position (Alt-Az)" = x,y

Takito, the SkyWatcherAPIMount was developed by Roger and Synscan driver was developed by Gerry among others. So now I'm visiting each driver and trying to asses the parking situation for those that do not natively support it. For SkyWatcherAPIMount the code is pretty advanced and not sure if I can "Fix" parking there easily. It would be great if someone with perhaps more time can step in and look at this particular driver.

Barker, yes I agree but as I said above I'll be checking all drivers that are missing this functionality on-need basis. Right now, you are parking to a specific Az/Alt in KStars actually. The RA/DE are internally converted to Alt/Az at the time you issue this command and then saved.

Mr. Jasem

Thank you for always being supported.

Please check the parking function of the driver of the mount which does not have park function.

Although INDI and Ekos are wonderful environments, it is dangerous to give parking rights to all drivers under the current specifications.

When turning on the power and leaving the park safely, the mount knows the current position and previously written information is the minimum information necessary to make the right movements.
(Alignment information is also stored in the mount corresponding to the park)

I think it will be multi-platform, I think users will increase more and more.

Before I understand this wonderful environment, it is sad that new users get confused and give up.

We are "faking" parking in the following sense:

1. Goto to desired Az/Alt
2. Stop tracking
3. Record Az/Alt in parking file

When user unparks, the following happens:
1. Mount is synced the parked Az/Alt
2. Tracking is resumed

Not sure if there is a better way to do this. Time/Location are always synced as well. The SkyWatcherAPIMount drivers uses its own parking/unparking routine which I am unfamiliar with and didn't get a chance to understand how it works. Hopefully Tarun can fix the issues associated with that driver.

Certainly, the parking function of this mountain has changed since the early days.

I think that it is probably a change to improve the behavior, but it is not functioning now.

I use this driver for EAA from the beginning of the announcement.

Items that seem to be bugs have been explained before

1. GPS information does not synchronize.
→ Enter the information directly from the site management tab of the driver.

2. General Park
→ When leaving the park, press stop on Ekos' mount controller, then
Move in any direction with the mount controller.

3. Mount information is not synchronized with solver option.
→ After moving the mount, press the button next to the solver option and update the mount position information by pressing the mount information update information from the detailed setting.

I am using this kind of operation to avoid problems and use it.
It is much more convenient and light than using Ascom.

1. What GPS information? There is GPS device or what?
2. I don't understand what that means.
3. Mount RA & DE are not reflected in solver option after slew is complete, is this what you mean?

I'm sorry that the response was delayed.

I am using the gpsd driver by incorporating GPS module in RaspberryPi3.

1. The information acquired by the gpsd driver is not reflected in the mount.
We copy and paste the information acquired by GPS every time.

3. After Slewing the mount, the optional part of the attached figure is updated with other drivers, but the SkyWatcher Alt-Az driver does not update it to the mount position.
Therefore, if you move the mount a lot, the solver becomes an error.

It has been updated with other drivers.

Both were working with other mount drivers (CelestronGPS in my case).

Telescope simulator also worked.

ps. Since I started up Pi inside the room, it is a figure not acquiring GPS information, but the GPSD driver is functioning normally outdoors.ps. Since I started up Pi inside the room, it is a figure not acquiring GPS information, but the GPSD driver is functioning normally outdoors.

Hi Jasem,

I was eager to test the new ss2k park function last week but clear sky abound for once!

Anyhow I did a quick first test at the end of last night session confirmed:-

1. park function appears in INDI Main control panel Parking: Park UnPark.
2. INDI Site Management appears to enable setting of Park Position as AltAz D:M:S
as test I input Alt 0:30:0, 260:0:0 and Set, then in Park Options I hit Write Data (I assumed this would be saved but this morning no data appeared after reconnect despite INFO screen showed 'Saved Park Status/Position)
It seems I forgot to do Options : Save Config since I re-did this morning and the Park position was saved.

3. at end of session I went to remote site so I could observe the Park function in action (always wary of runaway mount)
I saw there were several ways to operate Park function. from Kstars right click Skysensor then Park/UnPark or from INDI Main control or from EKOS Park or EKOS Mount Control Park. This is great I assume they all use same 'code'.

1st try : from INDI Main - after clicking (vnc from phone to PC) there was beep from handset (good) and audible change in motors but no movement towards park position.

2nd try : from EKOS Park.
handset beep and INDI panel shows ERROR error slewing to 260:0:0 0:30:0 Object below horizon
Tried setting Alt 2:30:0, 260:0:0 same result
By feeling the motors I can tell they are still tracking RA.

I Unparked and slewed to random spot and tried all again with same result.
It seems like same result when I tried my pyindi code i.e. there was comms with mount but the final 'goto' doesn't work.

The functionality feels great, if we can get it to work on ss2k it would be awesome.

Unfortunately I'd set logging off while I was imaging, sorry I know you need this, so I'll have to send logs from new session maybe tonight. Anything particular you want me to try?