Guiding sequence out of order

[donboy]

Hi Robin,

In the last two versions the goto catalog sequence has guiding coming on way too early before finishing the plate solve function and window PHD2 shows that is on pause. This happens most of the time but sometimes it works as it should.

While I'm on the subject the normal command to start imaging happens to soon before the PHD2 starts guiding, which ends up causing the first image to have star trails. Now this could be associated with my mount and the iOptron Commander. This has been going on for a long time and I just never bothered to say anything, I just manually cause the camera to restart the image before stacking is started.

Regards,

Don

[admin]

Hi Don,

an odd one to have changed recently, since I have not altered the way that the Goto Catalog Target/Co-ordinates tool implements things since early December.

If you look in the log after using this tool then it records the sequencer code that the tool has generated to do the things that it has been asked to do (it all happens via the SharpCap sequencer). I just tested and I got this code recorded

Code: Select all

SEQUENCE
    GUIDING CONNECT ABORT False
    GUIDING STOP
    SET PLATESOLVE/FOCUS SETTINGS EXPOSURE 4
        MOUNT TRACKING Sidereal
        TARGETNAME "M76 (NGC 650,Little Dumbell,Cork,Butterfly Nebula)"
        MOUNT SET TARGET TO RA=01:42:18.0,Dec=+51:34:00
        MOUNT GOTO RA=01:42:18.0,Dec=+51:34:00
        WAIT FOR FRAME
        MOUNT SOLVESYNCONLY
        MOUNT GOTO RA=01:42:18.0,Dec=+51:34:00
    END SET
    GUIDING START
    GUIDING DISCONNECT
END SEQUENCE             

Here you can see that the guiding restart is definitly after the plate solve (MOUNT SOLVESYNCONLY) and re-goto.

If you are running a custom sequence rather than using the Goto tool then you would need to check the ordering in the custom sequence.

On the subject of the guiding smearing the first frame, maybe, looking at the above, the guiding start should be *inside* the reduced exposure block to ensure that the guiding is running before going back to the full length frames - perhaps that could be a factor in a smeared first frame?

cheers,

Robin

[PeterAB]

Hi Robin,

I'm jumping on this thread, rather than starting a new on. I observed the same issue last night with a new install of SharpCapInstall-4.1.13229.0-64bit updated from SharpCapInstall-4.1.13131.0-64bit. Phd2 is version phd2-2.6.13-installer and has not been updated recently.

Phd2 tries to start guiding during the "waiting for mount to settle" well before the last plate solve and resync. Phd2 fails to resume guiding because of the resync.

I have not experienced the issue of Phd2 starting at the correct time in the sequence, but failing as posted above.

A quick look at my log shows the correct sequence as you posted above. My full log is too big to upload. I moved it to google drive here: https://drive.google.com/file/d/1BQToML ... sp=sharing

Related to another bug report is that there was a case of a hang during the "waiting for the mount to settle" last night. This happens infrequently. I just cancel the sequence and restart. The sequence has always completed on the second try. This should be in the log file.

Thanks again for all your help,

Peter

[admin]

Hi Peter,

ah, thanks, that log was exactly what I needed. What's happening is that the mount movements also try to stop/restart guiding independently of the sequence (which is good in some circumstances, but not here). What I need to do is keep count of how many things have disabled guiding and only restart it once the count gets back to zero. I will look into how to do that.

On the getting stuck waiting for the mount to settle, it looks like SharpCap was waiting for PHD2 to do the resumption of guiding - SharpCap has asked for guiding to resume but the updates coming from PHD2 are alternating between 'Lock Position Set' and 'Looping', so the guiding state is not being entered. I think we will see if this goes away once we get the guiding to resume at the right point in time rather than dig into it further now.

cheers,

Robin

[donboy]

Info 225356.695121 #1 Starting.txt

(978.64 KiB) Downloaded 35 times

[admin]

Hi,

thanks Don, same symptoms as in Peter's log, which is good to confirm. I tracked the issue down to a timing problem - when SharpCap asks PHD2 to stop guiding at the 'GUIDING STOP' step, it just sent the stop message to PHD2 and didn't wait for confirmation. The sequence would then run on quickly through the next steps like setting the target name and get to the move while PHD2 was still digesting/processing the stop request. So, at that point SharpCap would still be reporting 'guiding' as the PHD2 state, so the pause guiding inside the mount move would decide it needed to take action (incorrectly).

I have this fixed now ready for the next update.

cheers,

Robin

[PeterAB]

Hello Robin,

One note and a tangential issue.

The note is that Phd2 has a "stop guiding when mount moves" check box in the settings. Changing this setting did not effect the issue in this thread. I'm thinking it could cause problems in some timing situations. Best for me would be to leave this Phd2 option off and allow SharpCap to turn guiding on and off when it moves the mount.

The tangential issue is that the "goto target" sequence will stop if the ask Phd2 to pause guiding option check box is selected and Phd2 is not running or not guiding. I would call this a characteristic rather than a bug. However, I would rather see a notification, but, have the sequence carry on. I would not attempt to turn guiding on if it was off at the start of the sequence.

Thanks again, Peter

[admin]

Hi Peter,

yes, the option in PHD wouldn't take effect in this case I think, since SharpCap would have turned guiding off before the mount starts moving, so the criteria for the PHD option to activate wouldn't happen.

I see what you are saying about the way things work when PHD2 is not running - it's not easy to fix that within the generated sequence for the GOTO movement as I (deliberately) don't have any real way to conditionally do things in the sequencer in SharpCap. That means that a fix would have to come at the point where the window displays to the user - perhaps try to connect to PHD2 at that point and see if it is guiding before displaying or enabling the PHD2 check box. I'm not 100% keen on that approach either, as it would make SharpCap connect to PHD2 without the user requesting it, and I'm not sure if there are circumstances where that might be a problem. I think I will leave that one for now until I come up with some other way to solve it.

cheers,

Robin

[PeterAB]

Hi Robin,

Okay, I can understand not having conditions in the sequence. I'll just remember to uncheck the box when needed and if I don't it is not a big deal to rerun the sequence. Sometime my first goto target/coordinate of the night happens before I have Phd2 running. This would be the only time I need to remember to uncheck the box.

Thanks, Peter

[ScopesNC]

OK now thats out of the way on to more and bigger buggies. Ran the newest update version 4.1.13268.0-64 last night while streaming on Night Skies Network.
Not one mistep on my goto's last night. Guider went off and on in order. So that one is fixed.

The most importan issue to me was the hang up and fail on the gotos it would do about once every other time you'd go to an object That too seems fixed.Didn't happen one time on about a dozen gotos I ran over the night. Pleasent surprise on that one.

Good fix Robin and thanks.