I am using the Planewave PWI3 driver for rotator and focuser to control the intgrated IRF90 focuser/rotator from Planewave. When I run a sequence it seems like only the rotator is connected but not the focuser. The focuser module is greyed out and after the sequence has ended the connect button is red.
I can then manually connect the focuser driver and then I can control the focuser.
Also I noticed that during the sequence, the rotator always shows 0° position. But actually the rotation is 58° since I use an Alt/Az mount and the camera must be derotating the telescope slew. After the sequence has ended, the rotator module shows the proper rotation in the position field.
Here is a screenshot from the PWI3 and PWI4 screens during the sequence. The rotation position ist 58° and the rotator is tracking the mount.
What I also don’t understand is shown in the following log of the PWI3 software. The angle must be 58° to derotate the camera if the camera rotation is set to 0° in the sequence. I then changed the camera rotation to 20° in the sequence. The resulting rotation should be 78°. This can be seen in the follwing screenshot. The rotator starts rotating to 78° but 5s later it stops and rotates back to 58°. I am not sure if this is an issue for Planewave or SGP or simply a misconfiguration. Is this target field angle sent be SGP?
SGPro will only connect to gear that it needs to execute the sequence. Really we don’t need to disable all gear connection functionality… just gear that is critical to the sequence. You just want to move the focuser manually during the sequence? If there is a need for us to distinguish between critical / non-critical gear and only disable certain equipment, we can look at that later. For now, I think you can fake a dependency on the focuser by choosing to use auto focus, but clear all the triggers.
Im not sure about this. Connected to my rotator and also connecting to the ASCOM sim rotator, the physical position of the rotator is displayed correctly (both when the rotator is moved from SGPro and external to SGPro) so it’s hard to say if this is a driver issue or if it’s a UI issue. You can try to connect to the ASCOM rotator simulator and see if the UI responds differently and also always read 0 regardless of the true PA.
I think this is a bug in the new code and it’s calling the method that goes to a sky angle which considers the delta between PA and the camera’s sky angle. Since this is an absolute mechanical rotation, we should ignore the PA to sky angle sync and just move to the absolute PA.
Also, please note that version 731 will retain the same functionality as “verify” and “do not verify”, but I have gone with different descriptors for this new functionality. The default functionality where the target will rotate to a sky angle and iterate / verify until within range will choose “using sky angle”. The one your sequence requires will choose “using positional angle”.
Because of this change, your target’s rotation settings will need to be reapplied and the first attempt to open target settings may result in a blank entry for the new field.
ad focuser: In my final setup I will use the auto focuser. Right now I am testing all components on my desk before I am installing them in my observatore. Therefore this should not be an issue later on.
ad position feedback.
When I connect the rotator I get the position feedback in SGP. But in the rotator simulator the position and sky angle are both 15°. Which value do you show in SGP?
The rotator did not rotate my camera 20°. I found this in the log file:
[01/17/22 16:31:59.235][DEBUG][Sequence Thread][SQ;] Telescope: Slewing has completed
[01/17/22 16:31:59.237][DEBUG][Sequence Thread][SQ;] DoEventGroupChange: Slew complete
[01/17/22 16:31:59.248][DEBUG][Main Thread][SQ;] Adding sequence level notification: Rotating to 20,0° (mechanical angle)…
[01/17/22 16:31:59.252][DEBUG][Sequence Thread][SQ;] Sending Notification: Status - Rotating to 20,0° (mechanical angle)…
[01/17/22 16:31:59.253][DEBUG][Sequence Thread][SQ;] ASCOM Rotator: Moving rotator to PA 20
[01/17/22 16:31:59.253][DEBUG][Sequence Thread][SQ;] ASCOM Rotator: Error in MoveMechanicalAsync : MoveMechanical is not implemented because the driver is IRotatorV2 or earlier.
bei ASCOM.DriverAccess.Rotator.MoveMechanical(Single Position) in C:\ASCOM Build\Export\ASCOM.DriverAccess\Rotator.cs:Zeile 278.
bei SequenceGenerator.AscomRotator.ih(Single A_0)
I am not sure if you have already noticed. If you connect the Dome Simulator.NET the observatory Shutter shows “Opening” for ever and the sequence will not start. I have to manually press the Close and the Open button in the Observatory module to make the shutter work and start the sequence.
I was afraid of this… looks like we will need to do interface version checks. The rotator interface was a bit of a mess early on. It would be great if all rotators implemented against the new contract.
I dont’ think that MoveMechanical is the right command. The rotator driver in PWI3 will be calibrated with platesolve and then the mechanical angle is of no relevance. Also in Alt/Az mount configuration the compensation in rotation angle must be added to the final mechanical angle. This is done in the PWI3 driver. I think you need to send a “sky” angle to the PWI3 driver.
SGPro is only aware of the current sky angle of the rotator through a plate solve. Since your target is not solving, SGPro is only aware of the mechanical angle.
What I understand from talking to Planewave support. In the PWI3 driver the 0° sky angle is calibrated thorugh a platesolve. Then SGP only sends the “offset” to the rotator. If e.g. the camera rotation in the target setting is set to 20° you simply send a position of 20° (not the mechanical angle from interface version 3) without invoking a platesolve. I think for SGP it simply skips the plate solve and sends the value set in the target settings.
Dietmar
I think we are saying the same thing or something close to it. I think you are speaking from the perspective of looking at the rotator and I am speaking from the perspective of how SGPro views the rotator. From SGPro’s perspective, for your rotator, there simply is no offset. An offset implies that SGPro has a point of reference by which to calculate an offset and it doesn’t (SGPro doesn’t deal with relative offsets, but having no offset is nearly the equivalent). Because it doesn’t it will just ask the rotator to move to 20 (with an offset of 0). From SGPro perspective, this is equivalent to the mechanical positional angle of the rotator and no offsets are involved. From that point, it seems like the PWI driver applies its own offsets and I think this is where this conversation went in different directions.
In any case, the next beta will still use MechanicalPosition if the driver supports it (because I think this would have worked for you if the driver had it implemented… PWI driver would have still applied its own offset to this). If the driver does not support it, it will apply a standard absolute movement with no offset.
This thread was just brought to my attention, and I took a look at adding the IRotatorV3 interface to PWI3. I’ve built an initial version which you are welcome to try to see if it resolves any of the issues you’ve encountered. Here is a download link:
Right now I just treat the standard Position and MechanicalPosition as being the same. This should at least help you avoid the “MoveMechanical is not implemented” error message you were seeing before. The proper implementation requires a bit more investigation into how this should be handled for Alt-Az mounts, where the offset between the true mechanical position and the sky position angle is not constant (which seems to be something that the ASCOM standard assumes.)
Hi Kevin,
thank you very much for this quick implementation. From my point of view it is working excellent. I am summarizing what I have seen.
In PWI3 I have set my field angle to 0° at the rotation I want it to be 0° with the button “Set Angle”
In SGP I set my camera rotation to 15°
When I run the sequence in SGP the rotator rotates to 63° (48° from Alt/Az derotation + 15° camera rotation and then starts tracking the telescope. I physically checked the angle on the rotator and the 63° look right.
Who sends the command "new target field angle 31°? I did not find this number in the SGP log. PWI4 reports a field angle of 0° as shown in the screenshot above.
Except for the park position everything looks fine to me.
I haven’t tried to diagnose your specific problem but I recently helped an imaging buddy setup his new Planewave L-350 mount and CDK14 scope with the IFR90 focusing-rotator. His scope is in alt-azm mode.
Learning to understand the IFR90 rotator was a time consuming challenge as its behavior never seemed to match expectations.
Here are the issues we finally came to understand:
Field Angle -vs- Position
Field angle is the sky position angle of your camera as reported by a plate solve; whereas Position is the mechanical position of the rotator.
There is ALWAYS a difference between your camera’s sky position angle and the rotator’s (mechanical) position. This is what PW refers to as the “offset” and there is a screen in PWI3 where you set that value. You can fiddle with your camera’s rotational position on the rotator to get the camera’s sky position angle close to the rotator’s mechanical position but it will never be exactly the same.
Do a plate solve in SGPro and get the camera’s sky position angle. Compute the difference between the sky position angle and the reported rotator position. Enter that value in the screen where the “offset” is recorded.
The rotator (and focuser) use an internal encoder and those “ticks” are converted to position angle (and focuser steps). The conversion has rounding errors. Commands to move to a specific position (step) will often stop one step off. This is why SGPro would report that the focuser was not at the commanded position.
Now, the side effect of alt-azimuth rotation is complicated - because it is variable. The amount of rotation and speed of rotation depend on the declination of the target. When the L-350 is slewing to a target RA and DEC, PWI3 is computing how much the rotator needs to move and in what direction so that the camera stays at the specified sky position angle. The slew is not reported as completed until the scope has reached the the target RA and DEC and the rotator has reached the required mechanical position angle needed to put the camera at the specified sky position angle. The mount will get to the target RA / DEC in just a few seconds but the rotator may take another full minute. If watching the rotator position in PWI3, you will see the rotator sometimes changing direction and speed during the slew as the declination being reported by the mount is constantly changing until the slew completes.
The PWI3 documentation is massively out of date with the software and trying to read the documentation and use the software was an exercise in frustration.
It comes from a plate solve. SGPro has calculated the difference between the mechanical angle of the rotator and the sky angle of the target as 10 degrees. There is no option to manually move the rotator to a mechanical position, but it’s easy enough to add.
I dont use a plate solver. My camera and rotator are still sitting on my desk. Anyways I have installed the latest build and I get the following results. There is still this 10° (350°) offset I have seen before.
The following 2 screenshots are taken with the scope unparked and tracking during imaging.
SGP actually shows the field angle from PWI3 as mechanical angle. And the sky angle is not really related to the data from the PWI3 driver. Does SPG not simply show the 2 values reported by PWI3?
My camera is set to 15° rotation. Therefore the 15° field anlge makes sense. Together with the rotation due to the Alt/Az mount of 7° (reported by the PWI4 driver) results in a mechanical angle of 22° as shown in PWI3.
And the following 2 screenshots are from the parking position. There are again the 10°/350° offset but PWI3 actually reports the same value of 2° for field angle and mechanical angle since the PWI4 driver reports a field angle here of 0°.
I believe the PWI3 interface screen was written primarily for manual control of the rotator or, perhaps, for software doing direct control of the rotator – NOT ASCOM.
Using ASCOM, only the mechanical position of the rotator is readable / setable. On the PWI3 screen, this is “Position”. The “Field Angle” on the screen is the camera’s sky position angle. PWI3 allows you to define an “offset” to the Position that represents the Field Angle. This offset must be calculated after a plate solve has told you what your camera’s sky position angle is.
SGPro (and all ASCOM applications) can only set the mechanical position of the rotator. After a plate solve, SGPro knows the current sky position angle of the camera; eg, 92.6 degrees. If you want the camera to be at 90.0 degrees, then SGPro tells the rotator to move -2.6 degrees; that is, change the “Position” by -2.6 degrees.
Having said all this, I can tell you that I spent several hours trying to get PWI3 to move and maintain a specified camera angle without success. Finally, giving up, I configured PWI3 to always keep the rotator at “Field Angle” 0.0 degrees. This required setting the “offset” to an exact value calculated from a plate solve. I then disabled rotator control in SGPro. My friend who owns the L-350 / CDK14 only does photometry, so a fixed camera angle of 0 degrees was fine for his work.
I will also say that my friend and I had a discussion about removing the IFR90 and replacing it with an Optec Gemini Rotating-Focuser and the Optec derotation software but his need to have precise camera position control did not justify the expense.
When I look a the ASCOM interface it should be able report the mechanical angle and the field angle separately.
With the latest PWI3 driver version 3.5.6 and the latest SGP beta build my rotator performs exactly as expected, even in Alt/Az mount configuration. I can specify a camera rotation in SGP and the IRF90 does exactly what it should do. The only thing I don’t understand are the values reported back by the IRF90 to SGP and how SGP interprets and displays those 2 values. I have a stationary setup, hence no need for plate solve. I only do one plate solve when I calibrate my mount/rotator and from now on I have an absolute 0° field angle.
The v2 implementation of the ASCOM rotator had some notable shortcomings that v3 contract addressed. That said, the SGPro implementation of the ASCOM rotator is kind of a mess because some of the meaning have changed. For instance, the ASCOM property Position used to mean the mechanical angle and clients like SGPro were responsible for any kind of sync to produce a sky (field) angle. Now the meaning of Position has changed can mean either depending on the driver. I think that the changes I made in beta 741 should match expectations for reporting now (should correctly handle v3 drivers which I think PWI3 is now using if I understand previous posts correctly).
