I have struggled for some time with the driver which ends up disconnecting after a while. I changed the Arduino Uno last summer but the focuser keeps disconnecting in NINA. I had no issue for over a year with the focuser before (New with NINA beta version?). It is difficult for me to troubleshoot the equipment because the telescope is in Chile (9K km away) but it is the only component that disconnects and everything else goes through the same hub and wire to the pc. All I have to do is force the reconnection through NINA. Do we have access to a log via the driver to dig into the source of the problem?
I have attached a NINA log reporting the problem from last night.
There have been reports of issues with the focuser that happened after a NINA update.
I uploaded a new ASCOM driver a few days ago
myFP2ASCOMSetup282
which has of course been tested against Confirm and passed
In the ascom setup form, where you specify the port and speed etc, there is a checkbox
called Trace On. You need to enable the log trace by checking this box.
The log file will be stored in the users Documents\ASCOM\Logs folder.
I am running NINA 1.10 HF3
my recommendations
1. Update to ascom driver 282
2. Enable Trace On in the driver
3. In Nina, Options, set the Log Level to Trace
If you still have issues then I need the ASCOM driver trace log and the Nina log files
Regards
Robert
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
So there was a "The port is closed" exception after a while.
06:50:08.344 Position get Position
06:50:08.344 getresponse() Clearing serial port buffers
06:50:08.344 getresponse() Clearing serial port buffers: OK
06:50:08.344 send sending: :00#
06:50:08.344 Send sent: OK
06:50:08.344 getresponse() rec'd raw data: P6176#
06:50:08.344 getresponse returning: 6176
06:50:08.344 Position reply: 6176
06:50:08.344 Position curr: 6176
06:50:08.344 Connected get: True
06:50:08.344 temperature.get return cache: 20
06:50:08.344 Connected get: True
06:50:08.344 IsMoving.get query controller for ismoving
06:50:08.344 getresponse() Clearing serial port buffers
06:50:08.344 getresponse() Clearing serial port buffers: OK
06:50:08.344 send sending: :01#
06:50:08.360 Send sent: OK
06:50:08.360 getresponse() rec'd raw data: I00#
06:50:08.360 getresponse returning: 00
06:50:08.360 IsMoving.get response = 00
06:50:08.360 IsMoving.get Ismoving = 0
06:50:08.360 Connected get: True
06:50:08.360 TCAvailable.get Query controller for tempcompavailable status
06:50:08.360 getresponse() Clearing serial port buffers
06:50:08.360 getresponse() Clearing serial port buffers: OK
06:50:08.360 send sending: :25#
06:50:08.360 Send sent: OK
06:50:08.376 getresponse() rec'd raw data: A1#
06:50:08.376 getresponse returning: 1
06:50:08.376 TCAvailable.get focuser reply = 1
06:50:08.376 Connected get: True
06:50:08.376 TempComp.get Query controller for TempComp state
06:50:08.376 getresponse() Clearing serial port buffers
06:50:08.376 getresponse() Clearing serial port buffers: OK
06:50:08.376 send sending: :24#
06:50:08.376 Send sent: OK
06:50:08.391 getresponse() rec'd raw data: 10#
06:50:08.391 getresponse returning: 0
06:50:08.391 TempComp.get focuser reply = 0
06:50:13.345 Connected get: True
06:50:13.345 Connected get: True
06:50:13.345 Position get Position
06:50:13.345 getresponse() Clearing serial port buffers
06:50:13.345 getresponse() Clearing serial port buffers: OK
06:50:13.345 send sending: :00#
06:50:13.345 Send err: Exception: System.InvalidOperationException: The port is closed.[0D][0A] at ASCOM.Utilities.Serial.Transmit(String Data) in C:\ASCOM Build\Export\ASCOM.Utilities\ASCOM.Utilities\Serial.vb:line 1392[0D][0A] at ASCOM.myFocuser2ASCOM.Focuser.getresponse(String cmd)
06:50:13.345 Position err: Null reply
06:50:13.470 Connected get: False
06:50:13.470 Connected True
06:50:13.470 IsConnected Get True
06:50:13.470 Connected already connected
06:50:13.470 Connected get: False
06:50:13.470 Connected False
06:50:13.470 IsConnected Get True
06:50:13.470 Connected request to disconnect
06:50:13.470 Connected Disconnecting from port COM4
Last edit: Patrick Dufour 2021-12-31
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
is there anything about the config of the controller I should know about?
Firmware version for the controller?
Are you using bluetooth?
Did you recently reprogram the controller?
//--------------------------------------------------
// Please follow these steps
//--------------------------------------------------
In installing the ascom driver 282.
Please use control panel to remove the ascom driver
Then go to C:\Program Files (x86)\Common Files\ASCOM\Focuser
If there is a ASCOM.myFocuser2ASCOM.Focuser.dll file there then delete it
Then install ascom driver 282
On the controller,
look in the tests folder for cleareeprom
program the controller with this cleareeprom
then
reprogram the controller with the latest firmware 312
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
NINA latest beta v 022
Firmware version is myFP2.A4998HW203, 280 no bluetooth. I have two controlers on site both flashed about two years ago with the same firmware. I had the zero switch activated only, everything else deactivated.
Hope I don't have to reprogram it as I will have to ask some one for help. The system is in Chile, I live in Canada. Everything was working fine for over a year and changing the controller didn't help.
That explains a lot - firmware 280
A lot of change has happened since then, including support for NINA which started around firmware 282 and higher, as well as fixes for home position switch code.
You need to upgrade to the latest firmware 312.
Options:
Try NINA 1.10 HF3
In the meantime thanks for the logs I will have a look over them
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Ok I'm going to schedule a troubleshooting session with the site owner to update the firmware. I'm pretty sur I need a hand to perform this. Working with version 1.11 of NINA since the very beginning when it was available as a nightly version, I am not even sure how to use 1.10 anymore lol. Nah I can't live without the new sequencer! ;-) Will let you know!
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
That is probably a good reason to consider the myfp2esp wifi controllers.
You can update the firmware and config over the Internet.... all from anywhere, anytime..
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I was able to update the board remotely to the latest version but I had to deactivated the #define STEPPERPWRDETECT as it needs to cycle the board power Off-On first in order to detect it and I had no one available to do so. Could be done later thought as the focuser is working anyway.
However all of this didn't help with my deconnexion issue. I can let the myFocuser windows app running all day long refreshing the position and I get no error in the log. Here the lasted ASCOM log form last night session.
I'm blessed to have a very stable OTA in Chile so I can run autofocus at the beginning and even if the focuser is not available the sequence can still generate good images of Leonard comet.
I do not see anything in the logs that indicate an issue with the firmware.
In both cases, there is an unexplained disconnect associated with get position, where the
serial port returns a disconnected state to the ascom driver.
What caused that is difficult to identify. there is nothing in the log to indicate the cause of
the lost connection.
The only indicator is that the driver wanted to send a command but the serial connection had been dropped (not by the driver, by the OS).
What the cause of the dropped connection ws - there is not a clue. I believe at this point in time that the OS dropped the serial connection, not the driver. That is based on the fact that if it was the ascom driver, there would have been logged messages about that and the cause. In this instance however, the driver sent to send a command and found the port was no long open, and the only thing that can drop the port connection is the OS.
If there was a consistent repeatable cause it might be easier to find, but in this case, the exact same code is executing over and over and over without issue.
If it was an issue in the firmware then I would have expected that it would have gone boom from the start, not after hours of operation.
On the first log it went 6hrs + before it went boom.
On the second log time was around 1hr+ before it went boom. One might be tempted to think it had to do with the get position call, but then if there was an issue, it would happen more often and much quicker.
It might be a cable issue.
It might be a heat issue (do you have any means of identifying the temperature at the remote location) or a cold issue
It might be the power settings on the computer (the power plan, advanced settings, USB settings, usb selective speed setting - disable
The code executes perfectly, over and over again, in repeated cycles till it goes boom.
Looking at this objectively, you had a working system?
ascom driver, firmware 280, with NINA.
When did the trouble start?
Was this because the ascom driver was updated, or was it an update to NINA?
There had to be something to cause the issue.
I am running firmware 312 with NINA 1.10 as stated earlier, with no issues.
What version of the ascom driver were you using before?
I have a modified ascom driver you might try, attached. Remove the existing ascom driver using control panel first, before installing this one.
regards
Robert
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I do understand it is not an easy one to solve. I have been programming microcontrollers for years. It doesn't seem to happen when using the windows program but I never use other than when the scope is parked. Could still be a problem with a USB cable or bad connection even if we made a few checks and already changed the cable and use another usb port.
Ambient temperature at the location can't really explain this kind of problem. Actual temperature on site at night must be around 12-16 Celsius and very dry.
For the moment, one thing I would love to try is some mean of reconnexion retries when this error occur before turning off the ASCOM driver.
Does v283 do something like this?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Using a USB recorder, I discovered that the CEM120 USB 2 hub or internal connection was the problem. But since it reconnects a few seconds later I never saw this condition pass while I was using the system live. The guiding camera is also on this hub but PHD reconnects automatically so I had not made the link yet.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I have struggled for some time with the driver which ends up disconnecting after a while. I changed the Arduino Uno last summer but the focuser keeps disconnecting in NINA. I had no issue for over a year with the focuser before (New with NINA beta version?). It is difficult for me to troubleshoot the equipment because the telescope is in Chile (9K km away) but it is the only component that disconnects and everything else goes through the same hub and wire to the pc. All I have to do is force the reconnection through NINA. Do we have access to a log via the driver to dig into the source of the problem?
I have attached a NINA log reporting the problem from last night.
cheers,
Patrick Dufour
There have been reports of issues with the focuser that happened after a NINA update.
I uploaded a new ASCOM driver a few days ago
myFP2ASCOMSetup282
which has of course been tested against Confirm and passed
In the ascom setup form, where you specify the port and speed etc, there is a checkbox
called Trace On. You need to enable the log trace by checking this box.
The log file will be stored in the users Documents\ASCOM\Logs folder.
I am running NINA 1.10 HF3
my recommendations
1. Update to ascom driver 282
2. Enable Trace On in the driver
3. In Nina, Options, set the Log Level to Trace
If you still have issues then I need the ASCOM driver trace log and the Nina log files
Regards
Robert
Thank you Robert, I just have updated it and all trace mode are on now.
Will keep you informed!
regards,
Patrick
So there was a "The port is closed" exception after a while.
06:50:08.344 Position get Position
06:50:08.344 getresponse() Clearing serial port buffers
06:50:08.344 getresponse() Clearing serial port buffers: OK
06:50:08.344 send sending: :00#
06:50:08.344 Send sent: OK
06:50:08.344 getresponse() rec'd raw data: P6176#
06:50:08.344 getresponse returning: 6176
06:50:08.344 Position reply: 6176
06:50:08.344 Position curr: 6176
06:50:08.344 Connected get: True
06:50:08.344 temperature.get return cache: 20
06:50:08.344 Connected get: True
06:50:08.344 IsMoving.get query controller for ismoving
06:50:08.344 getresponse() Clearing serial port buffers
06:50:08.344 getresponse() Clearing serial port buffers: OK
06:50:08.344 send sending: :01#
06:50:08.360 Send sent: OK
06:50:08.360 getresponse() rec'd raw data: I00#
06:50:08.360 getresponse returning: 00
06:50:08.360 IsMoving.get response = 00
06:50:08.360 IsMoving.get Ismoving = 0
06:50:08.360 Connected get: True
06:50:08.360 TCAvailable.get Query controller for tempcompavailable status
06:50:08.360 getresponse() Clearing serial port buffers
06:50:08.360 getresponse() Clearing serial port buffers: OK
06:50:08.360 send sending: :25#
06:50:08.360 Send sent: OK
06:50:08.376 getresponse() rec'd raw data: A1#
06:50:08.376 getresponse returning: 1
06:50:08.376 TCAvailable.get focuser reply = 1
06:50:08.376 Connected get: True
06:50:08.376 TempComp.get Query controller for TempComp state
06:50:08.376 getresponse() Clearing serial port buffers
06:50:08.376 getresponse() Clearing serial port buffers: OK
06:50:08.376 send sending: :24#
06:50:08.376 Send sent: OK
06:50:08.391 getresponse() rec'd raw data: 10#
06:50:08.391 getresponse returning: 0
06:50:08.391 TempComp.get focuser reply = 0
06:50:13.345 Connected get: True
06:50:13.345 Connected get: True
06:50:13.345 Position get Position
06:50:13.345 getresponse() Clearing serial port buffers
06:50:13.345 getresponse() Clearing serial port buffers: OK
06:50:13.345 send sending: :00#
06:50:13.345 Send err: Exception: System.InvalidOperationException: The port is closed.[0D][0A] at ASCOM.Utilities.Serial.Transmit(String Data) in C:\ASCOM Build\Export\ASCOM.Utilities\ASCOM.Utilities\Serial.vb:line 1392[0D][0A] at ASCOM.myFocuser2ASCOM.Focuser.getresponse(String cmd)
06:50:13.345 Position err: Null reply
06:50:13.470 Connected get: False
06:50:13.470 Connected True
06:50:13.470 IsConnected Get True
06:50:13.470 Connected already connected
06:50:13.470 Connected get: False
06:50:13.470 Connected False
06:50:13.470 IsConnected Get True
06:50:13.470 Connected request to disconnect
06:50:13.470 Connected Disconnecting from port COM4
Last edit: Patrick Dufour 2021-12-31
please send me the entire log.
Also the NINA log.
What version of NINA are you running?
is there anything about the config of the controller I should know about?
Firmware version for the controller?
Are you using bluetooth?
Did you recently reprogram the controller?
//--------------------------------------------------
// Please follow these steps
//--------------------------------------------------
In installing the ascom driver 282.
Please use control panel to remove the ascom driver
Then go to C:\Program Files (x86)\Common Files\ASCOM\Focuser
If there is a ASCOM.myFocuser2ASCOM.Focuser.dll file there then delete it
Then install ascom driver 282
On the controller,
look in the tests folder for cleareeprom
program the controller with this cleareeprom
then
reprogram the controller with the latest firmware 312
Hello Robert, ok just provided them.
NINA latest beta v 022
Firmware version is myFP2.A4998HW203, 280 no bluetooth. I have two controlers on site both flashed about two years ago with the same firmware. I had the zero switch activated only, everything else deactivated.
Hope I don't have to reprogram it as I will have to ask some one for help. The system is in Chile, I live in Canada. Everything was working fine for over a year and changing the controller didn't help.
That explains a lot - firmware 280
A lot of change has happened since then, including support for NINA which started around firmware 282 and higher, as well as fixes for home position switch code.
You need to upgrade to the latest firmware 312.
Options:
Try NINA 1.10 HF3
In the meantime thanks for the logs I will have a look over them
Ok I'm going to schedule a troubleshooting session with the site owner to update the firmware. I'm pretty sur I need a hand to perform this. Working with version 1.11 of NINA since the very beginning when it was available as a nightly version, I am not even sure how to use 1.10 anymore lol. Nah I can't live without the new sequencer! ;-) Will let you know!
That is probably a good reason to consider the myfp2esp wifi controllers.
You can update the firmware and config over the Internet.... all from anywhere, anytime..
Hello Robert,
I was able to update the board remotely to the latest version but I had to deactivated the #define STEPPERPWRDETECT as it needs to cycle the board power Off-On first in order to detect it and I had no one available to do so. Could be done later thought as the focuser is working anyway.
However all of this didn't help with my deconnexion issue. I can let the myFocuser windows app running all day long refreshing the position and I get no error in the log. Here the lasted ASCOM log form last night session.
I'm blessed to have a very stable OTA in Chile so I can run autofocus at the beginning and even if the focuser is not available the sequence can still generate good images of Leonard comet.
Hi Patrick
I do not see anything in the logs that indicate an issue with the firmware.
In both cases, there is an unexplained disconnect associated with get position, where the
serial port returns a disconnected state to the ascom driver.
What caused that is difficult to identify. there is nothing in the log to indicate the cause of
the lost connection.
The only indicator is that the driver wanted to send a command but the serial connection had been dropped (not by the driver, by the OS).
What the cause of the dropped connection ws - there is not a clue. I believe at this point in time that the OS dropped the serial connection, not the driver. That is based on the fact that if it was the ascom driver, there would have been logged messages about that and the cause. In this instance however, the driver sent to send a command and found the port was no long open, and the only thing that can drop the port connection is the OS.
If there was a consistent repeatable cause it might be easier to find, but in this case, the exact same code is executing over and over and over without issue.
If it was an issue in the firmware then I would have expected that it would have gone boom from the start, not after hours of operation.
On the first log it went 6hrs + before it went boom.
On the second log time was around 1hr+ before it went boom. One might be tempted to think it had to do with the get position call, but then if there was an issue, it would happen more often and much quicker.
It might be a cable issue.
It might be a heat issue (do you have any means of identifying the temperature at the remote location) or a cold issue
It might be the power settings on the computer (the power plan, advanced settings, USB settings, usb selective speed setting - disable
The code executes perfectly, over and over again, in repeated cycles till it goes boom.
Looking at this objectively, you had a working system?
ascom driver, firmware 280, with NINA.
When did the trouble start?
Was this because the ascom driver was updated, or was it an update to NINA?
There had to be something to cause the issue.
I am running firmware 312 with NINA 1.10 as stated earlier, with no issues.
What version of the ascom driver were you using before?
I have a modified ascom driver you might try, attached. Remove the existing ascom driver using control panel first, before installing this one.
regards
Robert
Hi Robert,
I do understand it is not an easy one to solve. I have been programming microcontrollers for years. It doesn't seem to happen when using the windows program but I never use other than when the scope is parked. Could still be a problem with a USB cable or bad connection even if we made a few checks and already changed the cable and use another usb port.
Ambient temperature at the location can't really explain this kind of problem. Actual temperature on site at night must be around 12-16 Celsius and very dry.
For the moment, one thing I would love to try is some mean of reconnexion retries when this error occur before turning off the ASCOM driver.
Does v283 do something like this?
Here is a test ascom driver, please run this and let me know the results
Uninstall the previous driver first before installing this update
R
this is ascom driver 285
use control panel to remove the old driver first before installing this version
Last edit: brownrb 2022-01-04
Here is the log from this version with several error exceptions.
Using a USB recorder, I discovered that the CEM120 USB 2 hub or internal connection was the problem. But since it reconnects a few seconds later I never saw this condition pass while I was using the system live. The guiding camera is also on this hub but PHD reconnects automatically so I had not made the link yet.
A bug in the myfp2drv8825 firmware was recently found - which causes an issue with NINA. It has been updated to myfp2drv8825-312-1