Given your changes, I'd like you to look at the own-goto branch as it now has the changes so there should be NO status set from base classes. So it should be only update by our update, and should be consistently reported, and avoid the TrackState IDLE after a park.
I apologize for being quiet, and stepping on your toes about it, but I think it's actually a better solution. Unfortunately a lot of that delay was me upgrading and various changes. (Mostly related to me compiling things outside the package manager, and forgetting, plus resolving what turned out to be insofar as I can tell, a bit error on my SSD. (I don't think I've knowingly encountered that ever on a HDD, but might have if it's in data that's not processed by computer.)
The one change that I don't have in that branch is the Focuser hiding, but that seems to be pretty simple to add back in.
Unfortunately, KStars/Ekos does not pull directly from TrackState, so that didn't resolve the mount model issue. However, digging into it, it relies on EqNP's status as part of the Update using the TrackState. I've added updating that to the section after TrackState, so that should always be good as well. So finally solved? (Maybe.)
So far in my testing, That has eliminated all IDLE states when it's not actually idle except the very initial connect, and so far all instances of the Mount Model taking an instant photo. (Using an OnStep board, and CCD simulator, so that's limited testing and of course things are supposed to be not conducive to testing in the real world for a bit. ) So I think all of that is fixed, but not 100%. I do know in one case with TrackStateSP, there's something lower down that wants to modify it if slewing, so I had that only update if SCOPE_TRACKING to be on.
Anyway, Sorry for going quiet, now trying to catch up on some more things. (So I may be quiet again for a few days.)
we have an Old Story from Mr "Jean de La Fontaine" called the Haze and the Turtle.
So going slow and safe is also my view, otherwise I would have pushed to Indi Directly.
We can wait for pushing to Master for two reasons:
- Lamba use most probably do notice nothing because they do not use advanced features
- Advanced users can test your or my branch and test it if they want.
First test of your onw-goto is promising.
Everything worked fine.
I continue testing and review your code
2021-07-20T18:17:10 Shutdown complete.
2021-07-20T18:17:10 Ekos stopped.
2021-07-20T18:17:09 INDI devices disconnected.
2021-07-20T18:17:06 Dome parked.
2021-07-20T18:16:49 Parking dome...
2021-07-20T18:16:48 Mount parked.
2021-07-20T18:16:47 Warning: mount park operation timed out on last attempt.
......... a lot of waiting since meridian flip before parking
2021-07-20T18:14:53 Warning: mount park operation timed out on last attempt.
2021-07-20T18:14:52 Parking mount in progress...
2021-07-20T18:14:52 Warning: mount park operation timed out on attempt 4/5. Restarting operation...
2021-07-20T18:14:51 Parking mount in progress...
2021-07-20T18:14:51 Warning: mount park operation timed out on attempt 3/5. Restarting operation...
2021-07-20T18:14:50 Parking mount in progress...
2021-07-20T18:14:50 Warning: mount park operation timed out on attempt 2/5. Restarting operation...
2021-07-20T18:14:49 Parking mount in progress...
2021-07-20T18:14:49 Warning: mount park operation timed out on attempt 1/5. Restarting operation...
2021-07-20T18:13:48 Parking mount in progress...
2021-07-20T18:13:47 No jobs left in the scheduler queue.
2021-07-20T18:13:46 Job 'Navi' is complete.
2021-07-20T18:13:25 Job 'Navi' capture is in progress...
2021-07-20T18:13:25 Job 'Navi' slew is complete.
2021-07-20T18:10:17 Job 'Navi' is slewing to target.
2021-07-20T18:10:14 Mount unparked.
2021-07-20T18:10:12 Dome unparked.
2021-07-20T18:10:06 Unparking dome...
2021-07-20T18:10:05 INDI devices connected.
2021-07-20T18:10:05 Ekos started.
2021-07-20T18:10:00 Scheduler started.
I just tested with my setup.
I am unable to unpark the mount.
With the azwing driver the position of the mount on the map is correct and I can unpark the mount.
With the james-lan driver, the position of the mount on the map is wrong and I cannot unpark the mount.
I deleted the xml files just in case.
I will find out where it can come from.
Strange, I just made a test to reproduce your observation.
When I start Kstars and then Ekos I see the telescope where it should be and I have no problem with unparking.
Which xml files are you speaking about?
My park position is 0° alt and 0° az (telescope horizontal).
For the two drivers, in the mount tab, position is bad before unpark. But the reticle is good with your driver and not in the james driver.
It's very strange...
Same issue with Skychart (Cartes du ciel): Position is ok with your driver, not ok with james driver.
I'm confused: The only reason it shouldn't update are common to both as far as I can see from a diff. Either it should get a location in UpdateScopePosition, or it should fail in both cases, as that code is at the very front, do you have any: Error reading RA/DEC. messages?
I'd very much like to get a debug log if you don't mind, because I can't seem to reproduce what you have.
I do discover some odd behaviour with parking on a (fake) alt-az mount, namely that it seems sometimes to goto after an unpark?! (To where it was before the park.) Never have seen that on an EQ. I'm looking at it, but a log would be great to try to figure it out. I do seem to recall that as being something a while back though that I'd very occasionally encounter on startup?
I could reproduce your strange behavior.
After OnStep ColdStart and if Telescope was Parked I receive the Status "nNPH" which is At Home and Parked.
I checked OnStep response on :GR# and :GD# and effectively the coordinates are wrong RA=0 DE=0
After unparking whatver I do it in a terminal or from Kstars I get the right Parking RA/DE
So it is definitively not related to the driver.
Have a try to connect with my driver after OnStep Coldstart
Dear Alain, I've the Problem that I can't connect to my OnStep STM32F303 via KStars.
My System is a raspi 4 8G and I#M running Astroberry with KStars 3.5.4 and the last indi driver 1.9.1.
Since my last Update of Astroberry the System never worked again. My soft skills are limited.
My mount always stuck at DE=0 when I try to connect with Ekos and will not point to Polaris (Park Position).
I then have no possibility to control the mount.
In the indi tabs the indicator always become yellow and dont execute a command as it was previously the case.
The mount OnStep-Status tabs were left empty. The firmware figures were shown.
I cannot start an align procedure through indi.
What I discovered is that the traffic through my /dev/ttyUSB0 sends continuously the following messages what seems to be very strange.
I have set up in my Onstep config.h file some features like a DewHeater function called "DH-OHG".
Do you think that there is a problem with the OnStep firmware and a miscommunication with the indi driver that causes the failure?
I cannot understand why Onstep is sending those figures over the USB port, also because the Heater was switched off.
Perhaps I should ask Howard or Khalid if they know what could be the Problem.
All the best and thanks to your help and work since years as I read.
OnStep Firmware is 4.24g
Hardware : STM32 Bluepill with upgraded STM32F303 chip
Yes, that's related to the dew heater, and the new detection of features.
The gxy1 call should return the feature name and type.
It appears to be looping, but I'm not in front of the computer to look at the code. (Quickly looking at azwing's repo, I don't see anything that I would think could cause it, except repeated calls to update properties?) For a temporary solution, you might try removing that feature?
Bingo, after I have disabled the feature section, I got control over the OnStep STM32F303 controller.
Thanks for this hint.
I have to find another solution for my DEW Point heater. Something must be changed within Ekos or KStars that this happend. The systems runs quite stable without any failure before I updated kstars with Astroberry.
I'm planning to switch to MaxESPV3 controller where I can control a field-rotator with the second Focus stepper. The PCB is already fully equipped for testing. The Advantage of STM32 is the very low power consumption in comparison to MaxESPV3.
Thanks again James
Apologies for the long updates. Real life things I don't want to go into here.
There was a pull request which may help some cases regarding reporting status on V4
Right now testing my own-goto it's working well with git versions of Kstars.
I did discover an odd bug related to meridian flips on altaz: It would keep trying to do them, but in my branch I've removed the capability being reported by default and while it can trigger it only seems to once. Working on a patch to add detection to Kstars. Now the branch only reports if it's non altaz. Which seems to make it only do it once.
Right now I'm 2/6 through testing (working on 3/6) v3/4/5 EQ/Altaz before I make a pull request. Unfortunately power is out so the branch is not up to date right now. (Will probably see about X, but I don't think I have a near current pull) so far it and Kstars are working well, but Kstars still sometimes considers slew complete immediately. Fortunately it handles it ok now. (Mind I've got updates at something like 25ms to try to reproduce that.) Earlier Kstars did not handle that well.
I would like to get this merged before 1.9.2, if possible given the fixes. Not sure when @knro plans to release that (I would imagine very soon.) So if people can test it asap when I post next, I would massively appreciate it. If not, that's fine.