Currently the qdlscan application operates as expected and is reasonably robust to user error on it's own: utilizing a busy flag on the application controller to reject any additional queries for scans while a scan is in progress. While the busy flag is technically a public attribute (can be get/set by the standard ScanController.busy syntax), it is designed to be used as an internal attribute which is get/set only by the ScanController class itself.
The reason for the quasi-private usage is that a user could accidentally set the busy flag into an incorrect state, enabling queries for scans which fail manifestly (because the hardware is occupied). This type of usage was not initially planned and so the development of the ScanController has resulted in busy being a public variable.
At the same time, the addition of the counter, qdlscope, into the application (which is called by right click menu or the main control panel), introduces yet another way to occupy the hardware which bypasses the application controller completely. In the current version of qdlscan (implemented in pull request #10) one can cause the software to soft lock itself by (1) launching the qdlscope, starting sampling which occupies the edge counter, then (2) attempting to launch a scan in qdlscan. This forces the application controller into the busy state, but the software cannot complete the function and is then locked in the busy state, requiring a restart to become operational.
These two issues are closely linked and the following steps could be made to improve the robustness of the application:
- Update the
ScanController.busy attribute to a local, private variable _busy and then create a getter method (e.g. is_busy(self) -> bool) which simply returns the value of _busy (which is True or False).
- Update all calls/checks of the old
busy attribute in the remainder of the application code (primarily the main application LauncherApplication, etc.) to utilize the new getter and no longer refer to the protected variable _busy or the old busy.
- Route the call of
qdlscope during a "open counter" command (corresponding to the method open_counter() of the LauncherApplication) through the application controller (ScanController) to enable setting of the _busy flag, protecting against the soft-locked state describe above.
Currently the
qdlscanapplication operates as expected and is reasonably robust to user error on it's own: utilizing abusyflag on the application controller to reject any additional queries for scans while a scan is in progress. While thebusyflag is technically a public attribute (can be get/set by the standardScanController.busysyntax), it is designed to be used as an internal attribute which is get/set only by theScanControllerclass itself.The reason for the quasi-private usage is that a user could accidentally set the
busyflag into an incorrect state, enabling queries for scans which fail manifestly (because the hardware is occupied). This type of usage was not initially planned and so the development of theScanControllerhas resulted inbusybeing a public variable.At the same time, the addition of the counter,
qdlscope, into the application (which is called by right click menu or the main control panel), introduces yet another way to occupy the hardware which bypasses the application controller completely. In the current version ofqdlscan(implemented in pull request #10) one can cause the software to soft lock itself by (1) launching theqdlscope, starting sampling which occupies the edge counter, then (2) attempting to launch a scan inqdlscan. This forces the application controller into thebusystate, but the software cannot complete the function and is then locked in thebusystate, requiring a restart to become operational.These two issues are closely linked and the following steps could be made to improve the robustness of the application:
ScanController.busyattribute to a local, private variable_busyand then create a getter method (e.g.is_busy(self) -> bool) which simply returns the value of_busy(which isTrueorFalse).busyattribute in the remainder of the application code (primarily the main applicationLauncherApplication, etc.) to utilize the new getter and no longer refer to the protected variable_busyor the oldbusy.qdlscopeduring a "open counter" command (corresponding to the methodopen_counter()of theLauncherApplication) through the application controller (ScanController) to enable setting of the_busyflag, protecting against the soft-locked state describe above.