0.00
#...
·
 |
|---|
|
I began using NINA when my GEM45 arrived and it's meridian flips were flawless. However, the last two times out I've used my GEM28 and after the flip, my mount becomes unresponsive to slew commands, even the hand controller will not work. I have to power off the mount and turn it back on to fix it. I'm new to NINA, and am aware there may be settings in there that I have configured improperly. I thought it may be the HC battery, but why would it only happen at the flip? This is a head scratcher for me. Please help! 😅 |
3.81
#...
·
|
|---|
|
I dont know if it's related, but i've had trouble with meridian flips all week. (never had a single issue with them prior) it's a bit odd for me. It's like the mount doesn't start tracking again after the flip. no hand controller on my CEM70 though. (I dont even plug it in) |
5.76
#...
·
|
|---|
| Is the mount parking itself? Look (in NINA) under equipment, telescope and see if it shows parked. |
|
0.00
#...
·
|
|---|
| I think I have figured it out, but I haven't been able to confirm yet. In the iOptron Commander there's a meridian setting and it appears defaulted to 'stop' so I changed it to 'flip' and will have to test it soon. |
0.00
#...
·
·
1
like
|
|---|
|
I am also using the GEM28 with NINA. There is a chapter in the documentation, where it says that the flip should be managed by NINA only. Worked fine for me. https://nighttime-imaging.eu/docs/master/site/troubleshooting/ioptron/ |
|
5.76
#...
·
·
3
likes
|
|---|
|
No, that's incorrect (setting it to flip). Or more precisely it should not matter because the proper way to set it up is so that the iOptron commander/mount does NOT participate in the flip at all. You need it set up so that the mount can continue moving throughout whatever timing and mechanism you set up in NINA. There are two approaches to setting this up in NINA, and most explanations tell you the hard way because it is more efficient in imaging time, but it also requires the mount (and mount control software) be carefully set up to stay out of NINA's way. In NINA there is a "Pause before meridian" setting. Most instructions say set it to zero, and what this means is NINA will image THROUGH the meridian and go counterweight up. Most mounts seem to default to taking some action to prevent counterweight up, either to stop, park, bounceback, etc. What I recommend for people struggling with this is to do the following: - Set the pause before to a small but non-zero number, let's say 2 (how small is governed by how well synchronized your mount is with NINA, e.g. clock, longitude, etc., if in doubt start a bit larger). - Set the after-meridian times (Both time and max time) to a similar small number, let's say 2. - Ensure in NINA the "use side of pier" is turned on (probably already is). Now here is what happens -- NINA images until you approach the meridian, but stops taking images so as to leave at least 2 minutes before transit. Note if taking 3 minute images this means it may stop up to 5 minutes before. It then STOP TRACKING so the mount stops moving, and sits and waits..... It waits until 2 minutes after meridian passage and issues a slew command to the mount for the target. This slew is not to a target past the meridian so the natural thing for the mount to do (pretty much all mounts) is to flip. This is NOT reliant on the mount's meridian behavior (flip, stop, park) this is just the normal thing that happens. This is the 'easy' way to do flips, and almost always works if times and such are reasonably synchronized. The downside is it stops imaging for 4+ minutes at meridian. For many a small price to pay. To contrast this to the more efficient approach, when minutes-before is zero, NINA images THROUGH the meridian and expects the mount to keep tracking and NOT REACT to passing the meridian. This requires the mount be configured for a period of counterweight up tracking, which is not the default. If you fail to configure it properly, it will take action on its own - stop, park, something. Nothing it can do is correct since NINA thinks it is in control, so even if it flips that is wrong since it will flip while NINA is imaging. The more efficient approach is good, and worth considering, but it does require compatible settings. I think anyone struggling should first try the easy, less efficient way. But do NOT try to let the mount participate in the process in the sense of itself invoking the flip. That will never work properly. It may WORK, but it will the defeat everything NINA must do following, e.g. a recenter, possibly an AF run, etc. Linwood |
|
0.00
#...
·
|
|---|
Linwood Ferguson: This is how I am currently configured in NINA. When it reaches the pause time, a separate dialog appears counting down and showing the progress of each step. It's when it slews (flips) to the target again, plate solves, syncs, and then tries to re-center is where everything has been going bad. Both times it hasn't re-centered and the mount became unresponsive. I didn't get a chance to test it last night as I was having major spacing issues (unresolved) with my new camera/filter wheel/oag. I also had updated the firmware that was 2yrs out of date.... I will put iOptron commander back as it was and see how things go tonight, it's looking clear so far. |
|
5.76
#...
·
|
|---|
|
If it flips but cannot plate solve one distant possibility is that it mechanically has flipped but the mount thinks the target is back behind the meridian still, or more precisely after the first plate solve it tries to slew back past transit and something in the mount hangs. Are you sure it successfully plate solves after the flip, and then it is the slew to recenter that hangs? It would be interesting to look at the log around that time, see what responses the mount sent back and how far off the sync was. If all else fails give it a couple more minutes to get further from the meridian. And finally ... double check cables. Everyone gets so hung up in flip configuration that sometimes they find a cable snag occurred but that's too low-tech to consider.  But most clues are in the log for what is happening. Maybe not how to fix it, but it may give a clue what. |
7.61
#...
·
·
1
like
|
|---|
|
Something to note, though probably not what's causing the mount to be unresponsive, is if you make the buffer Linwood mentions too long, or even a short buffer but long exposures like for narrowband, and don't have the target coordinates in the sequence, then the mount will re-center to the position it 'thinks' it's at, not necessarily the target's coordinates..... I'm not really sure where the difference comes from, whether it's related to the initial plate-solve and pointing correction, or drift that occurs while guiding is paused during the buffer time (not sure how that would work), but Cuiv mentions in one of his videos (that I can't find the link to now), and the problem went away for me once I put the target coordinates in the sequence. FWIW. Cheers, Scott |
|
5.76
#...
·
|
|---|
| Why would you ever run a sequence in NINA without the target coordinates in NINA? I think what you stated is true, it just seems like shooting yourself in the foot. |
|
7.61
#...
·
|
|---|
|
Ha! Cause I'm lazy and before I knew about the issue, I just a had a couple generic sequences (LRGB and Ha) that I'd use for all targets after the initial plate-solve. I'm curious, though, where the incorrect coordinates come from. It never occurred to me that the coordinates might change or revert during the auto-flip process. Cheers, Scott |
|
5.76
#...
·
|
|---|
|
Generally speaking if you want a meridian flip to work properly (as well as a lot of other stuff like center-after-drift), all instructions that image for an object should appear underneath the context of a target in the advanced sequencer. It is certainly possible to not do so, by using the sequential instruction or placing instructions at the end outside the target. A quick way to see if your instructions are in the proper context is to drag in a slew to RA/DEC. If it's under a target the instruction just appears, if it is not it creates a slot for you to enter the RA/DEC. Look at this example. the target (right now not filled in but present) is above and includes one slew instruction (green arrow), but the other is outside and does not. So when executing anything like the last instruction there is no target context, and in a meridian flip it does not know what to do (other than use the last suspected coordinate). Generally everything when imaging should be under a target.  |
|
0.00
#...
·
|
|---|
Linwood Ferguson: This is what's shown in the logs, after a successful plate solve: 2023-07-17T01:25:57.9763|ERROR|AscomTelescope.cs|Sync|733|Telescope is not tracking to be able to sync 2023-07-17T01:26:12.2068|ERROR|AscomTelescope.cs|SlewToCoordinates|705 ... ASCOM.InvalidOperationException: Slew To Normal Pointing failed. ---> ASCOM.InvalidOperationException: Slew To Normal Pointing failed. ... 2023-07-17T01:26:42.6482|INFO|TelescopeVM.cs|Disconnect|742|Disconnected Telescope ... 2023-07-17T01:26:46.0690|WARNING|TelescopeVM.cs|SlewToCoordinatesAsync|931|Telescope is not connected to slew I was watching the meridian flip (as I do, because I'm paranoid), and nothing was snagged. When it hung, I tried to use the hand controller to go to Zero Position, no response, I couldn't even slew it with the controls. This was 'fixed' by powering cycling the mount. The most recent one was a little different: 2023-07-23T00:56:47.9607|WARNING|TelescopeVM.cs|SlewToCoordinatesAsync|881|Slew issued while a prior slew is still in progress! Waiting for the prior slew to complete 2023-07-23T00:57:30.7693|INFO|TelescopeVM.cs|Disconnect|742|Disconnected Telescope ... 2023-07-23T00:57:31.5970|INFO|TelescopeVM.cs|SlewToCoordinatesAsync|904|Slewing from to RA: 19:44:10; Dec: 23° 21' 22"; Epoch: JNOW This last one is interesting. There is no "from" coordinates, and then it fails. |
|
5.76
#...
·
|
|---|
|
Once the telescope is disconnected I do not expect anything reported about it to be valid. Are you saying the "disconnected" is not because you disconnected it (notably in the latter case)? If you did not disconnect it, you need to figure out what did -- commander (a logical disconnect of some sort), a physical disconnect, etc. Or am I not understanding. The very first line of log would indicate the telescope stopped tracking, but I would anticipate something in the log before that to say why? |
|
7.61
#...
·
|
|---|
|
Not updating NINA and moving to the advanced sequencer is another bit of laziness, but promoted by some paranoia.....so far, every time I've made a significant change to my set-up, new hardware or software, things go wonky for awhile......like USB ports not recognized or the focuser or filterwheel randomly disconnecting from NINA, and before I figure it out, the issues sort out on their own.....until next time. Anyhow, I'm still curious where the incorrect coordinates come from, but that doesn't help the OP. When I've had an unresponsive mount as a result of a meridian flip, it was as you described Linwood, the mount's meridian settings weren't compatible with NINA's. Basically, NINA wanted to continue, but the mount says sorry, I'm not allowed to go any further, and then everything stops. So the settings I use are 3 deg after the meridian in the mount (12 minutes) and 1 minute for 'pause before meridian' in NINA, but I could be more efficient and set NINA to 0 and even with 10 min Ha subs, in theory I should still have at least a 2 min buffer. Note that 3 deg past meridian doesn't cause any problems for my set-up, but may not be appropriate for others. Cheers, Scott |
|
0.00
#...
·
|
|---|
Linwood Ferguson: I am almost certain it was logical. In the commander mount control panel the ra/dec numbers were spinning like slot machines. I closed that and restarted it and it was still stuck. I'm hoping it was a "first encounter" of a bug that caused the firmware upgrades that I recently installed. My stuff was only 2yrs old.... 😅 |
|
5.76
#...
·
|
|---|
| Well, at least you appear to have localized it to the mount and/or its firmware and/or commander. I guess and/or its driver (which is separate from Commander). iOptron should help. |
