130
« on: February 04, 2018, 03:58:20 PM »
Coroutines have been a bit of a mystery to me: I am much happier with the concept of independent threads and semaphores. So thank you for posting and whetting my appetite to give them a try.
I too have extensively re-written the mcProbing module. Amonst other things, all Gcode is funnelled through a single function, the idea being that it would be easy to incorporate the necessary coroutine.yield() call if I decided to go down that path. As I have found that the GUI does not lock up even though I exclusively use mcCntlGcodeExecuteWait I had not taken that option.
Seeing your post left me unable to resist giving coroutines a try in a tool length measuring function that I was working on. This is initiated by a call from a button script. I found that with or without the coroutine approach, the function worked well, moving the tool over a sensor, probing, and returning the tool to its starting position without any obvious lock up or drag on the GUI.
I then ran a small program with an M6 macro that waited on a signal for manual tool insertion. During this hold, Mach4 remained in a File Run state. I tried running the measurement function, again via a screen button, during this M6 hold. I modified the coroutine.resume function to test for the File Run state in addition to Idle. I found that the original routine ran perfectly during the M6 hold, with no GUI lock ups. To my complete surprise, the coroutine version of the routine locked up the DROs which only caught up when the routine had completed.
This has left me wondering whether coroutines are the panacea that I had once imagined. I have removed them from my code, at least for now, as it seems to work better without. I welcome any ideas as to what might have caused the poor performance with coroutines when in the macro hold, as I am currently mystified by it.
Allan