vlachoudis / bCNC

GRBL CNC command sender, autoleveler and g-code editor
GNU General Public License v2.0
1.54k stars 528 forks source link

Manual Tool Change (TLO) doesn't work #1824

Open SamsonBox opened 1 year ago

SamsonBox commented 1 year ago

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 to Idle in the controllerStateChange function and jobDone is called which in turn calls purgeController from the serialIO-Thread. The purgeController 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 run serialIO-loop the reset answer ("Grbl xxx") ist parsed and the _stop is set to True. Due to this flag the gcode-queue gets cleared in the serialIO-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

rschell commented 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

MARIOBASZ commented 1 year ago

I am going to try. I have always used M6 with TLO and no problems.

SamsonBox commented 1 year ago

@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.

rschell commented 1 year ago

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.

SamsonBox commented 1 year ago

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

rschell commented 1 year ago

I'll take a look at your suggestion.

JipeB commented 1 year ago

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