I’m having some trouble with using the Nitecrawler rorator part with SGPro.
First I noticed that the rotation direction of NC didn’t agree with SGPro.
For example the platesolve reports the angle as 340 degree.
I set the rotation angle to 0.
NC rotates but the angle from the plate solving is now 320 degree.
This is solved by checking reverse rotation option in the ASCOM setup dialog for NC rotator.
However I found that NC doesn’t take the shorted direction to get to an angle.
For example the current angle is 340 degree.
When I set the destination angle to 0, NC tries to rotate 340 degrees to get to 0 instead of moving 20 degrees in the opposite direction.
I tried to play with min and max rotation angle in the ASCOM setup dialog but the results were not consistent.
While I don’t use a Nitecrawler for rotation, I do use Optec rotators. As part of the “cord wrap” logic, most rotators have a “do not pass” point. If taking the short direction to the target position will cause the rotator to cross the do not pass point, the direction of rotation will be reversed and the rotator will go the long distance to the target position.
For example, with my Gemini rotator after I have done a homing routine, the rotator is at 0 degrees instrumental. The Gemini has a sensor at the 75 degree position that is the do not cross point. So to go from 0 degrees to 76 degrees, the Gemini will take the long direction through 270, to 180, to 90 to 76.
That makes sense.
NC doesn’t seems to be having a hardware limit as Gemini but uses ASCOM setting.
The ASCOM min/max was set to -190 to 190 in my case (they are the default).
I may have to increase the max to 360.
Still it is not perfectly clear how the cable management setting works in the NC ASCOM.
I still want to use the rotation limit but I’m not sure how I can set them correctly for my case.
I thought that min/max rotation setting were sky angle but it may be the mechanical angle if they are for the cable management.
I will think about this again for tonight.
Hello,
I just received my Nightcrawler and have the question of why doesnt it take the shortest path to get to the desired angle.
I was just getting familar with things indoors and using the Rotation module, it doesnt take into account the rotation limits I set in the Ascom driver. So my limits are -130 to 130 but if I type in 140 degrees it still goes past 130.
My guide camera runs into my polar scope past 130 degrees is why I set these limits. This would be a real problem in the field if my target needs 170 degrees and rotates past my 130 degree limit instead of going to 350 degrees (with +/- 180 degree option checked) It would need to rotate just 10 degrees counter clockwise to get to the 350.
I believe the ASCOM rotator standard requires the rotator to report internal or instrumental position angle to the client app. The rotator doesn’t really know anything about its orientation to the sky. Once you have used SGP’s “solve and sync”, SGP will know the rotator’s (camera’s) sky position angle and SGP will know how to map the sky position angle to the rotator’s internal position angle. This allows SGP to make precision moves of the rotator.
Once you have done the solve and sync you should only move the rotator using SGP and not the native NC control software. For example, after the solve and sync let’s say SGP sees the camera is at sky position angle 94.3 degrees. However, you want the camera’s orientation to be 186 degrees so that the OAG camera has a good guide star. You would enter 186 into SGP and click “Set” to move the rotator to that sky position angle.
SGP will not send the sky position angle to the NC, so it can never know the sky position angle. Possibly the NC control software may allow you to enter the corresponding sky position angle and it will keep that separate from its internal position angle but maybe not. To be safe, always move the rotator using only SGP. Do not be confused if SGP and the NC report different angle settings – SGP will be correct.
@chasmiller46 has this right, the rotator only knows about it’s internal position angle. Also mixing the ASCOM and non ASCOM controller could give trouble
I will need driver logs to be able to do any sort of diagnosis.
The driver is intended to avoid cord wrap so a move from 0 to 270 would be expected to move 90 degrees to -90 (aka 270) but I will need the log to check this because it ay depend on the movement history.
Setting limits of -130 to 0 to +130 does not cover the full 360 degree range of rotation and should generate a warning when it is set up. Commanding a move out of this range should cause the move to generate an error. Again I need a log to be able to investigate.
Thanks for the replies. After fiddling around more indoors, this is what happens:
From zero degrees, if I type 270 into the Rotator module, it will in fact rotate the quicker path of counter clockwise (-90) This is good
But if I type 180 from the starting point of 270 degrees (only 90 degrees away from each other), it takes the long way around moving clockwise back through zero and around to 180.
*Edit- this is probably desirable because of cord wrap, but it still goes past my 130/-130 limits and does not generate an error.
Unfortunately, using the NightCrawler in the house with the native NC control software may not provide much new information other than confirming where the “do not cross” point is.
I could not find any documentation on the NC on the MoonLite web site but homing a rotator typically sets it to instrumental position 0. From that point you can command incremental moves to see where the rotator suddenly reverses direction and goes the long way to the target position. That reversal point needs to be noted and used as your cord wrap position.
When right clicking on a .fits image and selecting center scope here, is SGP supposed to move the rotator to match the angle of the image or is the rotator always a manual step within SGP? I notice that beside Pixel Error there is a Rotator Error and mine says N/A and doesn’t give a value of error.
I’m not using Moonlites’s non-Ascom software at all. All my previous posts have to do with using the rotator thru Ascom and SGP only.
As I stated before, I type in the ASCOM driver for the NC (thru the SGP settings button) the rotation limits of 130/-130.
I will do some more testing to see at which point it decides to reverse direction. Right now my thought is that it’s ignoring the settings I’m putting into the ASCOM driver but I will post the logs so Chris can analyze it and do his wizardry.
Thanks again
Dan
Edit@Chris, I forgot to mention before, you are correct that typing in a limit into the ASCOM driver less than 360 does generate an error message
I’ve checked and the rotator driver doesn’t seem to use the limits set in the driver setup at all.
I’ll look at implementing the limits and get a new version out. One thing that may be tricky is that the shortest move from 130 to -130(230) is via 180 which is in the forbidden zone.
I’m also not sure how SGP will cope with an unexpected error if it commands a move into the forbidden zone.
Sorry about that. I think that what happened was that I sent a first version to the beta testers, expecting there would be issues, and there weren’t.
Using the default of 190/-190 everything works as expected. When I put in 130/-130 it works correctly on the counter clockwise side (230) but when on the clockwise side it goes past the 130 limit, past 180 and all the way to 230 before it flips rotation in the other direction.
Let me know if you need me to do any more tests or what kinds of data you need
Try setting the range to +131 to -131, then only use the range 130 to 0/360 to 230.
What I’ve found is that the rotator sometimes goes the wrong way if a move is exactly to the limit but if it’s a tiny bit away from the limit it is OK. It seems to be something to do with how I’m working out which way to move.
I found that a move to 230.01 was OK but to 230.00 wasn’t.
This is pretty tricky. The slowness of the rotator makes it slow to debug. Maybe it needs a test harness.
The “center here” option does not move the rotator. You will need to use “solve and sync” at the beginning of your session to sync both the telescope and the rotator. Once that is done, you use the SGP controls to move the rotator to the desired sky position angle.
Also, when your target setup includes slew, center and rotate, SGP will perform the automatic rotator movement at target start. BUT it will only be accurate if the rotator has been sync’d to the sky prior to starting your target. Also, if you use the “Always” option on the sky position angle, SGP will rotate the camera 180 degrees as part of an automated meridian flip.
@Chris
I was able to briefly test the new driver this morning. I tried 30/-30 and it worked excellent. When you type in a value outside the driver limits nothing happens - which is expected.
One thing I could say is to possibly add an error message when you try to go to a degree value outside the range you set in the driver. Maybe this is an SGP thing and not a driver thing.
Also, when you do Manual sync in SGP it doesn’t change the actual rotator value shown on the little display on the Nitecrawler. This isn’t a big deal, just something I noticed.
This is an SGP thing. I throw an exception, it is up to SGP how they handle it.
This is also an SGP thing. The manual sync applies an offset to the position in SGP only and doesn’t affect the driver at all. Incidentally the limits remain relative to the driver zero so if you set a manual offset of 30 then the allowed range in SGP will be +100 to -160.