Looking for some insight into what may have occurred during my imaging run last evening. I had my 1100GTO set to do a smart meridian flip using NINA. This has worked in the past, but last night something serious happened.
The flip was to occur at 01:13:23.  When I checked the scope this morning it was counterweight up, pier-side east and APCC had the fault: East Limit Reached. There was not a pier crash (good!) but I lost half my subs (and clear nights are hard to get here in Maryland lately :)


My NINA and AP logs can be found below if anyone would like to help me out (I have a hard time deciphering these logs). 

https://www.dropbox.com/s/f0jtrbgudrwqtyq/APCC-2022-09-01-210259.txt?dl=0
https://www.dropbox.com/s/nonui224h0vunfw/NINA%2020220901-210203-2.0.1.9001.7564.log?dl=0
https://www.dropbox.com/s/gyd2p74rgpqxxzs/APCC%20Screen%201.png?dl=0

Thanks much

On Fri, Sep 2, 2022 at 09:50 AM, Michael 'Mikey' Mangieri wrote:

Looking for some insight into what may have occurred during my imaging run last evening. I had my 1100GTO set to do a smart meridian flip using NINA. This has worked in the past, but last night something serious happened.
The flip was to occur at 01:13:23.  When I checked the scope this morning it was counterweight up, pier-side east and APCC had the fault: East Limit Reached. There was not a pier crash (good!) but I lost half my subs (and clear nights are hard to get here in Maryland lately :)

You may want to ask on the discord channel for NINA, the people who really know are there regularly.  When you say though it was pier-side east -- do you mean east?  So it was already flipped but went CW up when it flipped?  

I did see this in the log: 

2022-09-02T01:09:41.9544|INFO|MeridianFlipVM.cs|DoFlip|127|Meridian Flip - Scope will flip to coordinates RA: 21:39:09 Dec: 57° 34' 46" Epoch: JNOW
2022-09-02T01:10:43.6149|INFO|MeridianFlipVM.cs|Settle|322|Meridian Flip - Settling scope for 30

That seems to indicate it spent a minute or so moving, and notice the destination RA is 21:39:09. 

Then look at the next plate solve (below).  It says the real coordinates are RA 01:08:19  which is 4 hours off (DEC is right), and perhaps even more strange the mount reports 04:41:22.  It's like it moved to a very wrong place and even so thinks it is somewhere else and stopped tracking.  Not knowing your location or anything hard to say where the target was, but was 1:13am when you expected it to flip?  Did the mount have "room" in its limits to reach that?   I would start there, first figure out RA 21:39:09 is the right place, see where it was relative to the meridian at 1:13am, is that actually when you wanted it to flip.  If all that looks good, something happened while the mount did that slew? 

But I really dropped by to say if it looks like it is a NINA question you may have better luck over on discord.

2022-09-02T01:13:03.4865|INFO|ImageSolver.cs|Solve|54|Platesolve successful: Coordinates: RA: 01:08:19; Dec: 57° 23' 06"; Epoch: J2000
2022-09-02T01:13:03.4895|INFO|CenteringSolver.cs|Center|84|Centering Solver - Scope Position: RA: 04:41:22; Dec: 57° 30' 23"; Epoch: JNOW; Offset: RA: 00:00:00; Dec: 00° 00' 00"; Distance: 00° 00' 00"; Bearing: 00° 00' 00"; Centering Coordinates: RA: 21:39:09; Dec: 57° 34' 46"; Epoch: JNOW; Solved: RA: 01:09:43; Dec: 57° 30' 11"; Epoch: JNOW; Separation RA: 20:29:25; Dec: 00° 04' 34"; Distance: 27° 32' 07"; Bearing: -67° 29' 09"; Threshold: 1
2022-09-02T01:13:03.4945|ERROR|AscomTelescope.cs|Sync|725|Telescope is not tracking to be able to sync

Linwood

Interesting.  I just got done posting to Discord about a similar issue and haven't heard back yet.  I had the smart meridian flip working very reliably several months ago and took some time off and the past several nights it hasn't worked.  Nothing has changed except the required updates for Win10, NINA.  Just updated the ASCOM driver this morning thinking it was one additional thing to try.  I've got my meridian limits set in APCC so if the custom limit is exceeded it will stop tracking.  Three nights in a row no flip has occurred despite checking all parameters and the mount stops mid run.

Joe

Linwood --- 
The object was IC 1396 and the RA is correct (21:39:09).  According to my meridian limits, the eastern limit is 01:12:18 (based upon interpolation of the data in the tracking limit table). And yes, it was when I expected it to flip. 
I'll repost this info on discord. Thanks.

Michael did you a tracking or pointing model active at the time of the flip?

Yes. 

I had a very similar problem and was caused by creating a Dec-arc tracking model that did not provide enough data points to be used as a pointing model.  Didn't realize it would be an issue and had the "Use Pointing Model" box checked.  When a flip occurred and it actually started pointing in a wrong direction.  The rig ended up trying to do plate solves pointed at the ground.  I was standing next to it watching.  At least that problem was solved by unchecking the pointing model box.  Just one cause with a similar sounding outcome.  No idea if it's the same circumstances as yours.  

Well, I tried to recreate the issue with the meridian flip this evening. I used 33 Cyg instead of IC 1396 so that I could start the sequence earlier (it has a similar DEC and so should mimic the same flip.)  I just watched the sequence complete the flip flawlessly and then continue imaging the star post flip.  Go figure.  No problem at all this time! I may still post this conversation to discord later. 
I wonder if NINA was in the process of taking the 300 sec exposure and the limit was reached during that time if that could cause the problem? But I think NINA wouldn't get into that situation as I think it wouldn't have started the exposure and thus execute the flip earlier, but never later.

--

So I tested the flip again this evening. This time I set long exposures on my camera to make sure the flip time would be within the exposure time range. NINA did what I expected. Since the next 20 minute exposure would contain the flip time and meridian limits NINA executed the flip early. Once again the whole process executed flawlessly. So I am at a loss as to way the initial problem occurred. Computers and software; gotta love them :)

Glad to hear everything is working well.  Who knows what went wrong.  My setup is working as expected again.  After exchanging messages with Dale Ghent on Discord he indicated the box labeled “Send Offsets to NINA” found in the Meridian tab of APCC does nothing and he wasn’t sure why it was there.  I’ve noticed it was originally programed there for Sequence Generator Pro and is labeled as such as default.  When NINA is being used along with APCC it changes to “NINA”.  Long story short, I unchecked the box and the mount flips are executed correctly, multiple times now.  Clearly checking the box does something to confuse the programs.  

I don’t have my AP mount yet, but have owned many mount models. So I’ll take a stab at explaining this as simple as I can, not knowing how much you might or might not know. Hopefully it will help you figure out the issue.

A meridian flip is nothing special. It’s just a goto command to go to a target. The reason the mount flips, is you are hopefully sending a goto command to a target that has passed the meridian, and for the mount to target it, it has to flip the orientation so it can track it down to the horizon from the meridian. 

You want to set the mount meridian limit to something like 5 degrees past the meridian. This way you can image to the meridian and past it, up to the 5 degrees. In NINA you want to set the mount to flip at 3 degrees past the meridian. This ensures you don’t send the goto command before the object has passed the meridian. Your scopes can track the object 3 degrees past the meridian this means the next goto command that is sent is to that object which is now past the meridian, but before you hit the 5 degree limit where the mount will stop tracking. 

If you issue a goto before the meridian, it will not flip. If the mount stops tracking because you hit a tracking limit before you issue the goto, it will not flip. AP mounts could have some feature that conflicts with my statements, but essentially you don’t want to issue any goto before the object has passed the meridian, and before you hit any limits that would cause it to stop tracking.

Hopefully that makes sense.

Regards,
Andrew

So what attitude did you find your mount after everything went off the rails?

My Mach1/NINA setup was working perfectly with the meridian flips being triggered exactly on time...until they weren't.  I was in the middle of an imaging project so was using the same imaging sequence I'd had been for half a dozen or so nights prior and all had been great.  Absolutely nothing had changed except me saving the sequence at the end of every night to preserve the additional progress. Then one night it all comes to end end and the mount runs against the meridian stop in APCC before NINA flips it.  

In my case there has to be some mismatch of timing/imaging site (or something) as every night it's failed the mount has come to a hard stop prior to NINA's projected flip time. I was going to research things a bit more tonight but the fog's here already.

Joe 

The mount parked itself after the failure but in each case it was off. Sometimes about 1hr in RA sometimes both DEC and RA are off. Each time I had to release the clutches and reset the mount to the Park3 position. 

From what I can tell it looks like the west meridian limit (APCC setting) is triggered while the mount is in the
process of a flip.

Actually, the mount did not flip because the target hour angle was within the meridian limit:

From your APCC file:
0947776 2022-09-27 23:28:02.884: Info, SafeSlewStateMachine, East/West Meridian Delay = -1.20583333333333 / -1.20583333333333, Target HA = 1.14080555085138

The mount's meridian delay is a negative value to the West, while hour angle is positive, so:

Target hour angle < -(West Meridian Delay) => no flip will occur.

-Ray