Major INDI Library release v1.9.0 bring significant internal changes championed by @pawel-soja to modernize core INDI Library drivers and clients. New drivers for DeepSkyDad Flat Panel & Pegasus devices plus further improvements to PCM8 drivers.
Apologies if this is essentially a duplicate, I thought I'd responded already, but don't see it.
There shouldn't be anything causing that, but I have in the past had issues that sound similar with a build from non-clean. I'd make a new build folder and see if it keeps happening. I haven't touched any of the park code. It mostly comes from @azwing and/or the lx200 base. However, I don't see any changes there. Can you turn on verbose debugging and post a log? (It should show :hR# and/or :hP# being the unpark/park commands)
Hello to the group,
I am in the process of setting up a CGE mount with OnStep using KStars remotely through Stellarmate on a Pi4. To be honest, I am lost on getting the meridian flip to work. The mount is a GEM, has limit switches and PEC installed, but for now, I just need it to slew and flip when it should. Can someone post their settings for both the OnStep and KStars to accomplish this? i.e. Does KStars setting for meridian flip control the OnStep, or, Does OnStep flip independently of KStars? Does one turn off meridian flip in, say, KStars and use just the OnStep?
For better or worse, there's not really a good way to do it. Kstars/Ekos/INDI doesn't really trigger a meridian flip specifically
, it just does a goto. The good news is we can replicate that.
(From memory, so apologies if any of this is off.)
What is done internally for OnStep is things are compared in location to preferred pier side. Which can be best, west, or east.
What the 'command' for meridian flip does is set the perferred to be east (or west, I've turned myself around I think) then a goto. Best from my recollection prefers to keep it on pointing east if already there (think re-centering target), but if not and it's in the overlap, but close it'll move to pointing west.) So if you set it to pointing west (which should be east) it does the same thing if you issued the meridian flip command. Assuming it's within the limits. (Otherwise neither does anything.)
The limits that you set on things are the auto meridian flip limits in OnStep, and it should be set to ON for the auto meridian flip, with home pause set to off. The Ekos setting is the HA to set it before is Mount/Meridian Flip, and that needs to be set lower than your auto flip limit, if you want kstars to know about/initiate the flip.
Hope that helps. Apologies for it being from memory as I seem to have misplaced the cable for my test board (a mega without anything on it) (Tiny hopefully amusing rant: I can find micro, usb-c, and mini cables, along with nikon camera cables, but not old usb1/2 full size cables. Anyone remember when this was promised as a single universal standard so we wouldn't need serial port converters? Ha! /rant)
Thank you for this. I may have to check what settings I programmed into my OnStep. Unfortunately, the CGE mount can not pass the meridian by much of anything without causing a serious mount to mount crash. Its now no wonder Celestron moved on to their present day designs. This is causing me to not trust the mount will flip or even stop before it crashes.
If you should find your cable or remember any other specifics of what settings you used, please do post some more. Thanks again,
I have a problem with the last version of indi_lx200_onstep with Kstars 3.4.3 (not tested with older Kstars versions).
If i park or unpark mount, kstars segfault.
It works fine with the older version of lx200_Onstep driver (1.8.5).
The new version (with weather) does not seem to worki for park/unpark (segfault on Kstars)
I just tested with lx200_onstep in simulation mode and same problem: kstars crashes.
Tested with lx200_teenastro (simulator): OK
Test with EQmod (simulator): OK
Test with the previous version of lx200_onstep: OK
I think there is really a problem with the latest version of lx200_onstep.
However, the latest version of lx200_onstep works perfectly with "skychart".
Just tested with kstars 3.4.2: same result with lthe last lx200_onstep -> crash on park/unpark.
I can confirm your test on my rig also - wrote a long winded test report on facebook group with a number of combination tests:
Major issue with latest release - Crashing KStars and Ekos when using the updated LX200_OnStep driver under EKOS:
all Cameras OK
Able to capture pictures and plate solve
Mount connects and PHD can connect to INDI and the mount
Crash happens when attempting to UNPARK - immediate death of KSTARS/EKOS but INDI is still running.
PHD can still connect to INDI server for the mount despite KSTARS/EKOS being dead
prior to crash all control tabs are ok and setting can be set expect unparking
Mount is OK and controllable via OnStep application and can UNPARK, move, PARK with no issues
With KSTARS/EKOS dead i connected to mount with its app and UNPARKED....restarted Ktsars and pressed NO to the restart server warning (since INDI was already left running) and the EKOS panel shows the mount in a tracking state - so I know that the status and connection is alive
Able to control mount via Kstars goto while in this state (which means this is a work around of whatever the issue is)
Since the latest update it seems there is new feature that may be related as it never blocked unpark before - the dome status (I do not have a dome and driver has set itself to simulator) - parking and unparking is impacted by this setting whihc is always starting in DOME LOCKED despite changing the setting on each start up
After successfully connecting and moving/goto and checking all other devices - I pressed PARK and immediately crash EKOS/Kstars
However the COMMAND to park has reached the mount and it has successfully moved to park position
Conclusion - Bug in LX200_OnStep or Mount controls panel in EKOS directly related to PARK controls and STATUS incoming messages (since the mount parked we know the outgoing message was OK....but the EKOS dies on (suspected) the return status
Was able to recreate at will
There is NO indication of issues in the logs - they just end on crash
No photo description available.
follow on updates as I tested:
Jamie Flinn addition - when PARKING via the mount application, the status is NOT being updated in EKSO/KSTARS are they show only the last GOTO position
Edit or delete this
· Reply · 2h
Jamie Flinn addition - appears that general DISCONNECT of device via the button on the main EKOS panel is also affected as the Crash was also induced by pressing this button (most likely trying to work the OnStep driver?)
Edit or delete this
· Reply · 2h
Jamie Flinn addition - using telscope simulator = no crash. conclusion the LX200_OnStep dirver is the problem and has a defect related to park/status
Edit or delete this
· Reply · 2h
Jamie Flinn addition - restart with mount in PARK as per OnStep app and status in EKOS is IDLE (wrong)...unpark via ONStep app...status changes in EKSO to TRACKING (correct)....this indicates the processing of status is no longer stable as prior to this release PARK was alway properly indicated
So this was reported by Dan and I can confirm it. There is a bug in Ekos is that it cannot handle Mounts that define WEATHER_INTERFACE. The problem is quite complex since Ekos uses decorator pattern to "upgrade" generic devices to concrete classes of one specific type (telescope, camera...etc). Right now, so right now, once the device is identified as Telescope, its class is ISD::Telescope. However, when it detects weather properties, it tries to send the same pointer to the Weather handling class, which them just casts it to ISD::Weather since it assumes it was initialized as such, when it wasn't. There it would crash since it's trying to use ISD::Weather signals on an ISD::Telescope objects and all kind of weird stuff happens leading to a segmentation fault.
I started working on a fix, but it was pretty complex and requires major re-write for some parts because you actually DO need two instances to handle different aspects of the driver separately. This change started snowballing and I decided to delay it post 3.4.3. Maybe there is another solution in which the driver defines a separate WEATHER device along the mount, but really the driver should not work around client bugs. However, this might make it easy for other clients to handle as well.