indigo-astronomy / indigo

INDIGO is a system of standards and frameworks for multiplatform and distributed astronomy software development designed to scale with your needs.
http://www.indigo-astronomy.org
Other
139 stars 64 forks source link

LX200 - OnStep park function not working #447

Closed MerowingerX closed 7 months ago

MerowingerX commented 2 years ago

Version 2.0-176 Using with OnStep. The Park / Unpark - function does not work properly. OnStep offers the selection of starting "parked" or "tracking". I use "parked". It seems that the "Unpark" form "Parked" position does not work stable, The Mount stays in "parked", comamnd to unpark is not send to the mount. Two things:

I suggest to give in the user the option to change the park state and in indigo_mount_lx200.c only distinguish between "Parked" and "!Parked".

MerowingerX commented 2 years ago

Additionally the MOUNT_PARK_PARKED_ITEM->sw.value seems not to be set correctly...

Piece of code, that works in mount_changed_property:

else if (indigo_property_match(MOUNT_PARK_PROPERTY, property)) { // -------------------------------------------------------------------------------- MOUNT_PARK indigo_property_copy_values(MOUNT_PARK_PROPERTY, property, false); if (!PRIVATE_DATA->parked) { if (MOUNT_TYPE_MEADE_ITEM->sw.value || MOUNT_TYPE_EQMAC_ITEM->sw.value || MOUNT_TYPE_ON_STEP_ITEM->sw.value) meade_command(device, ":hP#", NULL, 0, 0); else if (MOUNT_TYPE_GEMINI_ITEM->sw.value || MOUNT_TYPE_ZWO_ITEM->sw.value) meade_command(device, ":hC#", NULL, 0, 0); else if (MOUNT_TYPE_AVALON_ITEM->sw.value) meade_command(device, ":X362#", NULL, 0, 0); else if (MOUNT_TYPE_AP_ITEM->sw.value || MOUNT_TYPE_10MICRONS_ITEM->sw.value) meade_command(device, ":KA#", NULL, 0, 0); PRIVATE_DATA->parked = true; if (MOUNT_PARK_PROPERTY->count == 1) MOUNT_PARK_PARKED_ITEM->sw.value = true; indigo_update_property(device, MOUNT_PARK_PROPERTY, "Parked"); } else { if (MOUNT_TYPE_EQMAC_ITEM->sw.value) meade_command(device, ":hU#", NULL, 0, 0); else if (MOUNT_TYPE_GEMINI_ITEM->sw.value) meade_command(device, ":hW#", NULL, 0, 0); else if (MOUNT_TYPE_10MICRONS_ITEM->sw.value || MOUNT_TYPE_AP_ITEM->sw.value) meade_command(device, ":PO#", NULL, 0, 0); else if (MOUNT_TYPE_AVALON_ITEM->sw.value) meade_command(device, ":X370#", NULL, 0, 0); else if (MOUNT_TYPE_ON_STEP_ITEM->sw.value) meade_command(device, ":hR#", NULL, 0, 0); PRIVATE_DATA->parked = false; if (MOUNT_PARK_PROPERTY->count == 1) MOUNT_PARK_PARKED_ITEM->sw.value = false; indigo_update_property(device, MOUNT_PARK_PROPERTY, "Unparked"); } return INDIGO_OK; }

polakovic commented 2 years ago

For OnStep dialect park property is reduced to a single item (line 744), so it doesn't represent the state, it can just trigger parking.

MerowingerX commented 2 years ago

Yes, in Line 897, two conditions must be met to unpark. The boolean parked must be true and the property parked must be set. In connect, the boolean parked is set to "false" and the property is initalized to "not marked". When the OnStep is started up parked, this does not match. There seems to be no possibility to identify the current status of the mount. In this case, it seems that the UNPARK action does not do anything, because the mount is marked to be unparked.

Additinally (and maybe here is the problem) at the end of UNPARK path (line 908, the magic lines " if (MOUNT_PARK_PROPERTY->count == 1) MOUNT_PARK_PARKED_ITEM->sw.value = true; " are missing.

Fix possibility: If the mount does not support a park state, it could be a solution to execute the command of park or unpark even, if the mount is already parked or unparked. There is no risk to do this and it reduces the number of possibilities. With the double check of (PARK/UNPARK) and (property), two of the four possible combinations are not implemented.

polakovic commented 2 years ago

I'll check if "park" really works with OnStep simulator, it is easily possible there is some bug. But we'll not add dummy unpark option. The definition of the property is, that if the mount has park and unpark function, it has park and unpark items (one-of-many switch representing the state), otherwise it has just park item (a trigger).

MerowingerX commented 2 years ago

Ok, I simply prepared three funny small videos to show you the effect. Maybe you have time to watch them, if not please send me a message, then I would delete them, I hope, the issue gets clearer... :-)

https://drive.google.com/file/d/1-fKTVd_7alo2tbQ2ir0QsYoWYo4MZWoW/view?usp=sharing https://drive.google.com/file/d/1-eY5YEbMl47zYA0A6033kVeIfCU0U4w9/view?usp=sharing https://drive.google.com/file/d/1-cwmEZvOzr-0Yve6bwfv3dOLsFVv6AYP/view?usp=sharing

rumengb commented 2 years ago

Hi I watched the videos. I see the problem but I also see that your solution also does not work correctly. It says tracking while actually it is not tracking. So it is not solving the issue it is creating another. Is there any OnStep simulator or something I can use to try to debug the problem?

polakovic commented 2 years ago

LX200 simulator supports OnStep dialect. I’ll look at it.

MerowingerX commented 2 years ago

Yes, the tracking in AIN Imager was not in my focus, The solution only allows park+unpark, but status may be inverted. Tracking I think is a second issue, I am not sure that the fix is responsible for this (the modified code only affects park property). I have here only the real life OnStep.

MerowingerX commented 2 years ago

Additionally I want to remember, that the OnStep controller allows by configuration to be started "Unparked + Tracking" or "Park + Not Tracking". I use the last one, I think most users will do so

https://onstep.groups.io/g/main/wiki/26601#TRACKING

rumengb commented 2 years ago

Actually, Ain just visualizes the status of tracking and parking etc... is just shows the state of the property from the driver. So It is some issue with the driver....

polakovic commented 2 years ago

I looked at the code one more time. In LX200 protocol there is in general no command for checking parking state, that's why MOUNT_PARK property is not set to BUSY and later to OK. It looks, that the only exception is OnStep and its :GU# command. I'll add a specific code for it during refactoring to asynchronous template soon.

On the other hand, there is no command in general and also in OnStep dialect to detect tracking mode. If you know how to do it, let me know :)

I tried parking with OnStep with the simulator and it seems to work correctly. Pls. can you make a trace log to see the communication with the mount?

MerowingerX commented 2 years ago

It seems that the simulator is not exactly what the OnStep is doing. Additional I have to correct something: When starting up, the mount is NOT TRACKING and AT HOME. This is not the same as "PARK". In the OnStep - App the Park und Home Status at Startup is handled as the same thing.

There is the command ":GU#" that allows you to get the current Status, I took this information from the reality, the current code in OnStep 4.24g, file "command.ino"

:GU# gives you as Information:

I added some examples here as attachment

OnStep-Status.txt

rumengb commented 7 months ago

The issue is fixed