My focuser is all done and I have tried it a few times and it is working well thanks.
I am however picking up an issue where the after a a while the INDI log fill with temp probe errors. I can make it happen in a minute or two using the simulators.
My WIFI signaal is basically 100% on both devices so I dont think it is a network issue.
From the log it seems to be after a serial timeout, attached are all the logs.
Hi Cliff
Jaseem has just pushed a change to the myFocuserPro2 INDI driver.
In the sendCommand() of the .cpp file
change
if (res == nullptr)
return true;
to
if (res == nullptr)
{
tcdrain(PortFD);
return true;
}
Please let me know.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The controller and connection appeared fine till there was a serial timeout error.
When that occurred, INDI did not clear any responses and thus the INDI side of things started to
go haywire. The sequence was
Send Command Get Position
Get response
Timeout occurred
(the controller was busy but responded too late - the response is in the buffer now)
Send Command Get Temperature
Get Response
and here INDI read the response from the Get Position send command, tried to process it and found it could not (because INDI is looking for a Get Temperature response)
and it all goes haywire.
I am pretty sure this is an INDI ussue with the driver. I have confirmed that in INDI the timeout for a connection is 3s and that is hardcoded. In ASCOM and Windows the connection timeout is 5 seconds, I do not know why INDI uses a smaller value.
When using TCP/IP the return response will often take longer than 3s (or even 5s in some environments). INDI does not appear to wrap the connection around with a semaphore, and does not appear to have a mechanism that handles this scenario. I will add that the ASCOM driver and Windows app handles these situations.
It is my personal belief that there needs to be separate timeout settings for Serial and TCP/IP connections to allow for network delays etc. I use 10s as a default timeout value for TCP/IP,
However, the also needs to be a code fix for how INDI handles the timeout issues. INDI has timed out because it did not receive a response in time (but the controller does not know that and for all purposes did what was asked of it) and makes the blanket assumption that the response is always associated with the command it just sent.
I do not know much about INDI. I am not "blaming" INDI. What I am saying is that the way INDI times out a connection and how it might handle recovery of that connection timeout needs to be looked at. At present this scenario that is happening with a TCP/IP connection (or even Serial) would happen to all INDI drivers not just the myFocuserPro2 driver.
I have asked Jasem and he has on GitHub changes the default connection timeout to 5 seconds from the default of 3s that INDI was using.
I would ask that you download the lastest from GitHub, compile that and let me know if that goes some my to addressing the issue. I will begin to look at other things to work on should this not resolve the issue
Regards
Robert
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
One more thing, I changed the update interval in the INDI myFocuser page from 1s to 5s,see attachment. I see that setting determines the polling interval in the driver. Since then I have not had an issue. I wonder if the update interval was not just to fast for INDI to process causing the eventual timeout ?
Hi Robert
My focuser is all done and I have tried it a few times and it is working well thanks.
I am however picking up an issue where the after a a while the INDI log fill with temp probe errors. I can make it happen in a minute or two using the simulators.
My WIFI signaal is basically 100% on both devices so I dont think it is a network issue.
From the log it seems to be after a serial timeout, attached are all the logs.
Any idea how we can solve this.
Cliff
Hi Clifford
I see you are using KStars with myFocuserPro2 and using the TCP/IP interface
I did not write the myFocuserPro2 INDI driver, but I have poured over the code for about the last few hours.
There may need to be a fix to the INDI driver, and I think I have found a code change required.
I need to get back to you on this.
If you have any knowledge on INDI and are able to compile any driver code that would be great but if you cannot, I will find another way.
Cheers
Robert
Hi Robert
Thanks that is great news.
Yea I have an INDI build environment and I have contributed a few minor updates to the project in the past.
Let me have the code when you ready and i will build and test it.
Thanks again !
Cliff
Hi Cliff
Jaseem has just pushed a change to the myFocuserPro2 INDI driver.
In the sendCommand() of the .cpp file
change
if (res == nullptr)
return true;
to
if (res == nullptr)
{
tcdrain(PortFD);
return true;
}
Please let me know.
Hi
Just to let yiu know I pulled the code and built it.
Looks good so far but will do some more tests tomorrow.
Cliff
Hi Robert
So did a lot more testing with the code changes and unfortunately I am still getting the error.
Both with the temp sensor enabled and disabled, and there is no difference.
The log attached shows the error start :
and now it seems like it recoververs :
Any other ideas ?
Again happy to try any code changes.
Regards
Cliff
Last edit: Clifford de Wit 2021-06-15
The controller and connection appeared fine till there was a serial timeout error.
When that occurred, INDI did not clear any responses and thus the INDI side of things started to
go haywire. The sequence was
Send Command Get Position
Get response
Timeout occurred
(the controller was busy but responded too late - the response is in the buffer now)
Send Command Get Temperature
Get Response
and here INDI read the response from the Get Position send command, tried to process it and found it could not (because INDI is looking for a Get Temperature response)
and it all goes haywire.
I am pretty sure this is an INDI ussue with the driver. I have confirmed that in INDI the timeout for a connection is 3s and that is hardcoded. In ASCOM and Windows the connection timeout is 5 seconds, I do not know why INDI uses a smaller value.
When using TCP/IP the return response will often take longer than 3s (or even 5s in some environments). INDI does not appear to wrap the connection around with a semaphore, and does not appear to have a mechanism that handles this scenario. I will add that the ASCOM driver and Windows app handles these situations.
It is my personal belief that there needs to be separate timeout settings for Serial and TCP/IP connections to allow for network delays etc. I use 10s as a default timeout value for TCP/IP,
However, the also needs to be a code fix for how INDI handles the timeout issues. INDI has timed out because it did not receive a response in time (but the controller does not know that and for all purposes did what was asked of it) and makes the blanket assumption that the response is always associated with the command it just sent.
I do not know much about INDI. I am not "blaming" INDI. What I am saying is that the way INDI times out a connection and how it might handle recovery of that connection timeout needs to be looked at. At present this scenario that is happening with a TCP/IP connection (or even Serial) would happen to all INDI drivers not just the myFocuserPro2 driver.
I have asked Jasem and he has on GitHub changes the default connection timeout to 5 seconds from the default of 3s that INDI was using.
I would ask that you download the lastest from GitHub, compile that and let me know if that goes some my to addressing the issue. I will begin to look at other things to work on should this not resolve the issue
Regards
Robert
Hi Clifford
I have looked at the INDI driver and noticed some things that need to change as well as some bug fixes for existing code.
I will send you the updated driver .cpp and .h files to recompile and test
At this time please ignore what you see on Guthub.
Regards
Robert
You will need to contact me direct at either my gmail or yahoo account details of which are in PDF document and firmware file
Hi Robert thanks yea i saw that same flow interesting insight on the timeout
I will mail you. Please check you junk mail as my last mail did not seem to get through.
One more thing, I changed the update interval in the INDI myFocuser page from 1s to 5s,see attachment. I see that setting determines the polling interval in the driver. Since then I have not had an issue. I wonder if the update interval was not just to fast for INDI to process causing the eventual timeout ?
Hi all
The INDI driver was updated recently and Jaseem has pushed this into the current release.
There are quite a few changes that were made.
Polling should be set to like 2 to 5s (2000-5000)
Hi Robert
Thanks, I have been using the last version you shared with me for a few weeks back and it is really working well in INDI.
Great to merge the latest version into INDI, as now I don't have to have a separate build !
Thanks
Cliff