Thank you for all the updates. I just want to check if I am understanding something wrong or if there is a potential problem wih backlash under the Ascom drivers. In all my test with the Windows App (2396) I could not find anything that did not make sense to me. Backlash works perfect in my opinion.
Under Ascom if I do +500-500, +100-100,+10-10,+1-1 then backlash works perfect. However when I Move to 0 (home) and then move to 3000 backlash seems to be wrong/ignored. Am I misunderstanding the "move" function under Ascom or is there a problem?
If I do the same test under the Window App "Go Home" then "Goto Possition" 3000 then backlash works perfect.
Am I misunderstaning Move or is there a potential bug? Settings are the same for Windows App and Ascom driver.
Kind regards
Johan
ps Forgot to mention Ascom 259
Last edit: Johan Landman 2018-04-28
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi Johan
Backlash is actually implemented in the firmware and not the ascom driver.
The Move function in ASCOM works exactly the same (same firmware call to the focuser) as the Windows app, so as such there would be no difference - both using exactly the same methods. The firmware keeps track of what direction the focuser is moving and if that has changed thus deciding when to apply backlash.
Ascom does not have a HOME method, only a Move method, so it is only using one call to the focuser (a move method call). The Windows app provides both HOME and MOVE, and uses two different methods (move and home) to implement each.
I can see an issue with the HOME call in the firmware. That would indicate that the issue should really be happening with the Windows App and not Ascom. There is a problem with the Home code in that it does not flag direction so yes, there will be a problem with backlash in this instance but should not be happening with ascom because ascom is not issuing this call but using a move instead
What version firmware are you using (filename) - I will send u something to test.
Regards
Robert
Last edit: brownrb 2018-04-28
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I was using your Ascom Testing Program to do the tests.
Background
I use SGPro for focussing. It has been complaining about inaccurate HFR's after a focussing session (apparently a backlash issue) so I am just rechecking everything. I have changed the flexi coupler between the focusser and stepper motor to a solid one. Also redoing all grub screws etc. Now I am testing backlash with full camera, OAG and filterwheel load at latitude angle.
The test that is not doing what I think it shoud be doing
I use a digital dial indicater. First move to focusser step 0 then move to step 3000. Then I Zero the dial indicator, Move to step 0 and back to step 3000. According to me the dial indicator should now be back at Zero. This is happening as explained when I use the Windows App, Not when I do it through the Ascom tester program.
The arduino file is called Focuserv268_DRV8825_HW203_OLED
Regards
Johan
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I cannonot see anything in the ascom driver that would account for it, except that it uses Move command to do a home whereas the windows app (if you pres home key) uses a special Home command. The move command in firmware uses backlash and applies it when moving in (if conditions are met), but the special home command does not apply backlash at all when going home (but it should have).
I attach trial firmware 270 for you to test where the special home command in firmware has been changed to be the same as the move command. Can you please redo your tests to confirm?
What sort of indication are you getting on the dial indicator? What is your step size and how was it calculated? What is your step mode? I understand you are seeing correct behaviour in windows but not ascom (because ascom is using a move to zero and windows is using a home instead). But info does helps.
In doing the tests all conditions have to be equal. Power off is important.
Turn on controller
Run ascom app
move to 0
move to 3000
set dial indicator to 0
move to 0
move to 3000
record dial indicator
disconnect, close ascom app
wait 30s
power off controller
wait 10s
power on controller
Run windows app
move to 0
move to 3000
set dial indicator to 0
move to 0
move to 3000
record dial indicator
disconnect, close windows app
wait 30s
power off controller
Hi Johan
It would appear to me that since backlash was being applied in the ASCOM test when you went from 3000 to home, but in the Windows App was not being applied, that you have minimal backlash when changing from OUT to IN and the backlash setting for IN maybe too high?
Regards
Robert
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I will give answer to questions now. Will do the tests as per your method a bit later.
Step Size - Calculation
Full rotation of knob measured and checked is 29mm
Gear ratio for stepper moter is 26.86:1 and steps are 200 (https://www.omc-stepperonline.com/geared-stepper-motor/nema-17-stepper-motor-bipolar-l48mm-w-gear-raio-271-planetary-gearbox-17hs19-1684s-pg27.html?search=27%3A1)
So Step size is(29000/ (200 x 26.85) = 5.4 micron
Again this is confirmed with my dial indicator. I atually measured that 1 step = 5.4 micron. I will add fotos later. I can repeat this test many times (+1,-1) with 5.4 micron movement every time.
Step Mode = Full Step - No reason to go any less
There is a possibility that my backlash settings could be wrong and I will redo all today with the Arduino 270 Version.
On a side note. If you can add the mssing functions e.g "set to" in the Ascom Tester there would be no need to maintain the Standalone Windows App. It may make it a bit easier to only maintain a single Application
Again thank you for all the help.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I cannot add "set to" to ASCOM to set the position without a move - this feature does not exist in ASCOM. Only a get position and a move exists in ASCOM
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Ok great news. It seems to be working 100% Thank you so much for the help.
I have managed to get the focusser back to the same position only using the Ascom testing app at least 30 times in a row. This includes swithing power off and pulling from USB cable in between. The only thing I have noticed is that sometimes my current position is not saved between powercuts but I pressume this is when I did not give enough time for the EPROM to be updated? In this instance I still need to use the Windows App to reset the position. As per my earlier writing. It would be great if all the functionality could be in the ASCOM app then there is no need to maintain two apps. Just pushing my luck here.
Again thank you and regards
Johan
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
yes, also when connecting. To prevent the reboot you can try the power on reset circuit - perhaps a better name for the circuit would be "Prevent reboot circuit"
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi Robert,
Thank you for all the updates. I just want to check if I am understanding something wrong or if there is a potential problem wih backlash under the Ascom drivers. In all my test with the Windows App (2396) I could not find anything that did not make sense to me. Backlash works perfect in my opinion.
Under Ascom if I do +500-500, +100-100,+10-10,+1-1 then backlash works perfect. However when I Move to 0 (home) and then move to 3000 backlash seems to be wrong/ignored. Am I misunderstanding the "move" function under Ascom or is there a problem?
If I do the same test under the Window App "Go Home" then "Goto Possition" 3000 then backlash works perfect.
Am I misunderstaning Move or is there a potential bug? Settings are the same for Windows App and Ascom driver.
Kind regards
Johan
ps Forgot to mention Ascom 259
Last edit: Johan Landman 2018-04-28
Hi Johan
Backlash is actually implemented in the firmware and not the ascom driver.
The Move function in ASCOM works exactly the same (same firmware call to the focuser) as the Windows app, so as such there would be no difference - both using exactly the same methods. The firmware keeps track of what direction the focuser is moving and if that has changed thus deciding when to apply backlash.
Ascom does not have a HOME method, only a Move method, so it is only using one call to the focuser (a move method call). The Windows app provides both HOME and MOVE, and uses two different methods (move and home) to implement each.
I can see an issue with the HOME call in the firmware. That would indicate that the issue should really be happening with the Windows App and not Ascom. There is a problem with the Home code in that it does not flag direction so yes, there will be a problem with backlash in this instance but should not be happening with ascom because ascom is not issuing this call but using a move instead
What version firmware are you using (filename) - I will send u something to test.
Regards
Robert
Last edit: brownrb 2018-04-28
BTW what were you using as an ASCOM client?
Hi Robert,
I was using your Ascom Testing Program to do the tests.
Background
I use SGPro for focussing. It has been complaining about inaccurate HFR's after a focussing session (apparently a backlash issue) so I am just rechecking everything. I have changed the flexi coupler between the focusser and stepper motor to a solid one. Also redoing all grub screws etc. Now I am testing backlash with full camera, OAG and filterwheel load at latitude angle.
The test that is not doing what I think it shoud be doing
I use a digital dial indicater. First move to focusser step 0 then move to step 3000. Then I Zero the dial indicator, Move to step 0 and back to step 3000. According to me the dial indicator should now be back at Zero. This is happening as explained when I use the Windows App, Not when I do it through the Ascom tester program.
The arduino file is called Focuserv268_DRV8825_HW203_OLED
Regards
Johan
Hi Johan
I cannonot see anything in the ascom driver that would account for it, except that it uses Move command to do a home whereas the windows app (if you pres home key) uses a special Home command. The move command in firmware uses backlash and applies it when moving in (if conditions are met), but the special home command does not apply backlash at all when going home (but it should have).
I attach trial firmware 270 for you to test where the special home command in firmware has been changed to be the same as the move command. Can you please redo your tests to confirm?
What sort of indication are you getting on the dial indicator? What is your step size and how was it calculated? What is your step mode? I understand you are seeing correct behaviour in windows but not ascom (because ascom is using a move to zero and windows is using a home instead). But info does helps.
In doing the tests all conditions have to be equal. Power off is important.
Turn on controller
Run ascom app
move to 0
move to 3000
set dial indicator to 0
move to 0
move to 3000
record dial indicator
disconnect, close ascom app
wait 30s
power off controller
wait 10s
power on controller
Run windows app
move to 0
move to 3000
set dial indicator to 0
move to 0
move to 3000
record dial indicator
disconnect, close windows app
wait 30s
power off controller
Regards
Robert
Hi Johan
It would appear to me that since backlash was being applied in the ASCOM test when you went from 3000 to home, but in the Windows App was not being applied, that you have minimal backlash when changing from OUT to IN and the backlash setting for IN maybe too high?
Regards
Robert
Hi Robert,
I will give answer to questions now. Will do the tests as per your method a bit later.
Step Size - Calculation
Full rotation of knob measured and checked is 29mm
Gear ratio for stepper moter is 26.86:1 and steps are 200 (https://www.omc-stepperonline.com/geared-stepper-motor/nema-17-stepper-motor-bipolar-l48mm-w-gear-raio-271-planetary-gearbox-17hs19-1684s-pg27.html?search=27%3A1)
So Step size is(29000/ (200 x 26.85) = 5.4 micron
Again this is confirmed with my dial indicator. I atually measured that 1 step = 5.4 micron. I will add fotos later. I can repeat this test many times (+1,-1) with 5.4 micron movement every time.
Step Mode = Full Step - No reason to go any less
There is a possibility that my backlash settings could be wrong and I will redo all today with the Arduino 270 Version.
On a side note. If you can add the mssing functions e.g "set to" in the Ascom Tester there would be no need to maintain the Standalone Windows App. It may make it a bit easier to only maintain a single Application
Again thank you for all the help.
I cannot add "set to" to ASCOM to set the position without a move - this feature does not exist in ASCOM. Only a get position and a move exists in ASCOM
Hi Robert,
Ok great news. It seems to be working 100% Thank you so much for the help.
I have managed to get the focusser back to the same position only using the Ascom testing app at least 30 times in a row. This includes swithing power off and pulling from USB cable in between. The only thing I have noticed is that sometimes my current position is not saved between powercuts but I pressume this is when I did not give enough time for the EPROM to be updated? In this instance I still need to use the Windows App to reset the position. As per my earlier writing. It would be great if all the functionality could be in the ASCOM app then there is no need to maintain two apps. Just pushing my luck here.
Again thank you and regards
Johan
Yes, it requires 30s to elapse before saving the current position
...Just something I noticed. When I disconnect from the focusser it appears to "reboot". Is this the correct behaviour?
yes, also when connecting. To prevent the reboot you can try the power on reset circuit - perhaps a better name for the circuit would be "Prevent reboot circuit"
Will the above help in not losing the current position?
yes
Thank you will impliment