Thank you for always doing a wonderful job.

I summarize what I asked several times in the past.
As a conclusion, in both functions, the default setting, the type of mounting (ALT & AZ, equatorial mount), registration of the home position (in the case of ALT & AZ = orientation 0 altitude 0 or azimuth 90, altitude 0, etc. in the case of equatorial mount North Pole) is required. (Currently missing.)

(The latitude, longitude and time of observation are also necessary, but this is already implemented.)

About the alignment function
It is classified into three types largely depending on mount function.

1. Those without a hand controller (DSC, EQMOD, SynScanALTAZ, etc.)

Since the mount does not have location information at the initial stage, the following information is necessary.
· Home position (in the case of ALT & AZ = direction 0 altitude 0 or azimuth 90, altitude 0, the north pole in the case of equatorial mount)

· Mount type (ALT & AZ, equatorial mount)
· Latitude, longitude, and time of observed values ​​(already mounted)

Against the above initial setting
As additional information

· Registration of alignment points (registration of alignment module in mount model)
· Register PARK information (not required for DSC, SynScanALTAZ)

2. Hold hand controller and there is no encoder information on mount
(Most equatorial mountains are applicable)

 · Read latitude, longitude, time information of observation value of hand controller, or
　Write the latitude, longitude, and time information of the observed value to the hand controller.
 · Read home position information of hand controller, or
　Write home position information on hand controller.

For the above initial setting
As additional information

· Registration of alignment point (Mount model of alignment module and registration in hand controller)
· Register PARK information in hand controller (Send park controller off hand controller to move to home position when power is off)

* Same as 1 when hand controller is not used


3. Hold the hand controller, mount the model to store the encoder information
(Some luxury machines)

· Read the latitude, longitude, and time information of the observed values ​​of the hand controller.
　Write the latitude, longitude, and time information of the observed value to the hand controller.
· Read the home position information of the hand controller.
　Write the home position information in the hand controller.
· Read the alignment point of the hand controller or write the alignment point to the hand controller.
　Read the park point from the hand controller or export the park point to the hand controller.

For the above initial setting
As additional information

· Addition registration of alignment point (Mount model of alignment module and additional registration to hand controller)

* Basically, the above items are always synchronized with the mount hand controller.
Please add only alignment point.


About the PARK function

If you release the park with the default value currently, there is a danger of destroying the mount.
As INDI continues to increase users, it is necessary to eliminate dangerous conditions.

The realization of the park function is complicated and varies depending on the mount, but if the information described below is complete, it is safe to release the park.
As for DSC and Synscan ALTAZ, park information is unnecessary and should be deleted.

INDI absolutely necessary information
· Mount's home position (it becomes the reference point of mount)
· Latitude, longitude and time information of observation site
· Park position information (acquired at an angle from the home position)

※ If you cancel the park return to the home position.


at the end

INDI is a wonderful integrated environment. I think that more people will use it from now on.
In the current situation I think that there is a state that requires attention to the alignment function and park function.

If these are improved, it will be beneficial to many INDI beginners.

Supplement

Alignment model is a great feature, but it is based on the use of Solver of the captured image.
It is also useful for those who do not shoot if they can be added to the alignment model from the Kstars sync command.

Thank you for the detailed report! INDI drivers already initialize startup parking position (assuming equatorial mounts) when first used. The user can change this position to any custom position. For alignment, this heavily depends on the underlying system. Basically, you need to have a mount that supports SYNC. For those with internal mount model (i.e. Meade, Celestron..etc), alignment is simply Solve-Sync-Slew and repeat kind of process.

Thank you for always having great support.

Regarding the alignment subsystem, you can use it with equator mount when used with ALTAZ mount, I think that alignment is easy if you can choose home position.
In particular, in the park function, if the home position is set as a reference point and the park position is not angle-designated, the mount may be destroyed.

In the case of SynscanALTAZ, first need to unlock the park, but due to the characteristics of this mount, you do not need a park. Rather, this is the cause of the inhibition of alignment.

Because of the excellent mount model function of the alignment module, I would like to use this function with a mount that does not use a camera such as DSC.
(DSC users can also use this useful function if they can register on the mount model by entering the sync command on the star map).

In the case of synchronization, when not using the hand controller, it can be used when there is position information described in 1 of the first utterance of the computer side.
Celestron has a PC application nexremote, but you can not use a hand controller when using nexremote.
I do not think we need to be bound by a hand controller.
If INDI sets the information described in 1 of the first utterance,
I think that it can be controlled with INDI without registering the first observation place, time, 2 star alignment etc in the hand controller.