TargetInvocationException on Goto

[Fir Chlis]

Possible bug here, maybe related to v4.1.12100.0, as I've not seen it before and have only just upgraded to 12100. I don't think that I changed anything else, apart from setting my camera to 2x2 binning, has always been 1x1 before.

The past two nights, I've done my usual polar align with the SharpCap polar align tool, immediately followed by a goto catalog target. After pressing Start on the goto dialog, a TargetInvocationException pops up and the goto dialog closes.

Following this, goto operations seem to work (when I go outside the scope looks to be pointing in generally the right direction), but SharpCap fails to plate solve after the initial goto.

Log files attached for the 22nd and 23rd April. On the 22nd I just gave up, as cloud had come over, on the 23rd I gave up after attempting a few gotos because it was consistently failing to plate solve.

I've also attached the later log from the 23rd, as this shows SharpCap consistently failing to plate solve - just in case that is relevant to the problem.

Cheers

Geoff

[admin]

Hi Geoff,

from the logs it looks like EQMOD is generating an error when SharpCap is asking it to turn on tracking - the underlying error looks like it is a numerical overflow (numerical value too large to be represented properly).

I wonder if EQMOD has somehow got a weird tracking rate configured and when SharpCap tries to turn on tracking, the calculations give an error before SharpCap has a chance to send the second part of the command which would set sidereal rate tracking. I would try cycling through some tracking rates from the EQMOD application to see how that works out (it also might clear any saved EQMOD data with a bad tracking rate being remembered).

Looking at the code, I don't think there are any changes between 12066 and 12100 that are likely to have caused this from the SharpCap side (if you upgraded from an earlier version, do let me know and I can search further back).

cheers,

Robin

[Fir Chlis]

Thank you - I'll see what I can do, but it may be the Autumn before I can test properly. It's not really dark enough now until about 22:30 so I think I've given up for the next few months.

I may be able to to a general test during the day - though I can't test polar aligning. I'll see whether SkySimulator will run with my HEQ5Pro - at least I could see if the mount points in roughly the correct direction.

May or may not be significant, but on both occasions the Polar Alignment process had taken a long time.

I'll be back if /when I get a chance to test this for real.

Geoff

[Fir Chlis]

Just checked, the last time I ran it was v12025 - so I've skipped v12066.

On both occasions with v12100, the exception occurred after a protracted period of polar alignment - lots of frames where SharpCap couldn't detect enough stars.

On both occasions, I closed and restarted SharpCap subsequent to the exception. The first night (22nd) I stopped almost immediately due to clouds, but the second night (23rd), gotos worked without generating the exception - though plate solving kept failing.

Geoff

[admin]

Hi Geoff,

thanks for the update - just did a check of the mount control related changes between 12025 and 12100 and I don't think there is anything relevant to this situation - basically the changes came down to

* Error handling around park/unpark
* Changes to how the code waits for the mount to settle
* changes to talking to remote Alpaca devices

Unfortunately that doesn't help much determine what the problem *is*, just what it isn't...

You can probably test without needing dark skies - just run some GOTO movements with the mount from SharpCap and switch in/out of tracking (and between tracking rates) to see if you can come up with any pattern as to when it happens. Spotting some pattern is usually a good first step to understanding then fixing the issue.

cheers,

Robin

[Fir Chlis]

Hi Robin

I’ve done some testing this morning with the mount connected and the cap on the camera, and the problem is repeatable. It doesn’t seem to be version related within recent versions, as I uninstalled 12100 and reinstalled 12025, which exhibited the same problem.

The following sequence consistently produces the Exception. I've tested this 10-20 times this morning, restarting SharpCap between tests.

* Start SharpCap
* Connect camera and mount (ASI585MC, HEQ5Pro)
* Unpark
* Slew telescope in RA axis using telescope control panel. Amount of slew and slew rate don’t appear to matter. Direction of slew doesn't matter.
* Goto Sun using Goto Catalog Target
* Exception occurs immediately after pressing Start

If I restart SharpCap and repeat the sequence, but don’t slew, then the Goto works as expected. I suspect that it has only appeared recently because I have just changed my procedure. I used to do the first stage of the polar align from the park position (having unparked the scope), now I slew the scope about 3h left or right before starting the first stage, using the telescope control buttons.

If I restart SharpCap and repeat the sequence but, before I slew, I set the tracking rate to sidereal (using the SharpCap telescope control panel), the Goto works as expected.

I've attached log files for each of these three scenarios.

The obvious workaround for now is to set a tracking rate manually before doing the initial slew.

Cheers

Geoff

[admin]

Hi Geoff,

thanks for testing - I can still use EQMOD on my system here, so I will try that out and see if I see the same result. If I do, it should be possible for me to work out what is going on and hopefully fix it.

cheers,

Robin

[admin]

Hi Geoff,

just tested this on my NEQ6 with EQMOD 2.00w and (typically) it works fine...

I had a dig around the source code for EQMOD itself to see what might cause a maths overflow error when starting tracking, and an incorrect custom tracking rate having been set is certainly one option (the custom tracking rate is added to the normal sidereal tracking rate).

I'd like to suggest getting EQMOD to log all the requests that come to it, but I can't work out how to make that happen in EQMOD. So, instead I would suggest that you turn on 'Mount Hardware Communication' logging in SharpCap before starting a test (see https://docs.sharpcap.co.uk/4.1/#Logging%20Settings). That will record in the SharpCap log all the commands SharpCap sends to the mount and all the responses that come back.

Additionally, when the error has happened, please bring up the 'Scripting' window in SharpCap and enter these two commands

Code: Select all

SharpCap.Mounts.SelectedMount.AscomMount.RightAscensionRate
SharpCap.Mounts.SelectedMount.AscomMount.DeclinationRate

You should get numbers in response to each command - like this

Code: Select all

>>> SharpCap.Mounts.SelectedMount.AscomMount.RightAscensionRate
0.0
>>> SharpCap.Mounts.SelectedMount.AscomMount.DeclinationRate
0.0

If one of those numbers is weird (very large?) then maybe that has something to do with it.

cheers,

Robin

[Fir Chlis]

That's brilliant - thanks for the quick response. I'll have a go and let you know the results.

I haven't intentionally set a custom tracking rate, but I'll have a look at my EQMOD config and see if I can see anything. My setup is about as simple as it can be for SharpCap live stacking - one camera, no guiding, eqdir cable direct to the mount.

Sorry if it turns out to be a config issue at my end.

Geoff

[Fir Chlis]

I've done the requested tests and had a look through the log files myself, but can't spot anything obvious other than the overflow in the ASCOM driver (which we knew), and the Move Mount commands as the mount slews (which includes a Set Slew Rate).

I can't see anything odd in my EQMOD configuration.

What's significant is that if I slew the mount first, the goto fails, but if I don't slew, then it works. So what is the slew operation doing to cause the exception? I’ve also tried (unsuccessfully so far) to find how to enable debug logging in EQMOD/ASCOM.

I've attached two log files, with the mount hardware logging, one for the slew case (exception) and one for the non-slew case (goto works).

For the scripting commands:

SharpCap started, camera connected
>>> SharpCap.Mounts.SelectedMount.AscomMount.RightAscensionRate
-15.041067
>>> SharpCap.Mounts.SelectedMount.AscomMount.DeclinationRate
0.0

After slew in RA direction
>>> SharpCap.Mounts.SelectedMount.AscomMount.RightAscensionRate
-15.041067
>>> SharpCap.Mounts.SelectedMount.AscomMount.DeclinationRate
0.0

After Exception thrown
>>> SharpCap.Mounts.SelectedMount.AscomMount.RightAscensionRate
0.0
>>> SharpCap.Mounts.SelectedMount.AscomMount.DeclinationRate
0.0
>>>


I've repeated the test on my other laptop (which I normally use as a VNC client) and the behaviour is identical - exception thrown if I slew before doing the goto. This is a completely separate installation (but the same versions) of SharpCap, ASCOM and EQMOD. Any configuration would have been done by hand - not copied across - and would have been the minimum needed to set up the mount (e.g. LAT/LONG, COM port, epoch).

I've now gone back to the scope control laptop and installed the oldest version of SharpCap 4.1 that I can find (10970) and the exception is not now thrown. I'll try and iterate through the other versions to find out which release has introduced the issue.


Cheers

Geoff