SLAVING - stops/sleeps with new dome firmware

hmmm It still loses slave… - works a while then seems SGP stops selling the dome to update?
Dome stops updating and mount keeps tracking. Only thing that wakes it up is to send a manual bump to the dome to move it left or right 1 step. Then it re-aligns and continues tracking until… it fails again.

I’ll upload todays test logs. It tracked fine until about 4:50pm.
at 16:50:42 it stopped slaving.

sg_logfile_20180511120202.zip (40.0 KB)

So this is just the scope and dome with the dome slaved but not running a sequence right?

I see it checking if adjustments are needed with two slew commands going to the dome with the last at 18:01.

After the second slew I see no more checks for adjustment and you disconnecting about 2.5 hours later. Am I right in assuming that you simply set this up then left it alone the whole time?

If so then the question is should SGP coordinate scope and dome at all when there’s no sequence in play? Perhaps the coordination is an oversight and it shouldn’t be moving anything without a sequence and it just kind of randomly figures this out after a while and quits?

Only the SGP authors can answer that.

Yes, anytime the “slaved” checkbox is set the dome is slaved to the mount.

It looks like the dome disconnected from that log. I wonder if maybe the PC is going to sleep or the USB port is? Or something else? I’m testing this locally with the simulators to see if I can duplicate.

Thanks,
Jared

There’s no disconnect between the driver and controller. It manually disconnected I record that and it ungracefully disconnected I throw exceptions.

There is a disconnect in the SGP log. I’m not sure what caused it or if it was manually done. I don’t believe the corresponding log from the driver is there so it’s not possible to see if there was an exception in the driver that caused the disconnect or if it was disconnected through the UI.

Thanks,
Jared

And there’s an example of the difference between a real programmer and an “enthusiast”. I turned off all that power saving stuff years ago due to problems with things going to sleep and since it hasn’t bit me lately the possibility never entered my mind.

no, on PC sleep -I do no power saving. All performance settings. I don’t know why port would? Mount keeps tracking. To wake up the dome I have to manually bump < or > 1 degree (sending it a signal) wakes it up and moves it. Then about 6-8 seconds later it realigns with the scope position.

It acts like it’s sleeping. Is there a way to check the port, or fire a command at the port to make sure it’s active? Never had this with the old firmware, and another guy has the same issue. Nothing else on the PC sleeps - everything continues to function as does SGP.
This it the last NASTY bug to try and track down.

Does the driver output a log? Attaching that would also help.

How long from powering up the dome to seeing this behavior is it? Or does it seem random?

Thanks,
Jared

Here are the other logs driver added to the zip.

sg_logfile_20180511120202.zip (342.9 KB)

Those ASCOM.PDM... logs seem like the right ones but they also seem pretty light on data. Maybe @pmeloy can help track down the dome logs? Or maybe the driver can be put into a more verbose mode?

Thanks,
Jared

Wrong log. That was just connect then disconnect. The SGP low showed two slews.

err, low = log

Well I’ve been running the ASCOM Telescope simulator and my dome through SGP 3.0.2.82 for four hours now resulting in 36 slews and no errors. I’ll leave it running all night and see what happens.

Still going 14 hours later. I’ve done this several times but not more than 4 hours and still haven’t had the coordination stop working.

what change did you make - mine’s been going over 4 hours all good too.

None, Fixed a problem with calibration but there wasn’t anything else done.

Edit: I just packed it in at 22 hours. Want to do something else with the computer.

5.1.0 shutter compatible with 5.1.1 ascom driver and rotator? I get
exception errors.