How to cancel/abort loading a tool through M6ATC?

[sebba]

Hello,

I'm somehow new to the Mach3 VB scripting and now I'm trying to make some modification into my screenset and to create my personalized M6ATC script.
I want o make a 10 slots magazine, with a flexible allocation of different tools # in different slots, and not to have only tools from 1 to 10.
Now - in this initial phase - I managed to set any tool # in any slot i want and, if the requested tool # exist in magazine, it will be picked up and use it.
So far, so good, but I still have an issue I cannot solve it.
If somehow, by mistake, the requested tool does not exist in magazine, I need to stop the execution of the script without having the requested tool # set as active tool
And because the requested tool was not found, I need, after aborting M6ATC script, to have T0 as active tool (oemdro 824), not the requested tool number.

I have a small video - not finished yet - with what I want to do, maybe will be more clear.
The problem is visible at the end, when I want to load T1, which does not exist, but is still loaded.
Initially I thought I made some mistakes but I checked with the default empty M6ATC script, and it happens exactly the same.

Here is the video link: https://youtu.be/wflVkCaJQo0

Thank you,
Seb

[DaveCVI]

So far, so good, but I still have an issue I cannot solve it.
If somehow, by mistake, the requested tool does not exist in magazine, I need to stop the execution of the script without having the requested tool # set as active tool

I went and looked at MSM's internal code, I'm afraid that this not possible, and not desirable, given the way MSM currently handles running the user M6ATC script. I'll try to explain -

When a Gcode M6 is executed, Mach calls MSM's version of M6 start and M6End. This is the usual hook into mach to run code for handling M6 operations. The MSM internal code does a lot of things that MSM needs internally for handling tool changes (ex: optional tool measuring etc) including checking to see what the tool change mode is.
If the mode is ATC, then MSM executes the user's M6ATC script.

Here is a simplified excerpt from the MSM code that does that:

Code: Select all

	' now to the actual tool change code 
	tool = GetSelectedTool()

	' now call the auto tool changer code script
	result = RunScript(ATCScriptPathSpec)
	if result < 0 then
		' error - script was not run or an error happened
		' abort TC and reset mach
		if GetOEMLED(MachResetOEMLED) = 0 then	' not in estop
			DoOEMButton( MachResetOEMBtn )		' stop the G-code execution and reset Mach
		end if
	End If

	SetCurrentTool( tool )

This is the source of what you see as a problem. The SelectedTool# (the # from the last executed T gcode command) is stored before M6ATC is called and whether the M6ATC script is successful or not, Mach's CurrentTool is updated after the script is run.

with respect to the tool # update, this is the same logic that the stock (non-MSM) Mach M6STart uses

Code: Select all

tool = GetSelectedTool()
  SetCurrentTool( tool )

When MSM was written (many years ago now), the MSM code was written to play it safe and just always do what stock mach did before returning from M6 scripts back to mach.

This makes sense when one considers the tool number state from a G-code point of view. G-code does not ever expect a tool change (M6) to complete with any state other than the spindle tool now being what was the next tool #. Essentially, gcode has no concept of a M6 that is not successful. If the gcode is allowed to continue running after a failed M6, it will likely result in a machine crash very quickly.

This is why every detected error condition for M6 handling in the MSM code results in a estop reset of mach so that gcode can not continue to run. A failed M6 is a control error and it is necessary for the operator to resolve whatever happened, and then restart the gcode once the machine is back into the state that the gcode assumes.

I expect another question for me might be: "Can you change the MSM code so that it does not always call SetCurrentTool(), but instead leaves that up to the M6ATC script? Or only does the CurrentTool update if the script is successful?

Even if I ignore the Gcode state issue, making such a change would alter the assumptions of what all existing M6ATC scripts are expected to do. Thus, making the change would break all the existing M6ATC scripts which users already have.

As a product philosophy, we try never to make a change that breaks already running systems.

And because the requested tool was not found, I need, after aborting M6ATC script, to have T0 as active tool (oemdro 824), not the requested tool number.

BTW, depending on the error condition detected, T0 may not be the correct value for CurrentTool. Example: If the previous tool could not be removed from the spindle for some reason, you would not want mach to think the spindle was empty when it still has a tool in it.

Once a M6 is messed up, it really requires that the machne stop with a machine reset and then the operator has to put the machine back into a good state.
As part of that process, the operator may also need to reset Mach's understanding of what the current tool # is for the spindle.

Dave

[sebba]

BTW, depending on the error condition detected, T0 may not be the correct value for CurrentTool. Example: If the previous tool could not be removed from the spindle for some reason, you would not want mach to think the spindle was empty when it still has a tool in it.

Once a M6 is messed up, it really requires that the machne stop with a machine reset and then the operator has to put the machine back into a good state.
As part of that process, the operator may also need to reset Mach's understanding of what the current tool # is for the spindle.

Thank you, Dave, for taking your time for such a complete explanation.
I totally agree with you

Best regards,
Seb