Manual Tool Change Command

[aldenhart]

Does tinyg/tgfx support manual tool changes? Like where it would pause and prompt to change the tool then wait for a button press or something to resume motion? Or is it just 1 tool per program for now?

-- posted by Alden from forum post by mcgyvr

[aldenhart]

Right now it's one tool per program, but we should discuss what's meant by a manual tool change. To manage this properly the system will need to handle at least the following:

• T word for tool select
• M6 for tool change
• Spindle stop and start
• G43 Tool length offset and possibly tool length offset table (pre-loaded offsets)
• Gcode messages for communication to the operator
• Cycle start to restart

Some of this is already working, some is stubbed into the code, and some needs to be added. The code already has spindle controls. Messages can be sent using gcode comments of the form "(msgInsert Operator text here...)". Cycle start is simply a ~, but it need to be linked into the M6 sequence. The code has T and M6 stubbed, but no functions attached to them, and there is no tool table (not completely necessary).

Beyond this we should have a spec that describes the exact behavior we want. Some guidance is offered via LinuxCNC: http://www.linuxcnc.org/docs/2.4/html/gcode_main.html

[mikest]

we support "semi-auto" tool changes. (by we, I mean otherplan does)

tinyg could be made to support manual tool changes from console mode simply by pausing when a tool change command is issued, but honestly, if you're typing code into the console you've personally already implemented manual tool changes. you'll need a way to align one tool against another and that's very machine specific. as tinyg has no concept of a "stored program" any sort of tool change behavior would need to exercise gcode stream control... at which point you're not using console mode anymore, but a client program.

a tool change is best thought about as a subroutine, manual or not, wherein the planner needs to stop and some very machine specific code or user action needs to execute, once it's finished the planner then is signaled to pick up where it has left off.

offset tables (H codes) are a traditional method of making this process fast, but honestly, they're highly dependent on the machine design and rigidity and won't work for everyone.

gcode: "providing the absolute best human readable assembly language for robot control the 1960s had to offer."

--mikest

Sent from my iPhone

On Mar 12, 2014, at 3:37 AM, Alden Hart notifications@github.com wrote:

Right now it's one tool per program, but we should discuss what's meant by a manual tool change. To manage this properly the system will need to handle at least the following:

T word for tool select M6 for tool change Spindle stop and start G43 Tool length offset and possibly tool length offset table (pre-loaded offsets) Gcode messages for communication to the operator Cycle start to restart Some of this is already working, some is stubbed into the code, and some needs to be added. The code already has spindle controls. Messages can be sent using gcode comments of the form "(msgInsert Operator text here...)". Cycle start is simply a ~, but it need to be linked into the M6 sequence. The code has T and M6 stubbed, but no functions attached to them, and there is no tool table (not completely necessary).

Beyond this we should have a spec that describes the exact behavior we want. Some guidance is offered via LinuxCNC: http://www.linuxcnc.org/docs/2.4/html/gcode_main.html

— Reply to this email directly or view it on GitHub.

[mcgyvr]

I should have really made this a "feature request" for Tgfx as I believe that most of the functionality I was thinking about is already in tinyg..

I envisioned the following happening.. (please excuse my lack of programming/function jargon)

A tool change x/y/z position would be either included in the $$ settings or set in tgfx per job/session.. When a T word is encountered Tgfx should tell tinyg to do the following ..1- hold processing gcode..2- stop the spindle/coolant.. and 3- move to the tool change position(z up first obviously then xy). Then a dialog would pop up saying .."Please change to tool #? and then press ok" or something like that. Then tgfx would again prompt you to jog to establish the new z height. Then tgfx can tell tinyg to go back to processing the gcode.

Using M6 with a T word really isn't even needed yet as I doubt there are any users that need to have their machine preload tools. So just go into action immediately when a T word is encountered.

[mschorer]

my ideas are like this (working on grbl's spindle control + tool changing):

• m6 pauses gcode execution, saves spindle state and stops spindle
• there is some visual feedback on "tool change mode" (eg led blink code or lcd display etc)
• machine moves to (a configurable) tool change positon ( to front/center/top, per "tool index" from left to right? )
• user changes tool, user presses resume button
• appropriate length compensation is enabled (eg do a measurement cycle or blindly use predefined compensation or move spindle to predefined/compensated position and let the user adjust the tool against work plate etc)
• user presses resume button again
• the machine moves safely back to take-off position and resumes motion/spindle

i think this should be reasonable regarding lines of code, integration into the firmware and universality across machines. i'm pretty sure that splitting the handling between firmware and the streaming app (tgFx) isn't a good idea ...

[lutorm]

Hi all,

I was hoping to use TinyG with multiple tools, but the lack of length compensation seems to be a killer for this. I can see how the tool change "subroutine" itself could be managed outside of TinyG, but without the G43 tool length offsets, you'd have to implement the offset by re-defining the "main" G10 L2 coordinate offsets at every tool change, right? This would push the management of keeping track of the coordinate system offsets out to the sending context, which would add quite a bit of complexity on that end. How hard would it be to get the G43 offsets into TinyG?

[dgtlmoon]

Is this still an issue? another thread is hinting that M6 is supported. or am I missing something about this issue? can anyone clarify? see #186

[dgtlmoon]

@chillipepr

[johnlauer]

I use ChiliPeppr with TinyG with M6 commands all the time. ChiliPeppr has a lot of features to make M6 a breeze. On an M6 you just jog around, raise the Z, swap the tool, re-run the touch plate to Z zero out the tool, then unpause the job and you're off and running again. I don't need tool change offsets either because the Gcode has already been generated to take into account the tool. I also just make sure I zero out the next tool correctly on the Z axis.

[lutorm]

I also use M6 and tool change offsets, although as far as I know the latter are only available in TinyG2 (https://github.com/synthetos/g2/pull/109)

[dgtlmoon]

yes. so can we close this issue? @aldenhart ?

@johnlauer - so on chillipepr it simply pauses /stops on an M6 command right? any steps required to make that happen? some configuration or wiki notes applicable?

[dgtlmoon]

and probably finally; can anyone confirm G38.2 works under an M6 condition?

[johnlauer]

M6 pause is on by default so no configuration needed

Get Outlook for Androidhttps://aka.ms/ghei36

---

From: dgtlmoon notifications@github.com Sent: Thursday, February 16, 2017 2:08:46 PM To: synthetos/TinyG Cc: John Lauer; Mention Subject: Re: [synthetos/TinyG] Manual Tool Change Command (#75)

and probably finally; can anyone confirm G38.2 works under an M6 condition?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHubhttps://github.com/synthetos/TinyG/issues/75#issuecomment-280477903, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AA8jlaAWhpMqU2Hf4_bfib7so5PJwNIyks5rdMjugaJpZM4Bo6SU.

[dgtlmoon]

I can confirm that M6 works, be sure to enable Pause on M6 in the settings tab of the GCode widget

I can confirm that M06, M6 and T0 M6 commands work as expected