Welcome, Guest
Username: Password: Remember me
25 Jul 2018
Glad to announce of release of INDI Library v1.7.4 on 2018-07-25. A few drivers were added in this release as we continue to improve & stabilize existing drivers.
Read More...
  • Page:
  • 1
  • 2

TOPIC: Scheduler - Unexpected behavior since 2.9.7 update

Re:Scheduler - Unexpected behavior since 2.9.7 update 2 months 1 week ago #28181

Workaround for this is to disable "Remember Job Progress" until a fix is pushed.

From what I understand in the log, when the Scheduler finishes guiding calibration and triggers the Capture module, the Capture module is informed that there is 1 capture for Ha in storage. Then it proceeds to capture one frame. Image arrives, sequence count is incremented. In the log, each time there is a "NFocus Elapsed Time", one frame was captured. I count 13 captures between 22:30 and 23:05.

That's where the system goes wrong is: a dithering process starts at 23:05 at the guider level. This goes on until 23:05:58 at which the sequence is resumed. Something is taking place until 23:06:15, (delay based on guidingRate()?), that causes the sequence to be prepared again. Because of this, the current capture sequence count is reset to the initial value provided by the Scheduler, and the whole sequence restarts.

This is clearly not a regression from D14357, but is probably an integration problem with the dithering process.

I believe that this can be fixed very simply by properly incrementing capturedFramesMap each time a capture arrives. This should be done at capture.cpp:1219.

Still, the other issue that bugs me is the lack of logs from the Capture module. There should obviously be more of them. Perhaps the Guide module is owning all the bandwidth, I don't know.

-Eric
The following user(s) said Thank You: knro, Herrhausen, El Corazon

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

Re:Scheduler - Unexpected behavior since 2.9.7 update 2 months 1 week ago #28183

Thanks Eric! I did have "remember job progress" enabled. Will turn off next.
Tonight I had a different problem, though. The capture module did progress from Sii to L to R to G, but then it got stuck on the green filter after exposure 3 and went into Groundhog Day mode. It never recovered. The bad news about that is that as a result the capture module never commanded a meridian flip either and I found the telescope this morning wrapped around the mount.... in a figure of speaking. I don't think there is any damage, but I did panic for a moment.

Here the log of last nights run. That problem may be different from the previous night.

www.dropbox.com/sh/l3ezqk2vjfgjcuk/AACrd...siIujseiONzqlSa?dl=0

The only significant change I made was switch the USB3 cable from the camera and filter wheel from the powered USB hub directly to a USB port on my Zotac mini PC and I plugged in the mount cable into the powered hub. On the off chance that there was a communication problem through the hub that prevented the capture module from progressing.

Thanks for continuing to look into that puzzle.

Jo

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

Last Edit: by El Corazon.

Re:Scheduler - Unexpected behavior since 2.9.7 update 2 months 1 week ago #28185

We really need github.com/indilib/indi/pull/612 finished and merged in :/

Besides, Scheduler is missing a safeguard timer for all step procedures. This is being implemented on my side.

Of course, this is not a reason not to look for the exact issue that caused the problem...

-Eric
The following user(s) said Thank You: El Corazon

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

Re:Scheduler - Unexpected behavior since 2.9.7 update 2 months 1 week ago #28212

TallFurryMan wrote: Workaround for this is to disable "Remember Job Progress" until a fix is pushed.

From what I understand in the log, when the Scheduler finishes guiding calibration and triggers the Capture module, the Capture module is informed that there is 1 capture for Ha in storage. Then it proceeds to capture one frame. Image arrives, sequence count is incremented. In the log, each time there is a "NFocus Elapsed Time", one frame was captured. I count 13 captures between 22:30 and 23:05.

That's where the system goes wrong is: a dithering process starts at 23:05 at the guider level. This goes on until 23:05:58 at which the sequence is resumed. Something is taking place until 23:06:15, (delay based on guidingRate()?), that causes the sequence to be prepared again. Because of this, the current capture sequence count is reset to the initial value provided by the Scheduler, and the whole sequence restarts.

This is clearly not a regression from D14357, but is probably an integration problem with the dithering process.

I believe that this can be fixed very simply by properly incrementing capturedFramesMap each time a capture arrives. This should be done at capture.cpp:1219.

Still, the other issue that bugs me is the lack of logs from the Capture module. There should obviously be more of them. Perhaps the Guide module is owning all the bandwidth, I don't know.

-Eric



I disabled "Remember job progress" last night and had absolutely no issues. Scheduler, Capture and Guiding Modules ran perfectly. Meridian flip executed unattended and no problems. If this is all there was to it, I can easily live with it.

Here the logs, esq and esl files in case they are helpful for you, Eric.

www.dropbox.com/sh/e95wanc3s12t0jg/AAB6q...27IPeH7qZWHBJLa?dl=0

Here the result of last nights imaging session. I did nothing for it except program the scheduler and hit run. The rest was all executed without a hitch.

Attachments:
The following user(s) said Thank You: knro, TallFurryMan, tkottary

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

Re:Scheduler - Unexpected behavior since 2.9.7 update 2 months 1 week ago #28220

Thanks for this report! Nice Veil, narrowband really stands out for these nebulae!

We discussed the issue quite extensively with Jasem, I will look into this more deeply very soon. We started adding feature-specific test vectors, but some issues occur at a slightly larger integration level.

-Eric
The following user(s) said Thank You: El Corazon

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

Re:Scheduler - Unexpected behavior since 2.9.7 update 2 months 1 week ago #28281

Hello Guys!

I read this thread with interest, and thought, maybe my problem fits here...
After fullmoon phase and lots of heavy thunderstorms, yesterday was a night to get my setup out for a night. I wanted to try how guiding with guiding cam and KStars is working. So far i was satisfied with the results at first. So i set up the system to capture 50 lights with 5 minutes exposure time, guiding and dithering. I kept checking the system for the first 5 pictures and all seemed to work well.
So i went to bed and set the alarm clock to 0400.
Then i saw, that the system stopped making pictures after the 12th picture.
When trying to find out why that is so, the only thing that was "wrong" was the work, the guiding module made.
Too bad i did only check the ccd in the log so there is nothing of interrest there...
So what happened ist at first, the "info box" of the guiding module did like PICTURE DONE - DITHERING - DITHERING COMPLETE - PICTURE and so on.
At one point, it did no dithering anymore, and so there came no TAKE PICTURE command anymore.
so it seems that the module taking photos was just waiting for the guiding module to dither, which not happened anymore...
There is also no error message at all.
I have to say additionally, that there were some situations where the guide star was lost and found again, what worked quite well
Now, it was no drama this night, because of different problems anyway. (guiding not working as good as with the mgen, lines instead of points in all four corners...)

I thought OK, lets use the last dark hour for darks, so i first took some flats, and the set up for the darks.
AND THERE A OLD WELL KNOWN PROBLEM OCCURED!

When i took the first darkframe i waited, to see if it works allright and when the picture came in, it was NO DARK!
It was the picture that was taken BEFORE, the last Flatframe.
I thought that this problem, where the system 'forgets" to count pictures taken with the cam, was fixed allready?

So the question is, can that have something to do with the system stopping taking pictures?

Or is the fault somewhere else?

Attached the log though it will not help much.

And a burning question for a Linux-Noob: I did not update for a while, so i am on 2.9.4 still...
What was there to do to get the update?
Only the "sudo get update"?

I am a bit careful with updating now, since the last time i updatet, the whole system was not working well anymore...

Thanks for your kind help
cheers Niki
Attachments:

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

Skywatcher EQ6-R | Lacerta 10" Carbon-Newton | Skywatcher 6" Newton | Canon EOS 5DIIIa | MGenII via Off-Axis-Guider |

Re:Scheduler - Unexpected behavior since 2.9.7 update 2 months 1 week ago #28292

For the first problem, the dithering procedure hanging captures, we're working on a fix.

-Eric
The following user(s) said Thank You: the.cakemaker

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

Re:RE: Re:Scheduler - Unexpected behavior since 2.9.7 update 2 months 1 week ago #28294

the.cakemaker wrote: guiding not working as good as with the mgen, lines instead of points in all four corners...


This is interesting. Is that field rotation present for all your targets when not using the MGen? Do you know the root cause already? Better calibration on the MGen? Offset guider axis?

-Eric
The following user(s) said Thank You: the.cakemaker

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

Re:Scheduler - Unexpected behavior since 2.9.7 update 2 months 1 week ago #28298

TallFurryMan wrote:

the.cakemaker wrote: guiding not working as good as with the mgen, lines instead of points in all four corners...


This is interesting. Is that field rotation present for all your targets when not using the MGen? Do you know the root cause already? Better calibration on the MGen? Offset guider axis?

-Eric


I am not sure what the problem is. I mean, i AM sure that the problem is me. Its just that i do not really know, what all the variables in the guiding module are good for, since i tried it the first time yesterday.

Also i am not able to interpret the guiding graph.
I was happy, that it worked on the first try, and that for, i am very satisfied.

Maybe it has to do with to bad focus on the guidingscope, focusdrift on the guiding scope, the high clouds/moist air, and so on.

For the mgen i have to say that i use it with off axis guiding, and its own cam. Seems that this complete package is just working great.

Thats why i desperately wait for mgen support as guiding system for kstars :-)

Cheers Niki




Gesendet von iPhone mit Tapatalk
The following user(s) said Thank You: TallFurryMan

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

Skywatcher EQ6-R | Lacerta 10" Carbon-Newton | Skywatcher 6" Newton | Canon EOS 5DIIIa | MGenII via Off-Axis-Guider |
  • Page:
  • 1
  • 2
Time to create page: 0.387 seconds

Login



3rd Party

Choose from the numerous 3rd party INDI drivers to suit your needs!

Got Problem?

Check out the FAQ, the forum, and the bug tracking system to resolve any issues you might have!
You can also subscribe to INDI newsletter and development mailing lists to get the latest updates on INDI!


Gallery

Replica

Why INDI

Replica