×

INDI Library v2.0.6 is Released (02 Feb 2024)

Bi-monthly release with minor bug fixes and improvements

Issues with loading and starting a schedule via dbus script on ekos 3.5.5 and 3.5.7b

  • Posts: 7
  • Thank you received: 1
A couple of weeks ago, I updated the Astroberry to kstars/ekos 3.5.5 I found a little issue where a schedule won't run if ekos is started and the schedule loaded via a dbus command via python for some automated management I've been working on.

Previously on 3.5.3, the sequence was load ekos, load schedule, run schedule and then it connects devices and off it goes.

However in testing 3.5.5 (not tested on 3.5.4) some issues have crept in where sometimes it will not read the equipment profile from the schedule and won't load the profile unless that is injected over dbus via setProfile(), sometimes it loads the sequence in an inconsistent state which requires triggering of resetAllJobs() to force the scheduler to load the capture sequence and the target co-ordinates. Finally when triggering the start command the schedule is holding at idle with "no job running" until manually pausing/stopping and then restarting the scheduler via the ekos scheduler interface.

On the spare Astroberry, I built 3.5.7b from source to test if it was a one off, but the issues still present, and still end with the same result where it sits spinning the wheel with no job running.
2 years 3 months ago #78630

Please Log in or Create an account to join the conversation.

Hello Sean and welcome to INDI forums!

Please write step-by-step how to recreate this issue.
2 years 3 months ago #78638

Please Log in or Create an account to join the conversation.

  • Posts: 7
  • Thank you received: 1
Hi Jaseem, thanks for the welcome!

It'll be later on today when I get around to it as I'm just on the way to work, and I'll attach the python script that's used for the initiator, command line call, etc.

In the mean time here's the logging output from the scheduler module if it's useful I made yesterday evening from both 3.5.3 and 3.5.5, generated by simulators but it's the same behaviour as the physical hardware attached. The 3.5.3 is up to the point where the simulator is generating the first frame, but 3.5.5. doesn't log any further than where the last line of the log is generated without manual intervention. 
2 years 3 months ago #78639
Attachments:

Please Log in or Create an account to join the conversation.

  • Posts: 7
  • Thank you received: 1
Right, back from work and here's the rest of it.

The script, ekos_controller.py was put together by another member here, I can't remember who off the top of my head but it was another thread about dbus from quite a while back; I've gone through it, found no noticeable errors in it, rebuilt it a couple of times to make sure and matched it up to the scriptable functions in scheduler.cpp

On the machine, the configuration is a Pi4B 8GB, with the indiserver set to remote though on the same machine to maintain the current settings should kstars go down, the profiles in ekos are set to auto-connect.

The sequence which worked on 3.5.3, was from the terminal (or ssh, or shell script); examples assume relative to desktop.
The CurrentSequence.esl is just a copy of whatever the sequence I am working on at that time.
cd ~/Desktop;
./ekos_controller.py --start_ekos;
./ekos_controller.py --load_schedule ./CurrentSequence.esl;
./ekos_controller.py --start_scheduler;

However on 3.5.5 (and 3.5.7b) using the same python script, the process is :
cd ~/Desktop;
./ekos_controller.py --start_ekos;
./ekos_controller.py --profile 'Default';//Or other server profile name, sometimes fails to connect to the indi control panel
./ekos_controller.py --load_schedule ./CurrentSequence.esl;//Usually will not load correctly, marking as invalid, omitting co-ordinates, job status and .esq sequence count
./ekos_controller.py --stop_scheduler;//To mark the job aborted instead of invalid and allowing to reset
./ekos_controller.py --reset_scheduler;//Here resetting the the schedule sequence to correctly load co-ordinates and .esq file
./ekos_controller.py --start_scheduler;//Restarting the scheduler

This, however, only goes so far to start the scheduler, but when the schedule is started in this manner even with a valid job in the queue, it doesn't select the job and start.

Starting and running a sequence by direct input doesn't cause the same issue to appear. 

File Attachment:

File Name: ekos_contr...r.py.zip
File Size:2 KB
The following user(s) said Thank You: Jasem Mutlaq
2 years 3 months ago #78647
Attachments:

Please Log in or Create an account to join the conversation.

I found the issue and it's fixed in GIT now. Please try again.
The following user(s) said Thank You: Sean Needham
2 years 3 months ago #78671

Please Log in or Create an account to join the conversation.

  • Posts: 7
  • Thank you received: 1
Thanks Jasem!
I built from git on version 3.5.7b tested with the simulation profiles and the different ways I can think if to arrive to sequence start, and each time it is equal to the behaviour on 3.5.3 and without issue or workflow modification to force anything to happen. I'll throw some more tests at it over the coming days, but I'm not seeing anything different from previous (3.5.3) on it at the moment.
Thanks for the time looking in to this one and thank you for implementing the fix!
2 years 3 months ago #78680

Please Log in or Create an account to join the conversation.

  • Posts: 7
  • Thank you received: 1
Hello again.

I've been doing a bit more testing with the 3.5.7b with the changes to the scheduler.cpp that were pushed to the repo, and found some more problems; I'm not sure if it is a continuation of the same issue or it's another that was hidden by the previous one.

With testing further via the interface, I've found that the scheduler is now causing problems and hanging at the "No Job Running" state when starting the tasks locally via the scheduler interface within Ekos; it's appearing to fall over in exactly the same way as the dbus interface was previous but stopping and force reloading the schedule or toggling pause does not bring the queue to life.  I've been through and checked it with viable targets and with all the overrides turned off (altitude, twilight, etc) a few times just to make sure that it wasn't something I'd overlooked.

I've attached scheduler the log from the last test I ran with it as it's a carbon copy of the others.
2 years 3 months ago #78708
Attachments:

Please Log in or Create an account to join the conversation.

  • Posts: 7
  • Thank you received: 1
Saw the 3.5.7b build that was pushed on to gitlab earlier, built it and testing it now; initial tests show that interacting both directly and indirectly over dbus both seem to be functioning and nothing untoward has popped up in use or the logs.

I'll keep throwing some tests at it, just to check and hopefully towards the end of next week get chance to test it on real equipment in a real world situation; if anything pops up I'll keep you informed.
2 years 3 months ago #78755

Please Log in or Create an account to join the conversation.

  • Posts: 41
  • Thank you received: 2
Hello,

2 year after this discussion I tried to start and stop the scheduler with the ekos_controller.py script still without success as Sean ( The scheduler is starting but there is no progress on the job ). Is there still no progress on this topics ?

Best regards.
JC
2 months 3 weeks ago #97964

Please Log in or Create an account to join the conversation.

  • Posts: 41
  • Thank you received: 2
Hi,

Juste to inform that with with KStar 3.6.0, this working much better !

Wishing you nights cloudless...

JC
2 months 12 hours ago #98503

Please Log in or Create an account to join the conversation.

Moderators: Radek Kaczorek
Time to create page: 0.803 seconds