- User Since
- Jul 16 2018, 6:19 AM (65 w, 2 d)
- Add the option to clear the sensor data history
- Bug fixing of the display when no weather or no dome is present
Sat, Oct 12
Great! now it works just fine. I think the only thing missing is a small clear button to reset all the data.
OK, update will come.
Fri, Oct 11
I also noticed another issue.. because there is warning, I see count-down.. however, there are no actions to take so why is there a count-down? it counts down to what?
That's not so easy to fix. Will be handled in a separate diff.
- Immediate replot sensor graph after rescaling axes
- Show graph value as tool tip, display optimization
Thu, Oct 10
also, I think instead of displaying the tooltip in the graph, it should be like the guide graph in the sense that it displays the reading value @ time. Then it's very useful to know the exact value at a particular time stamp.
Good point, I will do it.
Repainting the entire graph happens with a certain delay - I have to investigate this whether it is possible to accelerate it. And I think it makes sense having the 0-line always visible.
Wed, Oct 9
Here a screenshot of the new graphs:
Thu, Oct 3
... but it needs to rebased manually. @TallFurryMan: I slightly doubt that it is worth the effort...
Hm, indifferent. It does not seem like there is burning request for this feature. So never touch a running system?
Some code cleanup
Looks good, I update the commented parts and re-submit the diff.
Mon, Sep 30
With "receive external guide frames" selected:
- pushing the "Capture" button in the Guide module creates an assertion failure in PHD2::captureSingleFrame().
- pushing the "Loop" button shows the warning "PHD2 Error: could not start looping", but PHD2 starts looping.
Sat, Sep 28
We don't really want to be disabling cameras that are connected to Ekos unless they are actually being used in PHD2 as a guide camera I would think? The images are received and displayed in fits viewer because PHD2 hasn't said that that is the guide camera yet.
Personally, I do not like it when the FITS viewer pops up with the image from the guiding camera - no matter in what state Ekos and PHD2 are. I am not fully aware of all the consequences what happens if it is turned off.
Changing to contains method
Fine, that solved the problem. I am using the latest PHD2 version 2.6.6dev2. Maybe they changed something.
Fri, Sep 27
Great, thanks! But I now do not understand why this happens:
2019-09-28T01:24:39 PHD2's current camera: INDI Camera [Guide Simulator], is NOT connected to Ekos. It does not need to be connected, the PHD2 Guide Star Image should still be received.
This message always comes when I press "Connect" in the EKOS guiding module.
One behavior that seems to be new: if PHD2 is not connected to EKOS and PHD2 is looping, the images of the guiding camera are displayed in the FITS viewer. Is there a reason behind or is it simply a bug?
Looks good! There is one warning that seems to have a problem:
PHD2's current camera: Simulator(I18N_ARGUMENT_MISSING), is NOT connected to Ekos. It does not need to be connected, the PHD2 Guide Star Image should still be received.
Thu, Sep 26
I do not think it is super necessary. A user who is using KStars for astrophotography normally does not play around with the simulation clock. A message in the log should be a good compromise.
Wed, Sep 25
Please check D24232, this should hopefully fix the regressions we discussed here.
... hopefully the last i18n
... and now also in the dome model.
i18n arguments corrected (now hopefully complete)
Tue, Sep 24
i18n message arguments corrected
i18n message for observatory handling corrected
Mon, Sep 23
OK, I found the problem with hitting a constraint. In this case the Scheduler calls stop() which sets the job to ABORTED. That's explains the behaviour.
Sat, Sep 21
[2019-09-20T04:54:00.721 EEST INFO ][ org.kde.kstars.ekos.scheduler] - "Job 'NGC1491' is now approaching astronomical twilight rise limit at pe syysk. 20 04:54:00 2019 (0 minutes safety margin), marking aborted."
Looks like at least the log warning is wrong. Assuming that @jpaana has the latest version, that's strange.
So we try to set jobs to COMPLETED based on frame count, we make sure we do not touch the frame count except when receiving a frame or recounting storage frames, and we do that state change when starting evaluation only? In other words, we never complete jobs during execution? The problem with states is that we must not jitter between values needlessly. Do you have a state diagram in head?
Let me give a try defining COMPLETED for a sequence job seq_j:
Fri, Sep 20
I agree. It is a regression from this diff, isn't it?
Well, some kind of. Before my diff, these where set to "aborted", which was also wrong from my perspective.
Hm, quite complicated. Has this ever worked? Nevertheless, I think when running multi-day-schedules, I would use "Remember job progress". In that case I think this situation would not happen.
Thu, Sep 19
Second regression observed minutes ago: when restarting after sleeping, all jobs are re-scheduled, even completed ones. I need to remove the jobs that were completed last night manually, or use Remember job progress.
Good idea, far better!
Wed, Sep 18
OK, understood. But why did it happen that no frame has been captured? Was it due to the case that as soon as it would have been there turn to be started, they already hit their altitude or twilight limit, right?
When job #12 crossed the altitude restriction at 15° while focusing, it was incorrectly set to completed instead of aborted (KO).
When job #13 crossed the altitude restriction at 14.3° before starting, it was incorrectly set to completed instead of aborted (KO).
That's how it was intended from my side (see our discussion here).
I think I got your point now with the multi-day-schedules. As soon as a job is marked with JOB_COMPLETE, it will not be started the next night when the scheduler keeps running for more than one night.
Sep 15 2019
Awesome job, Eric!
Sep 11 2019
Very nice idea, Eric - well done!
Sep 9 2019
Sep 5 2019
Aaaah, sorry, I misinterpreted one thing. You're absolutely right, 60sec for aligning makes sense, since it is more than one single astrometry run.
Good idea, Alex. And welcome to the Scheduler-Optimizing-Club :-)
Sep 3 2019
Thanks, understood. But where does the M102 entry for N5457 come from? In the OpenNGC catalog it's only mentioned in the comment. Same for N5866, by the way.
Sep 2 2019
@cdersch: when I understand OpenNGC right, then they do not contain any Messier names. Where do they come from?
Did Christian answer? I learned meanwhile that it is historically not clear, whether NGC5866 is really the M102 from Messier's catalog.
Sep 1 2019
Aug 31 2019
Aug 27 2019
I‘ve been using it now since several weeks and really appreciate the „restart immediately“ function. I typically have 2-3 different targets per night and it is very handy restarting the aborted job after a cloud e.g passed by. In the past few weeks I had several partially cloudy nights and all worked well.
Aug 19 2019
Aug 7 2019
Proposed code cosmetics added
Jasem, many thanks for the corrections, I wasn't aware of rangeHA. A small hint: is there a reason why you left the old code commented out in the code instead of simply deleting it?
Aug 5 2019
Jul 28 2019
Jul 23 2019
Jul 22 2019
Select "Sub Frame" and "Auto Select Star". Set "Box Size" to a small value, e.g. 128. Then start "Autofocus". Without this fix, the green box should be in the top left corner of the full frame image. With the fix, it is around the focus star.
Jul 21 2019
Re-focusing before capturing reworked, focusing states removed from calibration stages
Jul 20 2019
Jul 17 2019
Sorry, the description is misleading, the focus check is added to startNextExposure(). This is exactly the same place where I added the meridian flip check, where we had the same problem.
Update to the discussion regarding aborted jobs and limits.
Jul 14 2019
Serialization changed as suggested, log messages corrected. Now we need to agree how to proceed with the problem, that restarting aborted jobs immediately conflicts with the idea of having multi-day schedules.
Serializing error strategy corrected, log messages for aborted jobs unified
We need to decide whether we want the scheduler to be able handling multi-day schedules (as currently, without this change) or being able to restart immediately aborted jobs. The latter is important for a robust scheduling during nights with some clouds, where a job gets aborted, but may be continue, as soon as the cloud has passed by.
Many thanks for your comments. I will think about them and come back.
Jul 13 2019
Works as described, good point!
Jul 10 2019
Makes sense, good point!
Jul 2 2019
Hope it's like you meant.
- canRelativeMove added as D-Bus property
- String formatting improved
Jun 23 2019
Jun 19 2019
Jun 18 2019
Jun 11 2019
I am primarily working with PHD2. I've tested #1 also with the internal guider, it showed the same problem as PHD2 and should be fixed. #2 is PHD2 specific and #3 should work with all guiders.
Jun 10 2019
Jun 3 2019
no problem, I not made out of sugar :-)
Indeed, I think this feature makes sense - exactly as you described it. Pausing - for example arranging cabling or testing a better guiding setup - makes sense. My typical setup is shooting LLLRGB sequences. When I have the ability to pause in order to fix something and capturing continues exactly the place where I paused, this would be nice to have (but maybe not more).
Many thanks, so let's start the feature branch. As a next step I would like to discuss with you the interaction of Observatory and Scheduler.
Eric, please be so kind and test the pause button on the current master without this diff. There you will see that after pressing the button a) the Scheduler waits for a capture sequence to complete and b) when you press the "Start/Resume" button after the sequence completion, nothing happens.
Jun 2 2019
I guess you do not mean the bug fix part. For this the use case is very simple: "I want it working :-)"
May 29 2019
Checkboxes for weather status actions implemented
Ready-button deactivated, showing only the status
Switched to branch observatory_work
May 26 2019
From my perspective, we could start now with the feature branch. Currently, the Observatory is standalone. As a next step, I would like to implement the interaction with the Scheduler, but this should be handled in a separate diff.
Make observatory ready with one mouse click
May 25 2019
Observatory status added
May 24 2019
- Shutter actions invisible if no shutter present
- Measurement of delay in secs
- Scheduler actions prepared, but left invisible
May 22 2019
Action check box for stopping the scheduler added (not implemented)