Mount tracks into Pier if Meridian Flip plate solve fails

I barely avoided having my mount crash into my pier last night. I happened to wake up early so I logged on to my obs and luckily was able to witness the entire event.

The following sequence will crash your mount into the pier:

  1. Meridian flip time has arrived and SGP starts the flip process
  2. Before actually doing the flip, it does a plate solve, the plate solve fails
  3. It goes into recovery mode trying to get a successful plate solve
  4. meanwhile, the mount is merrily continuing to track into the pier, for as long as you have set recovery mode for.
  5. it never does the flip and crashes into the pier.

Fortunately I was monitoring the whole process and after 5 tries at plate solving, I terminated the run.
Whew!! Saved by the bell.

Why in the world does it need to do a plate solve before doing the flip? I have always wondered about this. It should just immediately flip the mount, as requested, then proceed with centering.
sg_logfile_20191017174519.zip (222.4 KB)

BTW, the entire night’s runs on both scopes ran perfectly with v313 up to that point, which was 4:45am. The new auto-focus was spectacular. I love the new focus graph.

I would also like to see SGP avoid a plate solve and then flipping to that position. In my case I often have some small drift due to guider mount flex. I’d rather start fresh on target than to the position after hours of drift.

Least common denominator I suppose… if you are not using target centering, we need to know where you are. In any case, I have added logic to skip this step IF the running target used centering to get on target.

With the above change in logic… which, for lack of a better term, I am referring to as a “blind flip”, recovery logic has changed. It is VERY possible to get into the situation you describe in a manner having nothing at all to do with flipping. Say that you lose the guide star 10 minutes before meridian. Now the recovery routines will recognize this and perform a blind flip. If this fails, the sequence quits and runs end of sequence. If successful, it will continue recovery on the other side. Keep in mind that this blind flip logic is not continuously checked (maybe in a future release). It is checked only when a recovery attempt is made. The significance of that statement is that your mount should be able to track safely past meridian by an amount of time equal to to recovery attempt interval.

1 Like

This is all very reasonable. Your solution looks perfect.

“If this fails” … how can it fail if I have recovery mode turned on? I would expect it to continue trying to get a successful center/plate solve until my requested recovery period has expired, or time has reached the end time of the last target.

In the interest of full disclosure, my mount would not have actually crashed into the pier. My limits are set to prevent that. However, it certainly could for other folks.

If the recovery routines ask for a flip and no flip occurs, recovery is done and we shut down… as you mentioned, this is the situation we are trying to avoid… where recovery is trucking along but the mount might be in a precarious position.

Got it. If the mount physically fails to respond to the flip command, then clearly we must abort. Of course that must be true in all cases where the mount won’t flip. So this is a user equipment failure situation.

So to make sure we are clear on what will happen here with the new release, is the following statement true?

Recovery mode is set to last for 12 hours, retrying every 5 minutes.
Regardless of when clouds come in, SGP will march through every target either taking images, or existing in recovery mode trying to recover from either a guiding error, or a centering error after a flip.
At the end time of each target (assuming they have an end time), slew and center to the next target will occur, even if the program is in recovery mode.
This process will only stop after time has reached the end time of the last target.

What I am hoping for is that the next release will allow me to continue imaging or in recovery mode all night regardless of weather. I deal with the weather by controlling my dome independently. Blank images I can easily eliminate by using the fine built in image grader.

All true

True, recovery honors both target and sequence end times. It is likely, that centering on the new target will also fail, but recovery is now in a state that where it is attempting to recover the “new” target.

True.

Continuous imaging modes will be a big part of the lift for 4.0. In the meantime, the closest approximation of this is through a safety monitor. 3.1 has a setting that will shut your gear down (mostly) when it reports UNSAFE ti image and will automatically restart the sequence when it is SAFE.

Awesome!. This is exactly what I have been looking for. This gives me continuous imaging now. I don’t need and won’t be using the safety monitor since my dome control program deals with all the safety issues and powers off my equipment at night’s end. Excellent Ken. You and Jarod are putting some amazing finishing touches in the 3.1 release. This is a real winner.