Guiding timing out before scope settles. (Scope prematurely shows slew completion)

[Don Elledge]

Hello

I have a CDK600 on a L600 Mount. I have a Diffraction limited Star Chaser with a QHY461 camera. I have been having problems with elongated stars and it has taken a little while for me to figure out the problem.

The scope when we Dither the scope between images, it takes a little while for the scope to settle down, and the guider takes images very quickly, so like 50 a second. The problem I am having is that the scope is not settling very quickly and ACP only lets the AOX take about 50 images (1-2 seconds time) before it fails the plan due to "Excessive Guiding Errrors"

I was wondering if there was a way to change this setting on number of attempts before erroring out or if I can make a minor change in the code to increase the number. I can set the threshold higher for errors but the scope does take time to settle and I am taking short images which does make the stars oblong.

thank you don.

[Don Elledge]

I'm on 8.3 of acp.

[Colin Haig]

Don, I was looking at your other thread on the MaxIm forum, and am a bit confused by "50 a second" - if this is guiding, MaxIm can't image that fast; if it's AO operation, 10Hz to 20Hz is the physical limit of the fastest AO units in the SBIG family.
Was that a typo?

[Bob Denny]

Don -- I need a log file from ACP showing this. I think I understand but I want to be certain. The ACP logs (time-stamped journals of the console output) are located in

Documents\ACP Astronomy\Logs\yyyymmdd\yyyymmdd@hhmmss.log

Please attach a few showing this issue.

[John Downing]

I was just about to post a related message. I too have a CDK24 and L-600 (equatorial mount). Mine is at SRO. Here is the my related problem: The L-600 mount can take as long as 60 seconds (or even a bit more) to settle to +/- 0.1 arc seconds of jitter from any slew. There is a lot of mass to move - and that mount moves very quickly. I've attached a few screen shots showing sample settle oscillations immediately following a slew. I took a look for the ACP log and cannot find it - is there a possibility that logging is disabled on my system? The Scheduler logs were there and OK. I can post those if needed. After given a few minutes to settle the L-600 is absolutely superb with tracking error measured of a few arc seconds over hours of imaging. I have a guider on the CDK24 but have found absolutely no need to use it. In fact, I believe for the L-600 it makes problems worse by constantly jogging the mount. The mount, if installed correctly, should have an RMS pointing error of less than 7 arc seconds and a tracking error of much less. I have tracked slews of 1 arc minute and found the settle time is not much different than a slew of 30 degrees.

At the start of every image run (for astro-imaging all of my images use 600 second exposures) the mount would first autofocus using PWI 4 then slew to the target where it would capture a 15 second image, plate solve, then adjust the mount to what the plate solve told it was the image center. My first image in a run always showed streaks and was unusable. At first I thought this was temp related - wrong - then truss flex related - also wrong - then mount tuning - also wrong - the Planewave tech did log in and make some small adjustments to the "extended" mount tuning results.

After examination of the autofocus logs from PWI3 and looking at image time stamps it became obvious the streaks appeared after every slew - and only after every slew. Over the last few nights I've run a few tests while looking at the settle time (tracking graph in PWI4) and the time an image capture starts. For the initial plate solve image - that capture starts when the mount has completed its slew but long before it has settled. With a short 15 second exposure time that is really no problem for plate solve - no trails. If the exposure time is extended to 60 seconds the trails become very evident and plate solve will fail. The total image capture/ plate solve process takes about 30 seconds. If the mount is within the parameters (max pointing error in ACP Preferences) the mount will continue to settle and the first 600 second image shows oval stars. If the mount is outside those parameters ACP will move the scope to center - and, guess what - that is enough to set the mount into a new settling sequence which takes a minute or two. The first image captured becomes streaked and unusable.

So what to do? The first is to skip guiding altogether. The second is to set the Max Pointing Error to something fairly large like 5 arc minutes. If you are off by that much something else is broken. My experience is that pointing correction is almost entirely due to differences in star catalogs - PWI4 limits you to the one supplied by PlaneWave (although I think that will change). You only need plate solve pointing correction for detection of something else really wrong - not to get the CDK24 pointed at the target. The next is to set the Slew Settle Time in ACP Preferences to something like 60 seconds. And here is where I have a problem: This parameter seems to have no effect at all after a slew. No matter what I set it to the image capture starts at the same time. What do you suppose is happening?

The next item is to minimize slews. One issue is the movement of the mount for autofocus ( which I schedule for hourly) . AutofocusScheduler.vbs moves the mount to 270 AZ and 70 EL before autofocus starts. PWI3 is perfectly happy with large star fields and even bright globular clusters for autofocus. It really is brilliant. So here it might be better to not slew the mount but just leave it on target (for initial autofocus that could be anywhere as long as it is tracking). If the lines to move the mount in that .vbs script were to be commented out would there be any unintended consequences?

To sum up: What does Slew Settle Time in ACP preferences do? And if the mount movement for autofocus is commented out are there any issues?

Cheers,

John

[Bob Denny]

I took a look for the ACP log and cannot find it - is there a possibility that logging is disabled on my system?

Logging of ACP runs cannot be disabled. A failure to open the log should cause a script error, terminating your run. The ACP logs are located in Documents\ACP Astronomy\Logs\yyyymmdd, or if you are logging into the ACP web UI with a username/password, then you can get to the logs via the My Documents item in the left hand menu section of the web UI. [more below]

Snap1.png

Snap2.png

They are stored on your disk in an area that is walled off from the rest of the system, preventing the webserver from accessing any other files outside that area. That is Public Documents\ACP Web Data\Doc Root\logs\yourname\yyyymmdd\etc. If you are spelunking in that area, do not remove the .asp files, they are vital to the file browsing and access from the web for remote users.

With that said, your post is very interesting. I can see you have thought of some ways to avoid slewing in the first place (don't slew to the best skies for autofocus, etc). But the real problem here is that the Planewave is telling you that it has finished slewing when it actually is still settling to it's published accuracy. Other mounts have that coarse/fine slewing behavior. ACP is waiting for the mount to say it has completely finished by changing its Slewing property from True to False. ACP has to believe the mount. If the mount is lying, ACP is going to make mistakes.

To sum up: What does Slew Settle Time in ACP preferences do?

It tells the mount to add a fixed delay of x seconds to the time at which it would otherwise think it is finished, thus delaying the change of Telescope.Slewing from True to False. This came about back in the old days when some mounts were mechanically oscillating not from control system issues but from pier flexing resonances, had worm gear slop, from building vibration, etc. In any case it has been a feature of the ASCOM telescope interface since the beginning (and will "never" go away). See the official documentation for ITelescopeV3.SlewSettleTime. However putting an artificial time delay after each slew is a band-aid if the problem is in the control system. If the time needed to settle varies, then this will always give you the worst-case delay after every slew.

And if the mount movement for autofocus is commented out are there any issues?

Other than causing you to needlessly focus through high-airmass turbulent air, no. :-) Also if you patch that script I can't support it for other stuff, and you'll need to re-patch after an update.

I know my position on this seems heartless, but really the mount needs to behave according to the spec (and according to common sense). Has Planewave commented on this?

Bottom line, my recommendation is to increase the SlewSettlingTime. ACP currently has a maximum value of 60 seconds, and if you really need more I can adjust ACP to allow more without a downside. I just thought 60 seconds after every slew was ridiculous and put that limit in as a preposterous-value protection.

I'm moving this out of the ACP section since it is not an ACP isssue.

[John Downing]

Bob,

Thanks for the quick reply. I have made a request to PlaneWave to add this to PWI4 - Change the state of Telescope.Slewing to False when the tracking error on each axis (axis 0 and axis 1) are both less than a user definable setting such as .1 arc seconds. PWI4 does this calculation as the mount is moving so the data is readily available.

On SlewSettlingTime - I have changed this from the default of 10 seconds to 60 seconds. There is NO change in when the imaging starts after a slew. It starts at the same time - at about when there is about 1 arc second of tracking error as the mount completes it slew. Perhaps you can take a look.

I located the ACP log file. It was located in Users/username/Documents/ACP Astronomy/Logs/Scheduler/Observatory Operator . Here is this the ACP log for this evening (short night - clouds came in). Slew Settling Time in the ACP / Telescope tab was set to 60 seconds. As you can see in the log file this had no effect on image capture. Perhaps there is another setup issue?

John

[Bob Denny]

On SlewSettlingTime - I have changed this from the default of 10 seconds to 60 seconds. There is NO change in when the imaging starts after a slew.

Interesting... I haven't used this feature in soooooo many years. I have verified that ACP is indeed setting the SlewSettleTime. Here is the Pipe connection trace for connecting the scope with Pipe inserted between ACP and the ASCOM Telescope Simulator .NET

InterfaceVersion: 3Connected: -> True (done)
CanFindHome: True
CanPark: True
CanPulseGuide: True
CanSetPark: True
CanSetTracking: True
CanSlew: True
CanSlewAsync: True
CanSync: True
CanUnpark: True
CanSetDeclinationRate: True
CanSetRightAscensionRate: True
CanSetGuideRates: True
CanSetPierSide: False
CanSlewAltAz: True
CanSlewAltAzAsync: True
CanSyncAltAz: True
Name: Pipe->Simulator
AtPark: False
SlewSettleTime: -> 60 (done)
RightAscension: 07:09:47
Declination: +29:59:59
Tracking: -> False (done)
AtPark: False
AtPark: False
AtPark: False
Slewing: False
... blahblah maintaining the displays

Well that ASCOM Telescope Simulator .NET doesn't appear to implement the settle time! So I changed Pipe to connect to the Alpaca OmniSimulator's Telescope, and it is properly implementing the settling time. If I put 60 into ACP's Settling Time setting, then ACP's SLEW light will continue to flash for 60 seconds after the coordinates stop changing.

Conclusion: PWI doesn't implement SlewSettleTime. It should be throwing a PropertyNotImplementedException. Instead it is silently failing to implement the requested action.

Well the ASCOM Telescope Simulator.NET has the same bug :-( But at least the much newer Alpaca OmniSimulator implements it correctly. I doubt they will fix the ASCOM Telescope Simulator .NET because this bug has been there for years, and those old simulators are slated for retirement and replacement by the newer cross-platform Alpaca/ASCOM compatible simulators (which have been the subject of soooo much work).

I have made a request to PlaneWave to add this to PWI4 - Change the state of Telescope.Slewing to False when the tracking error on each axis (axis 0 and axis 1) are both less than a user definable setting such as .1 arc seconds. PWI4 does this calculation as the mount is moving so the data is readily available.

I understand, but 0.1 " might prolong the slew times needlessly and impact your cadence capabilities :-)))

I want to defend the honor of ASCOM (and ACP & other apps) here. Your request to Planewave is not a "special accommodation" for some weakness in ASCOM or ACP. If the scope hasn't stopped moving, to include shifting gears and performing fine-grain movements to complete its pointing to the requested target and establishing sidereal tracking, then it should not be telling apps that it is finished (and thus you can immediately start imaging). Anything less leaves the app guessing "so how long do I need to wait?" and the universal ASCOM spec is designed to prevent needing such device-dependent "accommodations". ACP and other apps (I'm certain) wait for Slewing to become False, then (correctly) assume the scope is pointing and tracking.

I'm actually surprised that it passes Conform. I'm going to check to see if SlewSettleTime is tested. I'm betting not because if the bug in the ASCOM Simulator. It's a lunatic fringe feature of the interface anyway ha ha. Knowing Peter Simpson, that test will be added in the future to include checking not only that Slewing stays True for the extra time, but using the coordinates being unchanged down to the arc second being used to tell if it has stopped motion (at which point the settle time test would start).

And finally, for overall perspective, the SLewSettleTime is a band aid in the first place :-) :-)

Post Script:

I located the ACP log file. It was located in Users/username/Documents/ACP Astronomy/Logs/Scheduler/Observatory Operator .

Oh !@#$%^& My error!!! I'm sorry!!!

[John Downing]

Wow! Many, many thanks for digging in to this. I will bring these observations to the powers that be at PlaneWave. 0.1 " is pretty tight but the mount does settle in to .06 " and stays that way. I'd probably default at .15 (depending on if I was doing long exposure imaging or something rapid fire like speckle). The settle time issue actually explains a number of problems that may have been misdiagnosed. And it's an easy fix. My trade off is that now I give up the first 10 minute image after every slew vs pausing a few minutes before imaging. The pause, if implemented properly in PWI4, is a small price to pay. For now my only alternative is to extend the initial plate solve image capture to something like 60 (or more) seconds, let the plate solve fail (which it will because of the star streaks) and move on to imaging. That should eat up enough time to let the mount settle. Ugly but it will do for now. I hope! I'll be on the horn with PW this morning.

Many, many thanks for the outstanding work this morning! It looks like I got a twofer - a bug in the original ASCOM simulator and a flaw in PWI4!

Cheers,

John

[Bob Denny]

Ha ha well 60 seconds for the settle time is a hell of a lot better than giving up the first 10 minute image :-) :-) Kevin I knows he can call me any time.