SharpSky ASCOM compliant digital focuser project

[allan gould]

Originally Posted by dtrewren

Hi Peter,

Not at all, good suggestions based on real usage

I have incorporated your suggestions into the client and have uploaded V1.9 onto the website.

See what you think and let me know.

Cheers & clear skies,

Dave

This is getting too fast for an old fellow to keep up with. Great work Dave and Peter.

[wasyoungonce (Brendan)]

Originally Posted by allan gould

This is getting too fast for an old fellow to keep up with. Great work Dave and Peter.

I was thinking the same...quick service indeed

[peter_4059 (Peter)]

Dave,

I've downloaded V1.9 this afternoon and really like it now. The new layout is a lot better IMHO.

I've tried out all the buttons and combination of switching temp compensation on/off, moving it with the on screen buttons and the hand controller and from what I can tell it is making all the right moves.

I'm a little confused about when I'd need to use ref lock - it seems to do the same thing as hitting the ref position go button?

Thanks for the quick turnaround. Will spend more time testing this weekend.

Peter

[dtrewren (Dave)]

Hi Peter,

Excellent, pleased you like the layout

The Ref lock :
This button, if checked, removes any component added due to temperature or manual control. So as an example :

Ref lock : unchecked (default)
Abs position : 25000
Reference position : 25000
Filter 1 offset : +100
Filter 2 offset : +200

Hit Filter 1 Go : Abs position 25100
Hit Filter 2 Go : Abs position 25200
Hit Reference Go : Abs position 25000

Temperature compensation adds in +5 steps

Hit Filter 1 Go : Abs position 25105
Hit Filter 2 Go : Abs position 25205
Check Ref lock button
Hit Filter 1 Go : Abs position 25100
Hit Filter 2 Go : Abs position 25200

So with Ref lock checked all filter movements are with respect to the reference position only and any temperature/manual movement is lost when you move to a new filter position or even the same filter position as with the example. This allow you to move to an absolute filter position and start compensation from the point fresh clearing out any previous movement.

Hope that makes sense ?

Thanks for taking a look, much appreciated !

Cheers & clear skies,

Dave

[peter_4059 (Peter)]

So just to clarify the ref lock I'm assuming I'd see:

Hit Filter 1 Go : Abs position 25100
Hit Filter 2 Go : Abs position 25200
Hit Reference Go : Abs position 25000

Temperature compensation adds in +5 steps

Hit Filter 1 Go : Abs position 25105
Hit Filter 2 Go : Abs position 25205
Check Ref lock button
Hit Filter 1 Go : Abs position 25100
Hit Filter 2 Go : Abs position 25200

uncheck ref lock button

Hit Filter 1 Go : Abs position 25100
Hit Filter 2 Go : Abs position 25200

temp comp adds +5 steps
Hit Filter 2 Go : Abs position 25205
Hit Filter 1 Go : Abs position 25105

does that sound right?

Peter

[dtrewren (Dave)]

Hi Peter,

Absolutely right, just been through the sequence and that is exactly what what you see.

With the Ref lock unchecked as you move around any compensation and/or manual intervention is added to the absolute position. When you check the Ref lock compensation and/or manual input is only effectively valid for the current filter as soon as you move to a new filter the additional input is discarded.

By manual input I mean either via the software GUI or the manual control.

Cheers,

Dave

[rjweng91 (Bob)]

Dave,
Thank you so much for taking the time for making this kit, I only burnt my finger once. Tested it out last night with Focusmax and MaximDL; they worked great.

Thanks
Bob W

[dtrewren (Dave)]

Hi Bob,

That's excellent news, always good to get at the end of the day. Was that trying the focuser out in anger while imaging ?

If it's any consolation I also burnt my fingers this evening. After drilling & tapping the beam couplers I wash them in warm soapy water to remove the cutting grease and then bake them at 150 degrees C for fifteen minutes to dry before inserting the grub screws.

Observation : very hot aluminium looks the same as cold aluminium but feels very different

Clear skies,

Dave

[peter_4059 (Peter)]

I've recently upgraded to a win7 64bit laptop and have started to have some issues with the stepper controller. If I try to move up to 100 steps there are no problems. If try to move 1000 steps or more I get an error "Cannot access a disposed object" and the focuser disconnects. (I've been using sequence generator pro to control everything). I haven't tried this with the Sharpsky client yet so I'm not sure if the error is with the driver or with SGP however this has only started being an issue since I changed to win7. On some occasions when the focuser disconnects it leaves the stepper motor running and I have to remove the USB connection to stop it.

It is not a massive deal as normal focusing only requires a move of 20 steps at a time however if I want to rack the focuser back in it can be tedious to move 4000 steps in 100 step increments.

Any thoughts?

Peter

[dtrewren (Dave)]

Hello Peter,

That's an interesting one, not seen that one before. The only tricky problem is that I don't have a machine running W7 64bit .... at the moment. Going to see if work IT can knock me up said machine so I can debug the issue. Had a look on-line and there seem to be lots of people getting a message like this and lots of misinformation flying around as to the reason. I will look into it, if I can replicate the problem I can fix it.

Small favour :
If anyone else is running W7 64bit with any client program and fancies having a go at a large move say 2000 steps I would appreciate the feedback just to see if it's a universal problem or just particular to Peter's setup.

I'll get onto it

Clear skies,

Dave

[peter_4059 (Peter)]

Hi Dave,

I tried it out today with the SharpSky client and didn't have any issues. I think I know the answer but can you confirm the Sharpsky client is using ascom to drive the focus controller?

The issue seems to be related to Sequence Generator - if I do too many small steps close together or one big lot of steps it seems to generate this error.

It is not a big issue as I don't have a problem with a few small steps so the autofocus works fine.

There should be a few others that have win 7 64 bit and your controller and some are using Sequence Generator so shouldn't be too hard to get some testing happening.

Cheers,

Peter

[dtrewren (Dave)]

Hello Peter,

This is very interesting

Yes, the SharpSky client is just another ASCOM compliant client. So it connects the the driver in exactly the same way as any other client using the same API. You can connect the SharpSky client to any ASCOM compliant focuser for example the focuser simulator and it will work.

What to do .....

I think I will carry on with my plan of replicating the problem on a machine here and see what I can figure out. Trouble is with this software business is there are always many ways to skin a cat. If it looks like the error is being thrown in SGP I will have a chat with the guys there and see what can be done to stop the problem.

The SharpSky driver is fully ASCOM compliant and passes the conformance checking where large movement tests are performed. However, projects are about issue solutions and not blame so it must be fixed.

Where is that IT guy when you need him !

Clear skies,

Dave

[peter_4059 (Peter)]

You've got me thinking now Dave. Perhaps I should connect SGP to the focus simulator and see if I get the same error?

[peter_4059 (Peter)]

Just tried SGP with the ascom simulator and it works without any issues. I should also mention here I have seen a couple of error dialogue boxes - the one I mentioned earlier "Cannot access a disposed object" and another "Object reference not set to an instance of an object". Not sure if this casts any more light on the issue?

Peter

[dtrewren (Dave)]

Hi Peter,

yep, I just tried the simulator with SGP and it worked fine. I think the issue is to do with time. When connected to the simulator a movement of say 2000 steps is virtually instantaneous. However, when connected to a real focuser 2000 steps can take some time to execute.

While the motor is moving there is a chain of command. The PIC is aware the motor is moving because it is physically driving the motor. So the user initiates a move and client sends the command to the driver via ASCOM. The driver interprets the command and sends a command to the PIC via USB. The PIC receives the command & starts the motor moving. Now the client wants to know what the motor is up to so polls the driver for motor status, in tern the driver polls the PIC for motor status. PIC reports motor moving to the driver, driver reports to client and client reports to user .... an so on until the move is complete.

So if the client is waiting for something to happen and it doesn't happen or takes to long it might get upset and throw an exception or error. The part I'm a bit confused about is that the ASCOM conformance checker checks for correct driver response and is happy. So I am not sure why SGP is getting upset.

These sort of problems are what make development interesting

Dave

[dtrewren (Dave)]

Hello Peter et al,

I have just been doing a few experiments. Using W7 (32bit) and XP I performed large moments of 5000 steps using APT, SGP, ImagesPlus 5.0 & my client all without issue. So the issues does appear to be a platform 64bit OS problem.

Just a small point. you might notice when doing a very large movement to on occasion the motor will stop for about 1/2 second and then continue to move. This is normal and is caused by the client requesting a temperature update if the probe is fitted. The probe can take about 1/2 second to return a value so things stop while it is being accessed. No motor steps are missed just a slight pause in movement.

Clear skies,

Dave

[peter_4059 (Peter)]

Dave,

I'd also concluded it was a time related issue. Definately not a show stopper but it would be nice to resolve.

Hopefully some of the other users are able to test and help get to the bottom of this.

Peter

[dtrewren (Dave)]

Hello Peter et al,

I have just had a very interesting hour on a W7 64bit machine (I really must get out more )

- Installed the SharpSky driver
- Installed my client
- Installed SGP (latest version)

- Tried my client - no issues all good any number of steps
- Tried SGP with 100 steps - no issue
- Tried SGP with 1000 steps ........ whoops fell over

Same error message Peter is getting, I won't repeat Peter's report but my experience was the same.

- So tried SGP 100 steps again - all good
- Tried SGP 101 steps - whoops, fell over as before !!!!!

So, and this is the interesting bit ! I then decided to install another client, in this case I installed APT. Unfortunately, APT wouldn't install in the 64bit environment. The APT installation realised this and automatically un-installed itself cleanly.

NOW - I then tried SGP again ...... fixed ! Any number of steps in any direction always worked. I removed my driver and SGP and re-installed both everything working fine still any number of steps

This is what I think & I'm more than happy to be corrected :
I think SGP has a small issue with the 64bit environment, possible a run time library problem or something like that (bit too hard core for me). When APT tried to install it brought with it some run time library modules or made some change to the environment probably installing some x86 stuff that SGP is relying on. So after the APT failed install SGP subsequently has access to whatever it was missing in the environment and is now happy. I have been unable to replicate the SGP problem following the failed APT installation.

So, Peter you could try an APT installation (it's free) and see if this fixes your problem. I will report my findings to the SGP boys and see what they think.

Let me know how you get on ....

Clear skies,

Dave

[peter_4059 (Peter)]

Interesting Dave. Which version of APT did you use - was it the free version of V1.93?

Peter

[dtrewren (Dave)]

Hello Peter,

Indeed, simply the demo version 1.93 :
http://www.ideiki.com/astro/Download.aspx

I am not suggesting this is a solution to your W7 64bit issue, but an interesting experiment none the less. I have joined the thread you initiated on the SGP forum with the hope of getting to the bottom of the problem wherever it may be. Been very impressed with the SGP forum and the level of feedback & support. I am going to generate a debug version of my driver that does not require the hardware so that the SGP developers can test out the interaction between client & driver. I am hoping the issue is not with the driver but am happy to stand corrected - either way it gets fixed.

Be very interested to see what happens if you attempt an APT installation and whether this fixes the issue with SGP ......

Cheers & clear skies,

Dave