View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0002172||CCdciel||[All Projects] General||public||19-08-24 04:13||19-08-27 15:42|
|Reporter||Cedric Raguenaud||Assigned To||Patrick Chevalley|
|Priority||normal||Severity||minor||Reproducibility||have not tried|
|Target Version||1.0||Fixed in Version|
|Summary||0002172: Suggestion: data collecting jobs in their own thread|
|Description||It would be good if tasks that are orthogonal to the functioning of ccdciel ran in their own thread so as to not lock ccdciel while they wait to complete, e.g. Safety and weather monitors.|
|Tags||No tags attached.|
Can you give more information about function that lock ccdciel? if possible with a log so I can try to reproduce the situation with the simulator.
I just tested with a sequence interrupted by bad weather with message "Sequence paused for bad weather ...".
In this case the interface is not locked, you can click any menu and you can use the sequence Stop button to terminate.
||It happened to me when my safety monitor, which loads external data (weather), couldn't reach its source of information (network issue). Then ccdciel was locked until the timeout in the network connection within the safety monitor was reached. At least I think that's wat was happening. I see nothing specific in the logs.|
OK, I understand.
CCDciel make every ASCOM call from the main thread because many ASCOM driver are not thread safe.
For this monitoring ccdciel use a timer to check the device status periodically, in this case it call IsSafe from the main thread.
In this case the safetymonitor interface is so simple with this unique function that I can try to make the check in a separate thread. For more complex driver I have to use some lock (mutex) to prevent simultaneous call and this can introduce other problem.
I see what you mean. I solved the problem in my case by moving the data fetch to a raspberry pi which does some caching so that when the safety driver requests the data it never had to wait.
But this could happen for example if someone uses online weather data to feed their safety monitor (do people do that? I think it's the default for NINA and Ekos).
Yes I think this is the good way. Probably the driver must do it's periodic data collection and when IsSafe is called it only have to check the available data.
I don't know of online weather ascom driver, but the indi driver do the data collection independently of reporting the status. This is also because online weather server do not change too often and the number of daily api call is limited.
Also this issue is not possible with indi because ccdciel never make a query to the driver, it is the driver that send a message when the status change.
I make a change to the program to prevent flooding by timer event in the case the query function take more time than the timer interval. I have already do that for the Alpaca interface but local ascom was not protected again this issue:
I think this change is all I can do to help in such case.
From the ASCOM basic principle It is really to the driver to handle any communication issue with the hardware, maintain a cache of data that are slow to access, or decide what to do if the data are not available.
In the case an exception is raised, ccdciel assume unsafe status.
|19-08-24 04:13||Cedric Raguenaud||New Issue|
|19-08-24 10:13||Patrick Chevalley||Assigned To||=> Patrick Chevalley|
|19-08-24 10:13||Patrick Chevalley||Status||new => assigned|
|19-08-24 10:13||Patrick Chevalley||Target Version||=> 1.0|
|19-08-25 11:22||Patrick Chevalley||Status||assigned => feedback|
|19-08-25 11:22||Patrick Chevalley||Note Added: 0005874|
|19-08-25 11:31||Cedric Raguenaud||Note Added: 0005876|
|19-08-25 11:31||Cedric Raguenaud||Status||feedback => assigned|
|19-08-25 12:14||Patrick Chevalley||Note Added: 0005877|
|19-08-25 12:24||Cedric Raguenaud||Note Added: 0005878|
|19-08-25 13:04||Patrick Chevalley||Note Added: 0005879|
|19-08-27 15:42||Patrick Chevalley||Status||assigned => resolved|
|19-08-27 15:42||Patrick Chevalley||Resolution||open => fixed|
|19-08-27 15:42||Patrick Chevalley||Note Added: 0005888|