[emery]

Hey all, I'm building an html5 canvas implementation for generating gcode, as a part of a large endeavor to make a unixy utilitarian toolchain for cnc. https://github.com/em/gcanvas

I am looking to you guys for some advice on how I should support ATC and manual tool changes.

There doesn't seem to be much of a standard on how manual tool changes are done.

Here are some of the options:

1) Handle it outside of Gcode, block stdin and prompt for the new tool through stderr.

2) Use the T command as if ATC were supported, and make a separate utility for manual ATC postprocessing.
This makes manual tool changes harder than they need to be and forces you to maintain a mapping table.

3) Just pause with a comment (is there even a standard pause or prompt command? I can only find M226 which seems to be a reprap thing.)

I'd also really appreciate any thoughts on where the spindle should move to make the tool change. I'd like to avoid an additional context property like toolChangeZ, but that is probably unavoidable.

I'd like the actual API to remain independent of units and deal with tool changes when toolDiameter is changed. I can easily detect if the tool is an integer in mm or fractional inch and prompt accordingly.

Any ideas are very appreciated. Thank you! : )

Also here's a bit of eye candy, testing non-zero winding rule example: https://cloudup.com/c4FDvrtZoG5

[mactec54]

emery

M01 is a standard for optional Stop

M00 is a standard for program Stop

Just use the standard T1M6 for a tool change The T command is the tool number the M6 is the tool change command

Tool offset you would want G43 H1 Z---

At the end of you program before a tool change you need the Z to move up before a X Y move

G28 Z--- or a G0Z---
Then a X Y move this needs to be on a separate line

For a manual Tool change use a G28 X---Y--- or a G0 X---- Y----

[ger21]

I think the control that you are using should probsably handle the tool change.
In Mach3, all you have to do is call an M6 Tx and then Mach3 will handle the toolchanges. I would think that most controls would be similar?
Handling the entire Tool Change in g-code is not a good idea, imo.

[emery]

Thanks guys! I ended up finding a solution I like.

I decided to deal with this in the gcanvas(1) utility instead of making blocking human intervention a part of the lib.

In a part script you break things into setup blocks which prompt the user to do something before the next block.

setup('face up', function(ctx) {...});
setup('1/2" endmill', function(ctx) {...});
setup('left side', function(ctx) {...});
setup('1/4" threadmill', function(ctx) {...});

This approach manages to keep it simple by using messages instead of requiring a structured tooling definitions. : )

[emery]

Thanks guys! I ended up finding a solution I like.

I decided to deal with this in the gcanvas(1) utility instead of making blocking human intervention a part of the lib.

In a part script you break things into setup blocks which prompt the user to do something before the next block.

setup('face up', function(ctx) {...});
setup('1/2" endmill', function(ctx) {...});
setup('left side', function(ctx) {...});
setup('1/4" threadmill', function(ctx) {...});

This approach manages to keep it simple by using messages instead of requiring structured tooling definitions. : )