×

INDI Library v2.0.7 is Released (01 Apr 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 5 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 5 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 5 months ago #78639
Attachments:

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

  • Posts: 7
  • Thank you received: 1

Rendering Error in layout Message/Item: array_keys(): Argument #1 ($array) must be of type array, null given. Please enable debug mode for more information.

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 5 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 5 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 5 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 5 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
4 months 2 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
3 months 3 weeks ago #98503

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

Moderators: Radek Kaczorek
Time to create page: 0.682 seconds