indigo
indigo copied to clipboard
LX200 - OnStep park function not working
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:
- first the "Parked"-property does not change correctly in the AIN Imager (mount button remains "unparked", but it is parked.
- the code indigo_mount_lx200.c in method mount_change_property for this property only contains path for
-
- "!Parked" AND SW_Value
-
- "Parked" AND !SW_Value
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".
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; }
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.
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.
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).
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
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?
LX200 simulator supports OnStep dialect. I’ll look at it.
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.
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
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....
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?
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:
- tracking state
- park state
- goto state
- Guide state
- Pier side
- and some other things...
I added some examples here as attachment
The issue is fixed