Open SamsonBox opened 1 year ago
I have noticed these same issues over the past year. There are a number of fixes IMO that need to be applied to get TLO and Tools to function as expected. You might give these changes try, fix_TLO_and_Tool_handling
I am going to try. I have always used M6 with TLO and no problems.
@rschell I have quickly looked over your changes. When I understand your proposel correctly, than you store the values in a file and reload them after the controller reset. I'm sure if that ist the way to go. I think the controller reset should wait until the reset is really over and send the commands after wards.
My computer/controller on my machine spend 98% of its time in a development mode. The operating system/bCNC/controller are rebooted quite often. The state of the machine doesn't change during these reboots. So my goal was to return bCNC/machine state to that prior to these resets.
The code snippets you maybe most interested in are in _GenericController.py (softReset and purgeController). I spent a few days figuring out that g43.1 in the G return only indicates that a value has been set and is not sufficient to reset the state.
You are right, these changes are good. But I think the soft_reset should become an event to get it dispatched from the serialIO thread and wait till the reset-reply is received
I'll take a look at your suggestion.
Is it necessary to purge the controller at the end of the program? I solved the problem by removing the call to jobDone in the sender.py module :
def controllerStateChange(self, state):
print("Controller state changed to: %s (Running: %s)"%(state, self.running))
if state in ("Idle"):
self.mcontrol.viewParameters()
self.mcontrol.viewState()
if self.cleanAfter == True and self.running == False and state in ("Idle"):
self.cleanAfter = False
_self.jobDone()_
The TLO remains active after the end of the job and allows the spindle to be moved without risk.
When the next job is started the current TLO is canceled by a G49 placed in the preamble. It will be recreated when the first tool is mounted Cancellation of the TLO should remain the choice of the operator, not a prerogative of the machine. If you want it to be reset to 0 at the end of the job, just include a G49 in the postamble.
The controller should only be purged if stop is pressed during machining (emergency stop). In this case the machine must be reinitialized before restarting the job.
JP
Hi, I tried the manual tool change (TLO) and I found out, that it doesn't work. In fact all the motions and calculation are right, but the TOL doesn't survive the
purgeController
at all. The reason is the folloing: After all motions are done, bCNC state is changed toIdle
in thecontrollerStateChange
function andjobDone
is called which in turn callspurgeController
from theserialIO
-Thread. ThepurgeController
stores the "G"-variables and the "TLO", resets the controller (via a realtime commad) a and tries restores the "G"-variables and the "TLO". But in the next runserialIO
-loop the reset answer ("Grbl xxx") ist parsed and the_stop
is set toTrue
. Due to this flag the gcode-queue gets cleared in theserialIO
-loop (emptyQueue
) and the commands to restore the "G"-variables and the "TLO" are gone. Have I done something wrong? Or do you have any suggestions to overcome ths problem?Thank you