Arduino Ascom focuser Mark2

[IanL]

OK now  I'm in need of some help to get this working working with Sequence Generator Pro:

- I can successfully connect to the AAF2 in SGPro and get it to drive the focuser in and out using both the focus control docking module and the auto focus routines that run as part of a sequence. Note that I need to tick 'Reverse Focuser Direction' in the SGPro control panel to get the motor going in the correct direction for IN and OUT.

One issues I am having is that the position reported by SGPro in the focus docking module does not match with the position set by the AAF2 driver. So for example, if I force the initial position to be 1000 in the ASCOM chooser thus:

- The driver is correctly reporting a position of 1000, I can see this in AAF2 trace file, e.g. if I use the focus control docking module to move the focus control 'IN' 50 steps, it needs to move to position 1050 (as the direction is reversed per the settings):

14:55:38.670 Move                      1050

I have confirmed this more thoroughly by connecting to the focuser using the ASCOM Pipe device and the POTH device and can see the AAF2 ASCOM driver and the Arduino sketch seem to be in agreement about the 1000 -> 1050 move.

SGPro reports the initial position as being 9000 though:

After pressing 'IN' it reports 8950. So the relative number of steps seems OK 50 steps in the opposite direction to what the driver reports per the reverse setting above, but the absolute values are out of whack for some reason 8950 vs 1050. Any idea why SGPro is reporting a different value to the driver? (I know this might be one to take to the SGPro forum, but see below as there are other issues which may be related).

Secondly, when digging in to the SGPro Logs whilst connected directly to the AAF2 driver I am seeing regular errors as follows:

[12/11/17 14:55:55.683][DEBUG] [Focuser Thread] ASCOM Focuser: Error in IsMoving wrapper. : Exception has been thrown by the target of an invocation. (System.Runtime.InteropServices.COMException (0x80040402): Timed out waiting for received data
   at ASCOM.Utilities.Serial.ReceiveTerminated(String Terminator) in C:\ASCOM Build\Export\ASCOM.Utilities\ASCOM.Utilities\Serial.vb:line 1204
   at ASCOM.AAF2.AAF2.CommandString(String command, Boolean raw)
   at ASCOM.AAF2.AAF2.isMoving()
   at ASCOM.AAF2.Focuser.get_IsMoving())
   at System.RuntimeMethodHandle.InvokeMethod(Object target, Object[] arguments, Signature sig, Boolean constructor)
   at System.Reflection.RuntimeMethodInfo.UnsafeInvokeInternal(Object obj, Object[] parameters, Object[] arguments)
   at System.Reflection.RuntimeMethodInfo.Invoke(Object obj, BindingFlags invokeAttr, Binder binder, Object[] parameters, CultureInfo culture)
   at System.RuntimeType.InvokeMember(String name, BindingFlags bindingFlags, Binder binder, Object target, Object[] providedArgs, ParameterModifier[] modifiers, CultureInfo culture, String[] namedParams)
   at rb.ml()
   at q5.br(Boolean A_0)

I'm not sure why these are triggering, they seem to happen sometimes by themselves and other times immediately after connecting to the focuser driver or after doing a move.

I do not see these errors in the SGPro log when connecting via POTH. My suspicion is that the POTH is still seeing these timeout problems from the AAF2 driver, but is not passing them up the line to SGPro but I can't see any way to diagnose if that is the case?

I think this lack of ability to determine 'IsMoving' is a cause of erratic behaviour in SGPro. When I try the auto focus routine it generally fails to work unless I try it a lot of times - the focus position seems to jump around erratically - maybe because SGPro is trying to do further moves before the last one is complete? I see a nice downward line starting to form after maybe three autofocus steps and then suddenly it will jump up again, causing SGPro to try to restart the autofocus with a bigger intial rack-out. (I admit it might just be backlash or not having configured things properly, but trying to nail down one issue before the next so I can be sure what is going on).

Any thoughts - there definitely seems to be a driver issue somewhere - I don't think it is a sketch or comms problem at the Arduino end as everything else seems to work as expected?

 

Edited December 11, 2017 by IanL

[OuterObsession]

Hi, IanL

Depending on how the optical train and focuser is set up on your telescope the stepper motor may turn the wrong way. The same thing happened to me, I forget if I reversed it in the Arduino sketch or via my astro software - don't think it really matters.

What does AAF2Test report the position as? You should also try other astro software that supports ascom focuser like Astro photography Tools. Maybe you made a typo in the Arduino sketch relating to the go commands?

In any case knowing the starting position isn't really important for a lot of autofocuser routines. So it doesn't really matter if your astro software is reporting the same focuser position as long as the value that it's moving the focuser by is correct. What I usually do is manually move the focuser into close focus then run the auto focus routine on Astro Photography Tools, this way the stepper motor doesn't have to run as much. You just need to be careful that you don't run past the end points on your focuser. Because my ED100 uses a crayford focuser it just slips so not really a big issue.

As a side note of noticed that my nema 14 doesn't have as much precision as I first thought. It seems to focus really nicely but I might try some gearing just to see if it makes any difference.

Cheers,
Jameson
 

[OuterObsession]

And thanks for combing the Arduino sketches, I was going to do that originally but thought there were to many differences to justify it.

[IanL]

I did some more testing after the above post and I found:

- AAF2 was reporting the 'correct' position. whereas SGPro continued to report a completely different position every time I disconnected one and connected the other.

- When I created a new equipment profile and re-added the focuser I then got matching positions between AAF2 and SGPro. So somehow with the original profile SGPro (or far less likely the ASCOM driver) is 'remembering' a different position. I couldn't figure out why.

- I did some further testing and maths and determined that the physical size of each 1/8th microstep was way too small with this motor, gearing and the fine focus reduction. So really I need to use full steps not 1/8th microsteps.  This may explain the autofocus failures as perhaps the focuser was not moving sufficiently at each focus point and SGPro was measuring small differences due to seeing rather than focus moves.  The weather hasn't allowed me to do any further testing yet but I'm pretty sure that is one of the issues.

- I couldn't figure out the cause of the ASCOM isMoving errors or whether they were important, but it was a bit worrying. I decided to try a different project's Arduino firmware and drivers to see if the problem occurred there and it did not so at the moment I can only conclude the problem lies somewhere between SGPro and this particular ASCOM driver.

- As an aside I ran in to a whole bunch of other issues due to a small difference in the serial comms with Pro Micro boards vs. the Nano boards supported by the other project. The project's author worked with me to resolve the problems and I think I'll be sticking with that project going forwards (e.g. a lot more of the settings can be managed via the driver rather than by changing the sketch).

- One important point that I picked up along the way is that you should only be disabling the FETs on the EasyDriver board if you are using full steps. If you use any form of microstepping and disable the FETs between moves then the stepper is going to jump to the nearest full step position, which will then cause the motor/focuser position to drift relative to the reported step position over time.

- By extension, if you want a reliable starting position per filter (as supported by SGPro for example), you either need to have a method to repeatably position the focuser at startup relative to a known step number, OR you need to park the focuser at a full step position at the end of a session before powering off. If not you are again likely to experience drift over a a number of sessions due to powering off the motor whilst it is in a microstep position and having it jump uncommanded to the nearest full step.

Hope this helps!

[Mick J]

This is all over my head Ian, but good to see you are 'on it' and getting somewhere.  What is the other project ? you are now using.

[OuterObsession]

On 12/21/2017 at 21:02, IanL said:

- One important point that I picked up along the way is that you should only be disabling the FETs on the EasyDriver board if you are using full steps. If you use any form of microstepping and disable the FETs between moves then the stepper is going to jump to the nearest full step position, which will then cause the motor/focuser position to drift relative to the reported step position over time.

Wouldn't small changes from night to night require you to refocus anyway? If the stepper motor can't hold a position less then one step without keeping the coils energised shouldn't it just use full steps?

Also does anyone know of a method for auto-focusing for planetary/lunar photography?

[IanL]

3 hours ago, OuterObsession said:

Wouldn't small changes from night to night require you to refocus anyway? If the stepper motor can't hold a position less then one step without keeping the coils energised shouldn't it just use full steps?

Also does anyone know of a method for auto-focusing for planetary/lunar photography?

Yes but typically each filter would start from a known position where it is near focus. Over time that position would be invalidated. Whether you can use only full steps depends on:

With regard to whether to use full steps or not:

Critical Focus Zone in microns = focal ratio x focal ratio x 2.2

So my scope is 6.38, making a CFZ of 89.41 microns (i.e. the range of focuser travel within which the image is in good focus).

Distance moved per motor step in microns = Distance moved per focus shaft turn in mm x 1,000 / steps per motor turn x motor gear teeth / focus shaft teeth

So my motor has a step angle of 1.8 degrees, making 200 steps per turn, I have an 18 tooth pulley on the motor and a 36 tooth pulley on the focuser shaft and the distance moved for one turn of the focuser shaft is 1.43mm.

Thus I get a distance per step of 3.575 microns, and 89.41 / 3.575 equates to 25 steps in the CFZ. The distance moved per step needs to be a reasonable fraction of the scope's critical focus zone (say 10-20 steps), so mine is a bit too high but not unacceptable.

If there were too few steps, then one would try half, quarter or eighth microstepping to increase the number of steps by 2, 4 or 8 respectively. If too big then there are a number of strategies - change the motor, change the gearing or just increase the number of motor steps per reported step number in the Arduino firmware.

[OuterObsession]

Yeah I'm thinking of experimentation with a geared nema 14. I need to do the maths but it seems like I'm not getting enough precision with the setup I have currently. I think that the microsteps are going to cause too many issues in the long run and I just need to change more of my setup to reflect using full steps.

[RolandKol]

Hi guys, a bit offtopic as you are far away in your projects.

As nights are mostly cloudy, I want to start experimenting with Stepper motors for the remote focuser (simple one: with 2 buttons and a speed controller) and I wonder if you can advise and direct me to the best initial start.
From my google explorations, I have picked up 28BYJ-48 Stepper Motor (5v) with ULN2003 driver and UNO R3 Arduino Rev3 board for a start.

I have few questions in relation:

1) Is this 28BYJ-48 5-volt motor powerful enough for 130PDS focuser with Canon 1300D camera (around 650g in total) in it? (I strongly doubt it will be enough)

2) In case I will succeed with a remote focuser project and will decide to move on to autofocuser, - will UNO R3 Arduino Rev3 board be the right board to interact with ASCOM driver? if not, which should I go for?

Thank you for any comment in advance!

Regards,

R.K.

 

 

Edited March 12, 2018 by RolandKol

[Davey-T]

There are quite a few tutorials on using stepper motors on Y'Tube, there are also a few threads on here if you search.

Dave

[John78]

1. no, it wont even move the focuser alone - even with 12v

2. its a reasonable option

 

 

On 12/03/2018 at 17:00, RolandKol said:

1) Is this 28BYJ-48 5-volt motor powerful enough for 130PDS focuser with Canon 1300D camera (around 650g in total) in it? (I strongly doubt it will be enough)

2) In case I will succeed with a remote focuser project and will decide to move on to autofocuser, - will UNO R3 Arduino Rev3 board be the right board to interact with ASCOM driver? if not, which should I go for?

Edited March 16, 2018 by John78

[RolandKol]

Thank you

[dyfiastro]

Hi

I have been using this focuser setup with fantastic results for sometime now.
One small thing I have never seemed to be able to get working however is for this to play nice with APT's autofocus
Has anyone used this setup with APT and managed to get the autofocus part working?
Any help or information would be great.

[John78]

On 3/21/2018 at 23:11, dyfiastro said:

Hi

I have been using this focuser setup with fantastic results for sometime now.
One small thing I have never seemed to be able to get working however is for this to play nice with APT's autofocus
Has anyone used this setup with APT and managed to get the autofocus part working?
Any help or information would be great.

What part isn't working for you?  I had it "working" in APT with a 1000D Canon, in that APT was taking pictures and automatically adjusting the focuser - but what it decided was best focus wasn't great.  The Bahtinov tool I found to be very good and you can press the buttons to move the focuser manually, but means you need to go to the mount to put the mask on/off.

[dyfiastro]

1 hour ago, John78 said:

What part isn't working for you?  I had it "working" in APT with a 1000D Canon, in that APT was taking pictures and automatically adjusting the focuser - but what it decided was best focus wasn't great.  The Bahtinov tool I found to be very good and you can press the buttons to move the focuser manually, but means you need to go to the mount to put the mask on/off.

Thanks for the reply.
Yes this is what I have been finding as well and indeed the issue I have been having.
I traditionally always use a Bahtinov mask but was trying to get the autofocus setup for a complete remote operation.
I am at this stage not sure if the culprit is APT or the focuser. When ever I attempt to use autofocus the focus always ends up being slightly off.
The only other option at present is to use the assisted focusing section and do it by manually. I would like it setup so that it can just refocus on the fly without any interaction.
 

[John78]

On 3/26/2018 at 14:13, dyfiastro said:

Thanks for the reply.
Yes this is what I have been finding as well and indeed the issue I have been having.
I traditionally always use a Bahtinov mask but was trying to get the autofocus setup for a complete remote operation.
I am at this stage not sure if the culprit is APT or the focuser. When ever I attempt to use autofocus the focus always ends up being slightly off.
The only other option at present is to use the assisted focusing section and do it by manually. I would like it setup so that it can just refocus on the fly without any interaction.
 

So I've been lead to believe the HFR technique used by SGP and Ekos is very good at getting the best focus - given that SGP is paid and Ekos is "free", I've gone the Kstars/INDI/Ekos route and I've got it all up and running on a RaspberryPi and been very very impressed, its really a 1 stop astrophotography shop, but its been cloudmageddon here for about a month - so no field testing yet - I did have a brief chance to test it indoors though an open window last night and can confirm it appears to work and autofocus to the best point of focus with no fuss.

The software monitors the incoming images so if the focus is drifiting it can be setup to stop and retrigger focusing, you can also schedule focusing whenever you like, time, temp, filter changes etc...

The only issuette I had is as far as I could see this focuser software doesn't work with Ekos so I had to re-flash my Arduino with a moonlite cloning sketch instead which is available on the indi forum.

Edited March 29, 2018 by John78

[edziller]

I know this is a thread from 4 years ago but I am doing your project and had problems when running the installer AFF2.Focuser.msi. The windows keep me telling that "Another installation is in progress. You must complete that installation before continuing this one" 

So I cant even install the driver and the program to control the focuser. Is there any other solution to that?

Looked in some replies but could not find a sollution to my case.

I tryed to end installation processes but didn

[edziller]

But didn't worked.

Sorry, I've pressed something that posted before I ended LOL!

 

Appreciate your help

[SnakeyJ]

@tekkydave - Dave does your 2.5 version include an x64 bit driver?

I upgraded my version of Firecapture to try the x64, but it doesn't play with the original ascom driver.   Not the end of the world as I can still use the AAF2 software to control the focusing outside of FC.

I've been using the original version of this project for the last four years, but will update and build a new version now for new monster planetary setup!

 

[tekkydave]

I think it's 32-bit but it should work fine on a 64-bit o/s. 

[SnakeyJ]

33 minutes ago, tekkydave said:

I think it's 32-bit but it should work fine on a 64-bit o/s. 

It does and the AAF2 is working fine, but Firecapture x64 won't play with it and gives an error about non compliant 32 bit drivers!    I'll try and screenshot the error tonight, but I still have the option of using AAF2 as a separate program or going back to x86 version of FC, so not a show stopper but wanted to check.

 

To be honest I'm not sure if there is any real advantage in using the x64 version of firecapture, as USB3 and i/o to SSD are probably the main bottlenecks  affecting frame rates at larger ROI's.

[tekkydave]

I suspect the problem may be down to FC refusing to use non-64bit drivers. I'm not really supporting this project anymore and I dont have the tools to make changes to the driver which requires windoze ( I only use Linux these days).

If you get hold of the latest free copy of MS Visual Studio you can recompile the driver easily for your platform. All the source code is on the AAF Sourceforge site.

Hope that helps.

Dave

[Gina]

I too am virtually Linux only and use KStars/Ekos/INDI together with my own hardware for remote and auto-focussing using the Raspberry Pi 3 instead of a laptop in the observatory, right on the pier top.  I'm currently adding to my tutorial blog - Setting up a Raspberry Pi for Astro Imaging and Control - Ubuntu Mate

[SnakeyJ]

18 minutes ago, tekkydave said:

I suspect the problem may be down to FC refusing to use non-64bit drivers. I'm not really supporting this project anymore and I dont have the tools to make changes to the driver which requires windoze ( I only use Linux these days).

If you get hold of the latest free copy of MS Visual Studio you can recompile the driver easily for your platform. All the source code is on the AAF Sourceforge site.

Hope that helps.

Dave

Thanks Dave - I didn't realise the source code was available for this - I might just have a pop at this as the focuser works beautifully and it's far more satisfying to DIY it (rather than forking out £300+ to Baader/Moonlight/FT).   

[SnakeyJ]

1 minute ago, Gina said:

I too am virtually Linux only and use KStars/Ekos/INDI together with my own hardware for remote and auto-focussing using the Raspberry Pi 3 instead of a laptop in the observatory, right on the pier top.  I'm currently adding to my tutorial blog - Setting up a Raspberry Pi for Astro Imaging and Control - Ubuntu Mate

 

Thanks Gina - I would love to do this and probably makes a lots of sense for deepsky, but I don't think the Pi3 would provide enough grunt (USB3 connectivity or the i/o to SSD) for high speed planetary imaging.     However I could run all of this on Linux on the laptop and firecapture will run natively on Linux (limited support for cameras, but does cover the ZWO/QHY).    I will have a read through your blogg as I do have an idle RP3+ available and was thinking of using this to control my dome.