However I would not recommend this approach in isolation, as sending arbitary commands to the board without the user knowing the machine state, could end up being extremely bad.... At a minimum you would need to understand the current machine state and enable/disable your buttons appropriately, to prevent errors. Creating your own skew of DWC, or a DWC plugin would be much safer, as DWC already has the necessary controls in place to understand and manage the machine state, and will generally prevent a user from making a mistake.
@t3p3tony oh - damn... The instance of CodeLogger I'm running is quitting when the API goes down, isn't it?
I wasn't getting any errors at all which I thought was because the script was somehow being killed - but that could've done it too. Would have though it would just keep running.
Will add a wait and retry to it.
@mikeabuilder This was posted, in part, to show a proof of concept in returning external data into DSF. Setting persistent global variables is a good use case, but I already have several more complex ideas in mind!
@chrishamm Another user experience the same issue described above (you can read about it here https://forum.duet3d.com/post/227680), so @jay_s_uk and I put our heads together and tried to narrow down the failure circumstances and find a consistent fix (simply uploading a new DWC*SD.zip does not always work).
What we have discovered is that if the current install/SD card has gone through a number of release upgrades (eg 3.1 through to 3.3b3) it is likely that this Z-Index issue will arise after installing the plugin. Under this scenario I have also experienced complete plugin installation failures.
The resolution is to remove the SD card, wipe the WWW folder (& dwc-settings.json for completeness), and manually replace the WWW folder with a fresh copy extracted from the DWCSD.zip release file. Then once back up and running, re-install the plugin. Simply re-installing DWC by uploading a new DWCSD.zip will not resolve the issue.
This leads us to theorise the following:
There are redundant/left over files in WWW from previous upgrades which are contributing to, or causing this issue.
If (for whatever reason) a plugin install fails, it does not always fail gracefully, and can corrupts or leaves files in a non working state.
I appreciate this is somewhat speculative (correlation is not causation and all that jazz), but it may help you with the continuing development of the plugin system.