Fatal error : Solar/lunar framing Assistant

[stbkaiser]

Thanks Robin
I do appreciate your support effort for these odd ball issues.
For some reason I don't seem to have the skill to accurately setup my mount for Solar tracking during the day.
No problem if I polar align the night before , and leave the mount alone.
But I know I will be chasing a cloudless sky location the morning of the eclipse.
Take care
Steve

[stbkaiser]

Hi Robin
Still have a problem with Solar/Lunar Framing assistant
I am running with your "beta"
SharpCapInstall-4.1.11890.0-64bit
Not sure if this release was trying to implement the
Move the mount in 'steps' for high movement rates - 0.5 second move

When I try to use the Framing assistant , it only lets me select 63.8 speed (which seems to be = 0.266666)
From looking at the log file, When I try to use the framing tool , it looks like your software is trying to use the
0.26666666666666666 rate
As noted before , even though ASCOM says 0.26666666666666666 is valid, the interface to the mount throws an error when this rate is tried.
Rainbow Astro has not fixed this rate in the ASCOM interface.
excerpt from log file.
----------------
sharpCap.Base.WPFFrameDisplay.GetWriteableBitmapLease(Size size, PixelFormat pixelFormat)
Warning 13:09:15.883904 #37 Error from MoveAxis attempt with parameters Primary, 0.26666666666666666 : Exception of type 'InvalidValueException' : unspecified
---------------
attached it the log file

Take care
Steve

[admin]

Hi Steve,

I've seen a few uploaded bug reports with this issue in, which are probably from you. Based on what I can see, I think this is a bug with the hubo ASCOM driver, since it says it can support that movement rate 0.266666... and then when SharpCap requests it, it says 'nope, can't do that, no good'. At one point (SharpCap 4), SharpCap could end up rounding the value for the movement rate, so that the mount got sent a value that was very slightly different to the one it said it supported, but that is fixed in SharpCap 4.1.

I think the thing to do would be to turn on ASCOM logging in the hubo driver, then test and see what shows up in the ASCOM log - that will (should) reveal the values that the ASCOM driver is receiving from SharpCap to sanity check that the right number is getting through and maybe some error information too.

For the pulsed movement, when selected, SharpCap will move 0.5s then pause 1.5s, then repeat.

cheers,

Robin

[stbkaiser]

Hi Robin
Yes there is a problem in the ASCOM interface reporting rate
63.825252222222225x, 0.267 deg/s as being valid but ASCOM will not accept this as a valid rate command.
I'm working to get Rainbow Astro to fix this issue.

Maybe I am mistaken but I think the current issue with trying to "Pulse" the mount.
It looks like your code trying to use the 0.266.. rate to pulse.
As we see, the ASCOM interface will not accept this rate.
Would it be possible to have your sw "pulse" the mount using 1495.9043489583335x, 6.250 deg/s rate.
We know the ASCOM accepts this rate.
Thanks
STeve

[admin]

Hi Steve,

my intention was that the pulsing should use the rate that is currently selected in the UI, so the pulse nature should reduce the overall speed of that rate by about a factor of 4.

I think the code is correct to do that, but I will check - I am seeing the right movement rate, but also seeing cases where after a while the movement stops completely during calibration, so something may be wrong.

cheers,

Robin