When using the windows app (2.4.8.2) I can put a value in the Focuser Position box and click GOTO Position, it then resets the Position box back to whatever the previous value was without moving the focuser.
I have also tried NINA Auto focus and it connects fine then sends a move command to an absolute position, and just sits there doing nothing else.
I have a log output from ASCOM Conformance log and the NINA trace log, both attached.
The trace log shows that the driver is returning NULL for cmd =5, which I guess might be the issue?
The NINA trace was from a completely powered up focuser, 12v applied, whereas the conformance was run in the house with just usb connected to the focuser, I have just noticed the max steps is now shown in red (I am red green colour defective, so this may have always been the case but I have just noticed it).
I realised I had not got the latest Windows app, my problem in reading file names and comparing against installed version, now using 2.4.8.4, which is giving an error on GOTO Position
myFP2
Timeout Exception in ReceiveResponse: No response from controller
I have completely removed the ascom driver and reinstalled as per your instructions in another thread, but still no joy.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The current ascom app 278 has been around since april 2021.
Windows app 2_4_8_2 and 3 I believe was stuffed, affecting goto, so that was recently replaced.
2_4_8_2 + was a major update which needed to uninstall the previous version first before running setup.
21:04:21.780 CommandString :0529007#
21:04:21.780 CS: SET NEW POSITION cmd= 05
21:04:21.780 CS: Null value returned
This is correct, 05 is a command that returns nothing, there is not expected to be a reply, I would be worried it it did. For all commands that do not send a reply (like :05) the null response message informs me that the command was sent correctly, and there was no response (expected behavior . Maybe I should have called it something different.
Here is the problem
21:04:21.780 CommandString :0529007#
21:04:21.780 CS: SET NEW POSITION cmd= 05
21:04:21.780 CS: Null value returned
21:04:21.796 Move Force an isMoving call by resetting time stamp
21:04:21.796 IsMoving Get Check for time of last call
21:04:21.796 IsMoving Times up - query controller for status
21:04:21.796 CommandString Clearing serial port buffers
21:04:21.796 CommandString :01#
21:04:21.796 CommandString cmd: 01 21:04:21.827 CommandString recbuf: 0
21:04:21.827 CS: Raw recbuf = 0
21:04:21.827 CS: Returned recbuf =
21:04:21.843 IsMoving Ismoving = 0
first, the 05 command was fine
After sending the command, a request was made for ismoving
and we would expect it to be 1, moving, but the return was 0 - not moving
which is wrong of course.
I think that this is caused by an issue with the firmware.
I would suggest (after the below stuff about reinstalling) to start a test using the firmware 312) and latest window app - and verify that goto works Then I would suggest follow that up with the same test on the ascom driver 278
I suggest this
Recommended method to update.
1. Run ClearEEPROM on the controller
2. Program the controller with 312
The firmware uses eeprom on the nano to store settings. I think that what happened is the new 312 is accessing some older data in eeprom and it is causing an issue. To eliminate that requires running cleareeprom (in the test folder after extracting the firmware zip file)
I see you attached a conform. I know that a lot of things changed under the current release from 6.4 onwards. Obviously the driver can conform tested under the old release, but it looks like the later conform is flagging something that the previous confirm did not. I looked at the file and i do not think it will occur as all negative moves are always trapped by the firmware. The fact that a user application might send -1000 to the ascom driver does not mean that is what the focuser will do. The older conform in ascom platform 6.4 did not do that test.
There is in fact error checking in the 278 ascom driver specifically for this. But I see that the latest conform requires an exception instead. So I just coded that and I attach v279 of ascom driver and conform report.
By way of explanation, the windows app and the ascom driver use a special config file of settings that are saved and restored. This allows the app or ascom driverform to remember the state of things.
With a major update that means the settings file format was changed, and if the new app/driver is installed over the top of the last one, then the settings file is not overwritten and the app/driver ends up accessing the wrong things or missing things or replace some state/setting on the form using the wrong values.
Hi Robert, thanks for the very detailed response, and you are correct about me not clearing the eeprom first. I must admit that I was not sure how to clear the eeprom, whether it was done in the Arduino environment as a tool or from your windows app when you write to the eeprom. I now see it was neither, and did run the Arduino project to clear the eeprom, and saw that the serial monitor confirmed it had run.
I then reloaded the 312 firmware and ascom driver 279(uninstalled 278 first) I then tried a goto with 2.4.8,4, and got exactly the same response in terms of an error. I then uniinstalled 2.4.8.4 and reinstalled it, with same result:
myFP2
Timeout Exception in ReceiveResponse: No response from controller.
I then tried the myfocuser Ascom app, and pretty much the same, move says it is doing it but the focuser is not moving , and when GET position is clicked it returns the original value
I ran conformance again, still seeing two errors.
I make the following changes in the config file, to match my hardware
I have changed my config , so power detect is not enabled, and the goto nearly works! The focuser does move, but still get a timeout error in the windows app , same as before.
The ascom app does work fine though, and this is what i was after.
So it looks like it is related to the pwrdetect being enabled?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I have just done the conformance again, and no errors. or warnings!
The thing that changed is I noted your comment about the settings for the focuser being saved different for ascom and windows app, and it seems ascom settings default to reverse direction, so I unticked this and the conformance passed. With hind sight, the errors did point to this.
Recap on actual issues,
1. It seems that I had not cleared the EEProm, using the clearEeprom sketch found in the test folder of the extracted firmware.
2. Windows app still gets timeout issue on a GOTO.
I have not tried turning pwrdetect back on, as I am actually in the process of packing my kit for an astro camp at Kelling Heath, Norfolk, UK., and I don't want to potentially break it again. I will be back in a week if you want me to check anything. That being said, weather is abysmal here, so if it is raining next week, I could continue with some more testing if required.
Your help is very much appreciated, thank you.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I would need a windows log file to track that down.
I had it running here going about 12000 steps back and forth and never got an error.
So if you have a log of the windows app when it timed out that would be great
If you do not have the extra hardware to handle power detect and then enabled it in the firmware then the motor will not move.
Reverse direction should not affect anything except the direction in which the focus motor rotates. The acom driver and windows app do nothing with reverse direction - it is all handled internally by the firmware.
I say pack up your kit, to tempt fate with another change is not something either of us should attempt.
Best wishes for the camp
Regards
Robert
Last edit: brownrb 2021-10-02
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
When using the windows app (2.4.8.2) I can put a value in the Focuser Position box and click GOTO Position, it then resets the Position box back to whatever the previous value was without moving the focuser.
I have also tried NINA Auto focus and it connects fine then sends a move command to an absolute position, and just sits there doing nothing else.
I have a log output from ASCOM Conformance log and the NINA trace log, both attached.
The trace log shows that the driver is returning NULL for cmd =5, which I guess might be the issue?
The NINA trace was from a completely powered up focuser, 12v applied, whereas the conformance was run in the house with just usb connected to the focuser, I have just noticed the max steps is now shown in red (I am red green colour defective, so this may have always been the case but I have just noticed it).
Last edit: Alan Townshend 2021-10-01
I realised I had not got the latest Windows app, my problem in reading file names and comparing against installed version, now using 2.4.8.4, which is giving an error on GOTO Position
myFP2
Timeout Exception in ReceiveResponse: No response from controller
I have completely removed the ascom driver and reinstalled as per your instructions in another thread, but still no joy.
Hi Alan
Nice to hear from you.
The current ascom app 278 has been around since april 2021.
Windows app 2_4_8_2 and 3 I believe was stuffed, affecting goto, so that was recently replaced.
2_4_8_2 + was a major update which needed to uninstall the previous version first before running setup.
21:04:21.780 CommandString :0529007#
21:04:21.780 CS: SET NEW POSITION cmd= 05
21:04:21.780 CS: Null value returned
This is correct, 05 is a command that returns nothing, there is not expected to be a reply, I would be worried it it did. For all commands that do not send a reply (like :05) the null response message informs me that the command was sent correctly, and there was no response (expected behavior . Maybe I should have called it something different.
Here is the problem
21:04:21.780 CommandString :0529007#
21:04:21.780 CS: SET NEW POSITION cmd= 05
21:04:21.780 CS: Null value returned
21:04:21.796 Move Force an isMoving call by resetting time stamp
21:04:21.796 IsMoving Get Check for time of last call
21:04:21.796 IsMoving Times up - query controller for status
21:04:21.796 CommandString Clearing serial port buffers
21:04:21.796 CommandString :01#
21:04:21.796 CommandString cmd: 01
21:04:21.827 CommandString recbuf: 0
21:04:21.827 CS: Raw recbuf = 0
21:04:21.827 CS: Returned recbuf =
21:04:21.843 IsMoving Ismoving = 0
first, the 05 command was fine
After sending the command, a request was made for ismoving
and we would expect it to be 1, moving, but the return was 0 - not moving
which is wrong of course.
I think that this is caused by an issue with the firmware.
I would suggest (after the below stuff about reinstalling) to start a test using the firmware 312) and latest window app - and verify that goto works Then I would suggest follow that up with the same test on the ascom driver 278
I suggest this
Recommended method to update.
1. Run ClearEEPROM on the controller
2. Program the controller with 312
The firmware uses eeprom on the nano to store settings. I think that what happened is the new 312 is accessing some older data in eeprom and it is causing an issue. To eliminate that requires running cleareeprom (in the test folder after extracting the firmware zip file)
I see you attached a conform. I know that a lot of things changed under the current release from 6.4 onwards. Obviously the driver can conform tested under the old release, but it looks like the later conform is flagging something that the previous confirm did not. I looked at the file and i do not think it will occur as all negative moves are always trapped by the firmware. The fact that a user application might send -1000 to the ascom driver does not mean that is what the focuser will do. The older conform in ascom platform 6.4 did not do that test.
There is in fact error checking in the 278 ascom driver specifically for this. But I see that the latest conform requires an exception instead. So I just coded that and I attach v279 of ascom driver and conform report.
By way of explanation, the windows app and the ascom driver use a special config file of settings that are saved and restored. This allows the app or ascom driverform to remember the state of things.
With a major update that means the settings file format was changed, and if the new app/driver is installed over the top of the last one, then the settings file is not overwritten and the app/driver ends up accessing the wrong things or missing things or replace some state/setting on the form using the wrong values.
Last edit: brownrb 2021-10-02
Hi Robert, thanks for the very detailed response, and you are correct about me not clearing the eeprom first. I must admit that I was not sure how to clear the eeprom, whether it was done in the Arduino environment as a tool or from your windows app when you write to the eeprom. I now see it was neither, and did run the Arduino project to clear the eeprom, and saw that the serial monitor confirmed it had run.
I then reloaded the 312 firmware and ascom driver 279(uninstalled 278 first) I then tried a goto with 2.4.8,4, and got exactly the same response in terms of an error. I then uniinstalled 2.4.8.4 and reinstalled it, with same result:
I then tried the myfocuser Ascom app, and pretty much the same, move says it is doing it but the focuser is not moving , and when GET position is clicked it returns the original value
I ran conformance again, still seeing two errors.
I make the following changes in the config file, to match my hardware
define STEPPERPWRDETECT 1
define TEMPERATUREPROBE 1
define LCDDISPLAY 1
define BUZZER 1
define SHOWBOOTMSGS 1
//#define LCD1602 1 // 16 character, 2 lines
define LCD2004 3 // 20 character, 4 lines
My bad. I stuffed up.
So anyhows, changed the way that the app now handles moves. I just did a 12000 step move without issue. No more timeouts
So I will post the update now.
// 2.4.8.6
// Fix for timeout issues
// Implemented timer to monitor and handle moving positions
Pic shows moving from 2000 - 17000
Note the new status indicator Idle - Changes to Moving when a move occurs
https://sourceforge.net/projects/arduinoascomfocuserpro2diy/files/WINDOWS/MainApp/
Apologies to every one re my stuff up.
the ascom 279 passesthe new conform.
https://sourceforge.net/projects/arduinoascomfocuserpro2diy/files/ASCOM%20DRIVERS/
I just performed a move from 17000 down to 222 without issue. Using the 279 ascom driver. And a similar test in the Windows app 2486
I will do the ascom1 driver after a sleep (3am here) and update the pdf later in the day (my time)
Regards
Robert
I have changed my config , so power detect is not enabled, and the goto nearly works! The focuser does move, but still get a timeout error in the windows app , same as before.
The ascom app does work fine though, and this is what i was after.
So it looks like it is related to the pwrdetect being enabled?
I have just done the conformance again, and no errors. or warnings!
The thing that changed is I noted your comment about the settings for the focuser being saved different for ascom and windows app, and it seems ascom settings default to reverse direction, so I unticked this and the conformance passed. With hind sight, the errors did point to this.
Recap on actual issues,
1. It seems that I had not cleared the EEProm, using the clearEeprom sketch found in the test folder of the extracted firmware.
2. Windows app still gets timeout issue on a GOTO.
I have not tried turning pwrdetect back on, as I am actually in the process of packing my kit for an astro camp at Kelling Heath, Norfolk, UK., and I don't want to potentially break it again. I will be back in a week if you want me to check anything. That being said, weather is abysmal here, so if it is raining next week, I could continue with some more testing if required.
Your help is very much appreciated, thank you.
I would need a windows log file to track that down.
I had it running here going about 12000 steps back and forth and never got an error.
So if you have a log of the windows app when it timed out that would be great
If you do not have the extra hardware to handle power detect and then enabled it in the firmware then the motor will not move.
Reverse direction should not affect anything except the direction in which the focus motor rotates. The acom driver and windows app do nothing with reverse direction - it is all handled internally by the firmware.
I say pack up your kit, to tempt fate with another change is not something either of us should attempt.
Best wishes for the camp
Regards
Robert
Last edit: brownrb 2021-10-02
New ascom drivers have been uploaded, and they do work with NINA