Just wanted to flag an issue I’m having using DarLight with NINA. It
connects fine, and the open and closing of the panel works great, however
toggling the light from the software seems to bring back the
CoverCalibrator.get_CoverState() issue. The error from the logs is:
2023-12-05T16:06:42.3781|INFO|FlatDeviceVM.cs|ToggleLight|449|Toggling
light to True
2023-12-05T16:08:42.8050|ERROR|DeviceUpdateTimer.cs|Start|103
ASCOM.DriverAccessCOMException (0x80040402): Timed out waiting for received
data ---> 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.DarkLight.CoverCalibrator.get_CoverState()
at ASCOM.DriverAccess.MemberFactory.CheckDotNetExceptions(String
memberName, Exception e) in C:\ASCOM
Build\Export\ASCOM.DriverAccess\MemberFactory.cs:line 626
at
ASCOM.DriverAccess.MemberFactory.GetTargetInvocationExceptionHandler(String
memberName, Exception e) in C:\ASCOM
Build\Export\ASCOM.DriverAccess\MemberFactory.cs:line 664
at ASCOM.DriverAccess.MemberFactory.CallMember(Int32 memberCode, String
memberName, Type[] parameterTypes, Object[] parms) in C:\ASCOM
Build\Export\ASCOM.DriverAccess\MemberFactory.cs:line 230
at ASCOM.DriverAccess.CoverCalibrator.get_CoverState() in C:\ASCOM
Build\Export\ASCOM.DriverAccess\CoverCalibrator.cs:line 60
at
Castle.Proxies.Invocations.ICoverCalibratorFacade_get_CoverState.InvokeMethodOnTarget()
at Castle.DynamicProxy.AbstractInvocation.Proceed()
at Castle.DynamicProxy.AbstractInvocation.Proceed()
at Castle.Proxies.ICoverCalibratorFacadeProxy.get_CoverState()
at
NINA.Equipment.Equipment.MyFlatDevice.AscomCoverCalibrator.get_CoverState()
in
C:\Projects\nina\NINA.Equipment\Equipment\MyFlatDevice\AscomCoverCalibrator.cs:line
36
at
NINA.WPF.Base.ViewModel.Equipment.FlatDevice.FlatDeviceVM.GetFlatDeviceValues()
in
C:\Projects\nina\NINA.Core.WPF\ViewModel\Equipment\FlatDevice\FlatDeviceVM.cs:line
436
at NINA.Core.Utility.DeviceUpdateTimer.<<start>b__21_0>d.MoveNext() in
C:\Projects\nina\NINA.Core\Utility\DeviceUpdateTimer.cs:line 87
2023-12-05T16:08:43.3636|INFO|AscomDevice.cs|Disconnect|276|Disconnecting
from ASCOM.DarkLight.CoverCalibrator DarkLight CoverCalibrator
2023-12-05T16:28:04.5035|INFO|FlatDeviceVM.cs|ToggleLight|449|Toggling
light to True</start>
Which afterwards just seems to lock up anything to do with the calibrator.
Using the DarkLight program itself is fine, but it would be great to use
this through NINA so I can schedule my flats at the end of my imaging
session. Any idea what might be causing this, or if it's fixable? I've
attached a screenshot of the NINA interface locking up after toggling.
Sorry to hear you're having some trouble. Thanks for bringing up the issue you're experiencing and including the error log and screenshot. I'm glad you've been able to test against the DLC app and verify it works as expected, narrowing the issue down to doing something specifically with NINA. Let's get this issue addressed.
Based on your log, if I'm reading it right, NINA sent the command to turn the light on and then checked the state of the cover but never received the "#," aka DONE command, for the response. After the light turns on, it should have sent a # after completing the lightOn event and then been ready to receive and respond to the following command. Did the light turn on?
I need to see a breakdown of the communication. Please provide an ASCOM Serial Trace log; ASCOM Chooser > Trace > Serial Trace Enabled. Along with a new NINA log from the same event so I can trace the transaction history. Thank you.
R/
Nathan
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hey Nathan, thanks for getting back to me so quick!
In answer to your first question the light did turn on before it froze
And I've retrieved some logs from testing today, I've attached them and hopefully they help.
Although it was a bit harder to get it to reproduce today. The toggle button actually started working straight off, however after one or two times there was a long delay before the toggle would happen. I also tested swapping back to the DarkLight program as well, and experienced similar long delays. Eventually I swapped back to NINA and a cominbation of turning the cover 12v power on/off, and toggling the light panel, I was able to reproduce the problem again. Same with the DarkLight software. It seemed as though the script running the arduino gets into a weird state?
Is it possible this is occuring from the 12v power being turned off, but the USB still being on? Because my observatory is remote everything is running through remote controlled switches, which don't turn the USB power off to a device, and I'm wondering if the connection gets locked up on the Arduino side
"In answer to your first question the light did turn on before it froze."
OK, that's good. That supports the logs that the command was sent and received, but the confirmation # sent back to NINA was lost for some reason. I cannot reproduce the issue you're experiencing on my test bench, even with the 12V source disconnected, but I have a theory. I'll do some testing and get back to you. It may be a day or two. In the meantime, for giggles and fun, as Ryan's post mentioned. Please change your maxBrightness = 255 and see if that works without issue.
"Although it was a bit harder to get it to reproduce today. The toggle button actually started working straight off, however after one or two times there was a long delay before the toggle would happen."
**Do you mean turning the light on/off multiple times? **
"Is it possible this is occuring from the 12v power being turned off, but the USB still being on?"
In theory, you could damage the Arduino if you attempt to draw too much power, but realistically, I do not believe that is the cause of our issue.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Yeah, I was toggling the light on and off multiple times, and it would hit an increasing delay between the light state changing and the interface being re-enabled
I also tried setting max birghtness to 255 which unfortunately didn't work. This time I toggled multiple times, disconnected, then reconnected, and tried to toggle again and it happened immediately. So was working before disconnect/reconnect. I've attached the latest logs
Nial has been gracious enough to provide many logs, and we uncovered one error, which has been resolved. Unfortunately, it has created a new issue for him, which we are still working to resolve. Thankfully, he has completed some verification testing, and I should have a new release in the not-so-distant future.
Happy holidays to everyone!
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Nial and I have been able to resolve his issue. I want to clean up the code and have him retest to ensure everything functions appropriately. Then, I can release an update. Have an excellent finish to your year.
Happy New Year everyone!
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hey Nathan,
Just wanted to flag an issue I’m having using DarLight with NINA. It
connects fine, and the open and closing of the panel works great, however
toggling the light from the software seems to bring back the
CoverCalibrator.get_CoverState() issue. The error from the logs is:
2023-12-05T16:06:42.3781|INFO|FlatDeviceVM.cs|ToggleLight|449|Toggling
light to True
2023-12-05T16:08:42.8050|ERROR|DeviceUpdateTimer.cs|Start|103
ASCOM.DriverAccessCOMException (0x80040402): Timed out waiting for received
data ---> 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.DarkLight.CoverCalibrator.get_CoverState()
at ASCOM.DriverAccess.MemberFactory.CheckDotNetExceptions(String
memberName, Exception e) in C:\ASCOM
Build\Export\ASCOM.DriverAccess\MemberFactory.cs:line 626
at
ASCOM.DriverAccess.MemberFactory.GetTargetInvocationExceptionHandler(String
memberName, Exception e) in C:\ASCOM
Build\Export\ASCOM.DriverAccess\MemberFactory.cs:line 664
at ASCOM.DriverAccess.MemberFactory.CallMember(Int32 memberCode, String
memberName, Type[] parameterTypes, Object[] parms) in C:\ASCOM
Build\Export\ASCOM.DriverAccess\MemberFactory.cs:line 230
at ASCOM.DriverAccess.CoverCalibrator.get_CoverState() in C:\ASCOM
Build\Export\ASCOM.DriverAccess\CoverCalibrator.cs:line 60
at
Castle.Proxies.Invocations.ICoverCalibratorFacade_get_CoverState.InvokeMethodOnTarget()
at Castle.DynamicProxy.AbstractInvocation.Proceed()
at Castle.DynamicProxy.AbstractInvocation.Proceed()
at Castle.Proxies.ICoverCalibratorFacadeProxy.get_CoverState()
at
NINA.Equipment.Equipment.MyFlatDevice.AscomCoverCalibrator.get_CoverState()
in
C:\Projects\nina\NINA.Equipment\Equipment\MyFlatDevice\AscomCoverCalibrator.cs:line
36
at
NINA.WPF.Base.ViewModel.Equipment.FlatDevice.FlatDeviceVM.GetFlatDeviceValues()
in
C:\Projects\nina\NINA.Core.WPF\ViewModel\Equipment\FlatDevice\FlatDeviceVM.cs:line
436
at NINA.Core.Utility.DeviceUpdateTimer.<<start>b__21_0>d.MoveNext() in
C:\Projects\nina\NINA.Core\Utility\DeviceUpdateTimer.cs:line 87
2023-12-05T16:08:43.3636|INFO|AscomDevice.cs|Disconnect|276|Disconnecting
from ASCOM.DarkLight.CoverCalibrator DarkLight CoverCalibrator
2023-12-05T16:28:04.5035|INFO|FlatDeviceVM.cs|ToggleLight|449|Toggling
light to True</start>
Which afterwards just seems to lock up anything to do with the calibrator.
Using the DarkLight program itself is fine, but it would be great to use
this through NINA so I can schedule my flats at the end of my imaging
session. Any idea what might be causing this, or if it's fixable? I've
attached a screenshot of the NINA interface locking up after toggling.
Cheers,
Nial
I should also mention that once it gets locked up like this I need to disconnect the usb, and power the panel off, before I can use it again
Hi Nial,
Sorry to hear you're having some trouble. Thanks for bringing up the issue you're experiencing and including the error log and screenshot. I'm glad you've been able to test against the DLC app and verify it works as expected, narrowing the issue down to doing something specifically with NINA. Let's get this issue addressed.
I only know one other person who has the DLC setup with NINA. @Ryan did have a couple of problems with NINA and was able to resolve them. You can see his issue here: https://sourceforge.net/p/darklight-cover-calibrator/discussion/general/thread/dad33d9834/#de0e/9eeb.
Based on your log, if I'm reading it right, NINA sent the command to turn the light on and then checked the state of the cover but never received the "#," aka DONE command, for the response. After the light turns on, it should have sent a # after completing the lightOn event and then been ready to receive and respond to the following command. Did the light turn on?
I need to see a breakdown of the communication. Please provide an ASCOM Serial Trace log; ASCOM Chooser > Trace > Serial Trace Enabled. Along with a new NINA log from the same event so I can trace the transaction history. Thank you.
R/
Nathan
Hey Nathan, thanks for getting back to me so quick!
In answer to your first question the light did turn on before it froze
And I've retrieved some logs from testing today, I've attached them and hopefully they help.
Although it was a bit harder to get it to reproduce today. The toggle button actually started working straight off, however after one or two times there was a long delay before the toggle would happen. I also tested swapping back to the DarkLight program as well, and experienced similar long delays. Eventually I swapped back to NINA and a cominbation of turning the cover 12v power on/off, and toggling the light panel, I was able to reproduce the problem again. Same with the DarkLight software. It seemed as though the script running the arduino gets into a weird state?
Is it possible this is occuring from the 12v power being turned off, but the USB still being on? Because my observatory is remote everything is running through remote controlled switches, which don't turn the USB power off to a device, and I'm wondering if the connection gets locked up on the Arduino side
And here are the logs when the DarkLight software stopped responding
Thanks for the additional logs.
"In answer to your first question the light did turn on before it froze."
OK, that's good. That supports the logs that the command was sent and received, but the confirmation # sent back to NINA was lost for some reason. I cannot reproduce the issue you're experiencing on my test bench, even with the 12V source disconnected, but I have a theory. I'll do some testing and get back to you. It may be a day or two. In the meantime, for giggles and fun, as Ryan's post mentioned. Please change your maxBrightness = 255 and see if that works without issue.
"Although it was a bit harder to get it to reproduce today. The toggle button actually started working straight off, however after one or two times there was a long delay before the toggle would happen."
**Do you mean turning the light on/off multiple times? **
"Is it possible this is occuring from the 12v power being turned off, but the USB still being on?"
In theory, you could damage the Arduino if you attempt to draw too much power, but realistically, I do not believe that is the cause of our issue.
Yeah, I was toggling the light on and off multiple times, and it would hit an increasing delay between the light state changing and the interface being re-enabled
I also tried setting max birghtness to 255 which unfortunately didn't work. This time I toggled multiple times, disconnected, then reconnected, and tried to toggle again and it happened immediately. So was working before disconnect/reconnect. I've attached the latest logs
Thanks for all your hard work!
In case anyone is following this discussion.
Nial has been gracious enough to provide many logs, and we uncovered one error, which has been resolved. Unfortunately, it has created a new issue for him, which we are still working to resolve. Thankfully, he has completed some verification testing, and I should have a new release in the not-so-distant future.
Happy holidays to everyone!
Nial and I have been able to resolve his issue. I want to clean up the code and have him retest to ensure everything functions appropriately. Then, I can release an update. Have an excellent finish to your year.
Happy New Year everyone!