TargetInvocationException on Goto

[admin]

Hi Geoff,

ok, thanks for the logs. If you do work out which version breaks it then do let me know, as searching for the changes between two consecutive versions will hopefully narrow down the possibilities for the cause very quickly.

The logs do look promising - in the one with the slew, SharpCap tries to set an RA rate of -15.04 just before the failure, but in the log that works without the slew its -0.04, so something is different there coming from the SharpCap side.

I will dig a bit deeper and see what that leads me to!

cheers,

Robin

[Fir Chlis]

Thanks - I'm running through now installing incremental versions of SharpCap. I took a gamble that it worked when I first started using SharpCap back in January, so 11621 didn't crash. I'll post up here as soon as I find the first version that throws the exception.

Geoff

[admin]

Hi Geoff,

I think I might be starting to see where this is coming from - it is sending a custom tracking rate as part of turning the tracking on, and that custom rate is the -15.??? one that is out of range. I can sort of see why, but not quite sure what has changed yet, but got it down to 1 or 2 places in the code.

cheers,

Robin

[Fir Chlis]

Got it!

I've installed and tested every version from 11621 to 11824 and then it's 11922 that throws the exception.

Geoff

[admin]

Hi,

yes, that makes perfect sense now... I added one line of code to set the mount to tracking before setting the rate - seemed harmless enough and a good thing to do in case the mount wasn't already tracking at all.

The problem was, in some circumstances turning on the tracking would get a bit confused and try to set a 'custom' rate, which then causes the error. The old way did not do this and just set the tracking rate to solar (or whatever) and that was enough.

I think I have a fix in two ways

1) remove the extra line of code I added which turned out not to be needed anyway and wasn't as harmless as it looked

2) check before sending a custom rate to the mount and skip doing that if the rate looks like it is invalid.

I should really rework the whole of the special handling around EQMOD (annoyingly it doesn't let you easily set solar/sidereal/lunar rates, so I have to work around that in SharpCap). It was the special EQMOD code getting mixed up with other code that caused the issue. Not going to do that now as it is a bit riskier in terms of breaking other stuff...

cheers,

Robin

[Fir Chlis]

Well, I’m glad we’ve found the cause. Takes me back - most of my career was spent developing software in a similar genre to SharpCap, but that was mainly in assembler, FORTRAN, C/C++ and VB.

The bug isn’t a big issue in any case - and I’ve got a workaround. And I’ll probably not have the scope out again for a few months.

Geoff