Craig thanked Hans in topic 10Micron Mount Modelling 2 months ago

Hans replied to the topic 'Mount Model tab (module) issues' in the forum. 3 months ago

Hi mpfjr,

Do I understand right that you're trying to use the generic EKOS mount modeling system for a 10micron mount ?

As I see it the EKOS mount modeling system is a generic system that augments the pointing of a mount. Any mount.
A 10micron mount however has a built-in modeling system, far superior to what EKOS has (because fi. it uses the absolute encoders to model things like sag and mirror flop and also corrects for air pressure and air temperature).
The EKOS mount modeling system currently does not program that 10micron internal modeling system.

That said the EKOS mount modeling system should of course work. But I do not recommend to use it on a 10micron mount, I recommend to use its superior internal modeling system.
If you want to continue with the EKOS mount modeling system I have to defer to others here on this forum. I hope they can help you further.

If you want to program the 10micron internal modeling system then you have several options of which 2 work on Linux today (that I know of) : Either use the 'Alignment' tab in the 10micron INDI device driver by manually adding plate solved coordinate results. I have used this to make a model myself once. Or get MountWizzard version3 or later to automate the whole thing. I now only use MountWizzard together with a local installation of and the astrometry-api-lite interface to it that offers the same interface as . Sadly MountWizzard v3 is not released yet publicly, and the repo still only has 2.x branches. The good news is that the MountWizzard author is working on a new version.

Here's a screenshot of a recent model I made with it :

-- Hans


Hans replied to the topic 'kstars-bleeding 6:3.3.4+201908080145~ubuntu18.04.1 crash' in the forum. 5 months ago

(gdb) up 3
#3 0x0000564d1dfde790 in Ekos::Capture::processPreCaptureCalibrationStage (this=0x564d23bf4aa0) at ./kstars/ekos/capture/capture.cpp:5562
warning: Source file is more recent than executable.
5562 void Capture::toggleVideo(bool enabled)
(gdb) list
5557 }
5558 }
5559 }
5560 #endif
5562 void Capture::toggleVideo(bool enabled)
5563 {
5564 if (currentCCD == nullptr)
5565 return;

(gdb) up 1
#4 0x0000564d1dfde8cd in Ekos::Capture::updatePreCaptureCalibrationStatus (this=0x564d23bf4aa0) at ./kstars/ekos/capture/capture.cpp:2988
2988 abortedJob = job;
(gdb) list
2983 SequenceJob * abortedJob = nullptr;
2984 for(SequenceJob * job : jobs)
2985 {
2986 if (job->getStatus() == SequenceJob::JOB_ABORTED)
2987 {
2988 abortedJob = job;
2989 break;
2990 }
2991 }

No idea why abortedJob triggered yet.


Hans created a new topic ' kstars-bleeding 6:3.3.4+201908080145~ubuntu18.04.1 crash' in the forum. 5 months ago

kstars-bleeding 6:3.3.4+201908080145~ubuntu18.04.1

After capturing 6 frames kstars/ekos segfaulted with :

(gdb) bt
#0 raise (sig=<optimized out>) at ../sysdeps/unix/sysv/linux/raise.c:51
#1 0x00007f32a64257f9 in KCrash::defaultCrashHandler(int) () from /usr/lib/x86_64-linux-gnu/
#2 <signal handler called>
#3 0x0000564d1dfde790 in Ekos::Capture::processPreCaptureCalibrationStage (this=0x564d23bf4aa0) at ./kstars/ekos/capture/capture.cpp:5562
#4 0x0000564d1dfde8cd in Ekos::Capture::updatePreCaptureCalibrationStatus (this=0x564d23bf4aa0) at ./kstars/ekos/capture/capture.cpp:2988
#5 0x00007f32a0c4d0d4 in ?? () from /usr/lib/x86_64-linux-gnu/
#6 0x00007f32a0c410db in QObject::event(QEvent*) () from /usr/lib/x86_64-linux-gnu/
#7 0x00007f32a209682c in QApplicationPrivate::notify_helper(QObject*, QEvent*) () from /usr/lib/x86_64-linux-gnu/
#8 0x00007f32a209e0f4 in QApplication::notify(QObject*, QEvent*) () from /usr/lib/x86_64-linux-gnu/
#9 0x00007f32a0c119a8 in QCoreApplication::notifyInternal2(QObject*, QEvent*) () from /usr/lib/x86_64-linux-gnu/
#10 0x00007f32a0c69d8e in QTimerInfoList::activateTimers() () from /usr/lib/x86_64-linux-gnu/
#11 0x00007f32a0c6a589 in ?? () from /usr/lib/x86_64-linux-gnu/
#12 0x00007f329c151417 in g_main_context_dispatch () from /usr/lib/x86_64-linux-gnu/
#13 0x00007f329c151650 in ?? () from /usr/lib/x86_64-linux-gnu/
#14 0x00007f329c1516dc in g_main_context_iteration () from /usr/lib/x86_64-linux-gnu/
#15 0x00007f32a0c6a8ef in QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib/x86_64-linux-gnu/
#16 0x00007f32a0c0f9ea in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib/x86_64-linux-gnu/
#17 0x00007f32a0c18a84 in QCoreApplication::exec() () from /usr/lib/x86_64-linux-gnu/
#18 0x0000564d1dc99c92 in main (argc=<optimized out>, argv=<optimized out>) at ./kstars/main.cpp:331

The logfile has :

[2019-08-25T00:08:57.697 CEST INFO ][ org.kde.kstars.ekos.focus] - "Autofocus complete after 9 iterations."
[2019-08-25T00:08:57.699 CEST DEBG ][ org.kde.kstars.ekos.scheduler] - Checking job stage for "NGC 7000" startup 2 "24/08/19 22:54" state 3
[2019-08-25T00:08:57.699 CEST DEBG ][ org.kde.kstars.ekos.scheduler] - Checking Park Wait State...
[2019-08-25T00:08:57.705 CEST INFO ][ org.kde.kstars.ekos.capture] - "Ekos will refocus in 3600 seconds."
[2019-08-25T00:08:57.706 CEST INFO ][ org.kde.kstars.ekos.capture] - "Focus complete."
[2019-08-25T00:08:57.707 CEST DEBG ][ org.kde.kstars.ekos.scheduler] - Focus State "Complete"
[2019-08-25T00:08:57.725 CEST INFO ][] - "PHD2: Guiding Resumed."
[2019-08-25T00:08:57.726 CEST INFO ][] - "Guiding resumed."
[2019-08-25T00:08:57.727 CEST DEBG ][ org.kde.kstars.ekos.scheduler] - Guide State "Guiding"
[2019-08-25T00:08:57.727 CEST DEBG ][ org.kde.kstars.ekos.scheduler] - Calibration & Guide stage...
[2019-08-25T00:08:57.727 CEST INFO ][ org.kde.kstars.ekos.scheduler] - "Job 'NGC 7000' guiding is in progress."
[2019-08-25T00:08:57.728 CEST DEBG ][ org.kde.kstars.ekos.scheduler] - Get next action...
[2019-08-25T00:08:57.729 CEST INFO ][ org.kde.kstars.ekos.capture] - "Meridian flip configuration has been shifted to the mount module. Please configure the meridian flip there."
[2019-08-25T00:08:57.730 CEST INFO ][ org.kde.kstars.ekos.scheduler] - "Job 'NGC 7000' capture is in progress..."
[2019-08-25T00:08:58.353 CEST DEBG ][ org.kde.kstars.ekos.scheduler] - Checking job stage for "NGC 7000" startup 2 "24/08/19 22:54" state 3
[2019-08-25T00:08:58.353 CEST DEBG ][ org.kde.kstars.ekos.scheduler] - Checking Park Wait State...
[2019-08-25T00:12:00.858 CEST WARN ][ default] - QSocketNotifier: Invalid socket 8 and type 'Read', disabling...
[2019-08-25T00:12:00.858 CEST WARN ][ default] - QSocketNotifier: Invalid socket 16 and type 'Read', disabling...
[2019-08-25T00:12:00.858 CEST WARN ][ default] - QSocketNotifier: Invalid socket 10 and type 'Read', disabling...

The console :

The konsole shows not much help either
KCrash: crashing... crashRecursionCounter = 2
KCrash: Application Name = kstars path = /usr/bin pid = 8677
KCrash: Arguments: /usr/bin/kstars
KCrash: Attempting to start /usr/lib/x86_64-linux-gnu/libexec/drkonqi from kdeinit
[1]+ Stopped kstars
~/ $?=147 INDI server localhost/7624 disconnected.
INDI server localhost/7624 disconnected.
Unable to start Dr. Konqi
Re-raising signal for core dump handling.5


Richard Horn thanked Hans in topic INDI DSLRs FAQ 7 months ago

Hans replied to the topic 'Full Automation and Weather handling in the Scheduler' in the forum. 9 months ago

sterne-jaeger wrote:

Awesome. Do you generate kstars/ekos/observatory/observatory.ui with some tool ? and if so how does that work ?


Hans replied to the topic 'Full Automation and Weather handling in the Scheduler' in the forum. 9 months ago

sterne-jaeger wrote: ... I started testwise to develop a dedicated tab for the observatory.

Hey that's great that you started this ! Please tell me this lives in a branch in github somewhere :) (we can arc it to phabricator later :-P )

We need to add things like which dome/roof driver is in use, make a distinction between roll-off roof and dome with shutter, which safety system is in use and what its status is (I see weather is already there), enable or disable closing on bad weather, we need a flexible close order (like dome park first, then close cap, then close shutter). And a hysteresis setting, like if we closed down and things are safe again wait with opening for X time. Retries, how many ? Logic like if dome park fails do we still want to try to close the shutter or not ? Maybe even pre and post scripts or curl calls per action. And a wake-human alerting system, which may be just another script to be called so to defer the actual implementation to the user. Do we need to support multiple mounts in an observatory here too ?

-- Hans


Hans replied to the topic 'Full Automation and Weather handling in the Scheduler' in the forum. 9 months ago

With EKOS 3.2.2 closing up the observatory again on bad weather (live tested and verified last night, yay !) I'll adapt sentinel to handle the that the mount may already be parked etc. so that sentinel turns into a second defense line, an independent safety mechanism.
-- Hans


Hans replied to the topic 'Full Automation and Weather handling in the Scheduler' in the forum. 9 months ago

Hi Ferrante,

fenriques wrote: I'm adapting the script to my setup, 2 out of 4 of my devices work:
1) Roof is ok. Only updating the property was needed:
2) Weather is ok. Just used '_PARAMETERS' instead of '_STATION_INDEXES' :
And changed the variable names accordingly in the script.

Great !

3) Mount. I'm using 'LX200 10Micron' drivers. There's no PARK property there. Are you using the same driver?

I would hope so, I get this :
indi_getprop | sort -u | grep 10micron | grep PARK
What do you get ? Is your scope parked when you try this ? Or has the scope been parked with this instance of the INDI driver once ?

4) Camera. The property 'ZWO CCD ASI071MC Pro.CCD_COOLER.COOLER_ON' is not listed using getprop with ASI071. Anyway when I execute the script it returns true but the cooler is still On. The only other property related to cooler is 'ZWO CCD ASI071MC Pro.CCD_COOLER_POWER.CCD_COOLER_VALUE' but doesn't change the cooler power neither.

In the ZWO asi_ccd.cpp code we have
bool ASICCD::initProperties()

    IUFillSwitch(&CoolerS[0], "COOLER_ON", "ON", ISS_OFF);
    IUFillSwitch(&CoolerS[1], "COOLER_OFF", "OFF", ISS_ON);
    IUFillSwitchVector(&CoolerSP, CoolerS, 2, getDeviceName(), "CCD_COOLER", "Cooler", MAIN_CONTROL_TAB, IP_WO,
                       ISR_1OFMANY, 0, IPS_IDLE);

    IUFillNumber(&CoolerN[0], "CCD_COOLER_VALUE", "Cooling Power (%)", "%+06.2f", 0., 1., .2, 0.0);
    IUFillNumberVector(&CoolerNP, CoolerN, 1, getDeviceName(), "CCD_COOLER_POWER", "Cooling Power", MAIN_CONTROL_TAB,
                       IP_RO, 60, IPS_IDLE);
As you can see there the CCD_COOLER parameter is IP_WO, a write-only parameter. You get to see these with indi_getprop when you add -w
indi_getprop -w | sort -u | grep CCD_COOLER
And writing to CCD_COOLER_POWER is indeed not allowed as it's IP_RO , Read Only.
But writing to CCD_COOLER.COOLER_ON should work still. If it does not then that is a ZWO ASI and/or INDI driver bug. You can file a bug for that ;-)

5) Cap. Didn't test the cap.

Neither can I, I don't have a cap (yet).

-- Hans


Eric thanked Hans in topic Partitioning the Scheduler code 9 months ago

Hans replied to the topic 'Partitioning the Scheduler code' in the forum. 9 months ago

TallFurryMan wrote: Hans, do you agree to make your Ekos Sentinel a parallel project to what is done in that Observatory module?

Yes that was my intention. To follow any upcoming EKOS' observatory close down changes and keep it only as a failsafe system for the cases where EKOS does not close down while it should. (I consider this to be a different situation from an EKOS crash where the INDI watchdog driver can kick in.)

We would follow the same approach as the Ekos Internal Guider developed in parallel to Linguider and PHD2.
That means your project needs to formalize a notification interface, and that means Observatory needs to clearly separate its safety management to accept external services. That would be a benefit for both I think.

That sounds perfect. Where are the parts of the Linguider/PHD2 interfaces that EKOS uses described ?
Ekos Sentinel can now only command the scheduler to start or stop. It cannot ask what the scheduler is doing. The new observatory module should have an API where external programs can query these things, and it would be great if the observatory module could inform sentinel that it is going to do something, and that it expects to take X seconds at max. I propose I add a REST API interface to Sentinel for this.

-- Hans