Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Toolchanges #26

Open
petervanderwalt opened this issue Nov 16, 2018 · 52 comments
Open

Toolchanges #26

petervanderwalt opened this issue Nov 16, 2018 · 52 comments

Comments

@petervanderwalt
Copy link
Contributor

petervanderwalt commented Nov 16, 2018

Normally you'd want the GCODE to have M6 (Pause) then a Tx command. The UI should pause streaming at the M6, and prompt you to insert tool X. Then you jog to zero tool length, setzero z, and unpause. But thats not in the code yet... Sorry! (: - couple weeks though!

So the hack here is to split your gcode into seperate files for each tool. The machine will hold position between jobs (unless your gcode resets coordinates with G10, etc). Run the job file for tool 1. When its finished, change tool, zero z (dont rezero xy). Load file for tool 2, go. etc. I know its a kludge, but bare with us (; theres a lot of features that still has to be added - and we'll get to them all eventually (:

@petervanderwalt petervanderwalt added this to Planned Feature: Driver in OpenBuilds CAM and CONTROL Nov 16, 2018
@gmorse7
Copy link

gmorse7 commented Apr 30, 2019

Has anything been done to add the capability to accommodate tool changes and resetting Z manually in a single g-code file?

@petervanderwalt
Copy link
Contributor Author

Not yet (:
(Or this issue wouldnt have been "open" right)

@petervanderwalt petervanderwalt moved this from Planned Feature: Driver to In Progress in OpenBuilds CAM and CONTROL Aug 30, 2019
@petervanderwalt
Copy link
Contributor Author

Working on Toolchanges (finally!) this week:

First light:

dropdown

@petervanderwalt
Copy link
Contributor Author

petervanderwalt commented Sep 3, 2019

@swarfer @sharmstr - (: if you have any comments on it so far (and have some more sample gcode files to throw in the testing pool)

Basically the parser looks at the gcode, finds a M6 and splits it at that point. We look around for related comments to populate the description a little better

Ideally i want it to have the whole wizard like feel in the end (not yet) where it just runs and pauses on M6, lets you rezero etc, but for now (quicker) i figure handling each section/tool as a mini "job" means once its done we have access to all the usual jog/probe etc to prep for the next tool?
Or allows starting just a specific tool in a file

@gmorse7
Copy link

gmorse7 commented Sep 3, 2019

Here's a simple sample with tool change generated by the Fusion 360 GRBL post processor. I agree, pause on M6, allow movement to facilitate tool change and Z re-zero then resume. A message box prompt would be nice but given the multitude of possible platforms...unless of course there is a simple way.
ToolChangeTestPiece.docx

@gmorse7
Copy link

gmorse7 commented Sep 3, 2019

Here's some psuedo code I used to modify a post processor for another machine.

image

@petervanderwalt
Copy link
Contributor Author

petervanderwalt commented Sep 3, 2019 via email

@sharmstr
Copy link
Collaborator

sharmstr commented Sep 3, 2019

@swarfer @sharmstr - (: if you have any comments on it so far (and have some more sample gcode files to throw in the testing pool)

Basically the parser looks at the gcode, finds a M6 and splits it at that point. We look around for related comments to populate the description a little better

As a temp solution, its probably fine. I know I'm going to press the wrong run button, but you cant code for that :)

I'll get you some sample files tomorrow.

@swarfer
Copy link
Collaborator

swarfer commented Sep 4, 2019

Here is a SketchUcam file with tool changes. This is created by generating a file for T1 and another for T2 and then using the joiner tool to join the files together.
pockettester.txt

@swarfer
Copy link
Collaborator

swarfer commented Sep 4, 2019

Note the Sketchucam can also insert a macro for the toolchange which may not include a M6 command. User beware (-:

@petervanderwalt
Copy link
Contributor Author

petervanderwalt commented Sep 4, 2019 via email

@swarfer
Copy link
Collaborator

swarfer commented Sep 4, 2019

yep, just look in the file. the joiner hooks a few lines from the comment header of each file and includes them in the output just before the tool change command

@sharmstr
Copy link
Collaborator

sharmstr commented Sep 4, 2019

Here's one from Fusion using the Tormach post. I disabled G30 output.

PegBoard-Fusion-Tormach.txt

@petervanderwalt
Copy link
Contributor Author

So did the parser get it right?
Two operations:
1 = Holes cut with a 6.35mm endmil
2 = chamfering with a 12.7mm 30deg

two ops

@petervanderwalt
Copy link
Contributor Author

re @sharmstr " know I'm going to press the wrong run button, " - the Run Complete Job one is the one I am still working on and the one most should use. Idea is to get it to run to a toolchange, popup a message telling you which tool to load, then lets you jog/probe/etc and finally continue

@sharmstr
Copy link
Collaborator

sharmstr commented Sep 4, 2019

The parsed info looks good.

Ah, ok. During the tool change, will macros be available so I can use a modified G28 for my tool change location instead of having to jog?

@petervanderwalt
Copy link
Contributor Author

petervanderwalt commented Sep 4, 2019

Yeah I'm forseeing handling each section "like a job", ie when it gets to the end, before the toolchange it "stops" streaming completely. Instead of duplicating jog/probe/macro buttons onto a dialog. Just click "ok i'll load up that tool" (hehe) and then we hand you back to the full UI but play button will say "Continue" or something like that which actually starts the next section

@petervanderwalt
Copy link
Contributor Author

petervanderwalt commented Sep 4, 2019

@swarfer :

Here is a SketchUcam file with tool changes. This is created by generating a file for T1 and another for T2 and then using the joiner tool to join the files together.
Looks like it worked (:

pockettest

I checked the file and I do see it having the headers from the joiner as described.
But for Sketchucam can also insert a macro for the toolchange which may not include a M6 command - what do you (or more importantly what do I have the parser look for) use instead of M6 then
I'm hoping for something like

(start of toolchangemacro)
G28
G10 L2 Z0 etc etc
(end of toolchangemacro)

So basically I can look for the two comments and know gcode before start is "the job", between the comments is the "toolchange macro" and after end, is the next section with the new tool. (so the dropdown can reflect accordingly. When you get to the macro, we either let you manually do it, or run the macro

@petervanderwalt
Copy link
Contributor Author

@gmorse7 yours looks good too:

file2

But I dislike how it looks in the 3D viewer (; - so will fix that for you too (;

@swarfer
Copy link
Collaborator

swarfer commented Sep 5, 2019

@swarfer :

Here is a SketchUcam file with tool changes. This is created by generating a file for T1 and another for T2 and then using the joiner tool to join the files together.
Looks like it worked (:

yep

I checked the file and I do see it having the headers from the joiner as described.
But for Sketchucam can also insert a macro for the toolchange which may not include a M6 command - what do you (or more importantly what do I have the parser look for) use instead of M6 then

in this case there is no way to automatically split the file as we have no idea what a user may put into the toolchange macro. none at all since the macro is user defined. the point of the macro is to do the tool change without stopping the job so using it and then expecting CONTROL to cooperate with it is a bit of a stretch.

@petervanderwalt
Copy link
Contributor Author

petervanderwalt commented Sep 5, 2019 via email

@sharmstr
Copy link
Collaborator

sharmstr commented Sep 5, 2019

How close is this to being released? Not pressuring, but the fusion post will need to be adjusted. Just wondering how much time I have :)

@petervanderwalt
Copy link
Contributor Author

petervanderwalt commented Sep 5, 2019 via email

@petervanderwalt
Copy link
Contributor Author

So something like this: Just before the M6, streaming stops, this pops up:

dialog

(also playing with the idea of instead of a dialog popping up, I show this where the 3D viewer usually is)

You use the regular tools/macros etc to effect the toolchange

then hit the Play button up top (its description now says Continue)

@sharmstr
Copy link
Collaborator

sharmstr commented Sep 5, 2019

I like it. Can you clarify a few things?

1 - I'm assuming the cutter image will always be the same. If so, I guarantee someone will ask why its not showing their v-bit. LOL

2 - After rezero'ing, will your continue button raise the cutter?

@petervanderwalt
Copy link
Contributor Author

petervanderwalt commented Sep 5, 2019

  1. no no - the boss really wants it to show the correct bits or at least close. It might be "best effort" by looking for keywords like "ball" or "flat" or "v"

  2. Hmmm, thats a good Beta testing question (: - i dont think the cam/posts give us a raise before/after the M6 right, so probably going to have to either do it for users (then i see the "z=5, vs G53 0 fights coming). But excellent catch this will need some debate for sure

@sharmstr
Copy link
Collaborator

sharmstr commented Sep 5, 2019

1 - Oh good luck with that. I can certainly help you with that on the Fusion end. And maybe even the Aspire end (though I only have the desktop version which doesnt allow multiple tools anyways).

2 - The Tormach sample I gave you does. Right after the tool change the first move is in Z to your clearance height before any x/y moves. But it doesnt look like the Autodesk version of grbl post does. Right after M6 it goes to x/y, then to your Z clearance height. That could be bad potentially. I can make sure in our version of the Fusion post that we move to clearance height first if need be, but probably best that control does it.

@petervanderwalt
Copy link
Contributor Author

  1. If not able to determine, show a cartoonish endmill lol
  2. yeah can be really bad, guess we can check what the first move is and decide whether to add one or something. Future Peters problem! hehe. And yeah we can can fix it in our posts, but you know people are going to load default/other posts etc too

@gmorse7
Copy link

gmorse7 commented Sep 5, 2019

Does the M6 triggered code raise to safe height and command a spindle stop?

Tool change user prompt window and text looks good to me.

@sharmstr
Copy link
Collaborator

sharmstr commented Sep 5, 2019

That should happen in the gcode before the M6.

Even your ToolChangeTestPiece doc above raises and stops the spindle before the M6 call. I've never seen a post that wont do that, so I think we are safe there.

Hmmm, as soon as I say that I now see that Davids file didnt have it. Well, shoot.

@gmorse7
Copy link

gmorse7 commented Sep 7, 2019

Fusion post processors handle tool change coding pretty well from what I've seen. I've added patches to move to a convenient tool change location in a couple of Fusion posts. I'm not sure about others. I see if I can create a couple examples from other CAM software.

@gmorse7
Copy link

gmorse7 commented Sep 14, 2019

The other attempts I've made to create multi-tool gcode files the software tells me GRBL does not handle tool changes (or at least their post processors don't).

@swarfer
Copy link
Collaborator

swarfer commented Sep 16, 2019

That should happen in the gcode before the M6.

Even your ToolChangeTestPiece doc above raises and stops the spindle before the M6 call. I've never seen a post that wont do that, so I think we are safe there.

Hmmm, as soon as I say that I now see that Davids file didnt have it. Well, shoot.

yes it does raise Z after the M6
this is the start of the second joined file which uses T2
(File: pockettester.skp)
(Bit diameter: 6.0mm)
(Join pockettesterT2.nc)
G90 G21 G49 G17 F1500
T2 M06
G53 G00 Z0 ; <-------------<< raise Z safely (-:
G00 X0 Y0

@sharmstr
Copy link
Collaborator

sharmstr commented Sep 16, 2019

(File: pockettester.skp)
(Bit diameter: 6.0mm)
(Join pockettesterT2.nc)
G90 G21 G49 G17 F1500
T2 M06
G53 G00 Z0 ; <-------------<< raise Z safely (-:
G00 X0 Y0

The question was "Does the M6 triggered code raise to safe height and command a spindle stop?"

(File: pockettester.skp)
(Bit diameter: 6.0mm)
(Join pockettesterT2.nc)
G90 G21 G49 G17 F1500
T2 M06
G53 G00 Z0
G00 X0 Y0
M3 S15000
G00 Z3.000

It moves up to safety height, but then moves to X0Y0 and sends a spindle start. Where's the M5??

@swarfer
Copy link
Collaborator

swarfer commented Sep 16, 2019

you are correct! the joiner specifically removes the spindle stops because you really do not want to stop the spindle when joining several operations with the same tool. but it leaves the M3 because the new tool may have a different speed.
I think CONTROL must stop the spindle whenever it finds an M6. this is the safe thing to do.

@sharmstr
Copy link
Collaborator

Agreed. But it should also allow for a spindle stop in the code (okay to be in there, but ignores it). That way my fusion code can work on other controllers :)

@gmorse7
Copy link

gmorse7 commented Sep 16, 2019

I agree with sharmstr, the spindle stop should occur immediately after the z retract.

@petervanderwalt
Copy link
Contributor Author

petervanderwalt commented Sep 18, 2019

I see I am going to need several more hours one this one (;
Like checking if there is an M5 if not offer one. Offer to raise Z (again the G53 vs Z+xxx problem (people with and without homing) etc

@sharmstr
Copy link
Collaborator

Yeah, sounds like a nightmare.

I havent tested this but I wonder if grbl will throw an error if 2 M5s are issued. Basically wondering if you actually need to "ignore" an M5 that already in the gcode. Having to ignore it will be a pain because you cant ignore the last one :)

@petervanderwalt
Copy link
Contributor Author

petervanderwalt commented Sep 18, 2019 via email

@petervanderwalt
Copy link
Contributor Author

Note to self, once implemented, remember to update Fusion posts etc to support Toolchanges

@rscamp
Copy link

rscamp commented Jan 21, 2020

Peter
Do you need any beta testers? FWIW I have experimented with the bCNC implementation for tool change with the standard GRBL F360 post and it seems to work okay.

@ghost
Copy link

ghost commented Mar 6, 2020

This looks very promising! Is there any way we can start testing this feature? Has this been implemented in master branch?

@diegocolonnello
Copy link

Waiting for this to happen, so happy with Openbuilds so far...

@petervanderwalt petervanderwalt moved this from In Progress to Planned Feature: CONTROL in OpenBuilds CAM and CONTROL Aug 10, 2020
@SeanDolan
Copy link

If I want to do a tool change in the same file, I enter a manual NC I’m Fusion to move the tool head out of the way then another entry for Stop. Measure the tool bit height off the table. Replace the bot and check the height is the same. OpenBuilds Control allows me to hit Pause then Resume and it continues the job. It might not be a resolution outright, but this might help some.

@sharmstr
Copy link
Collaborator

Measure the tool bit height off the table.

How are you taking this measurement?

@jacobgad
Copy link

I would love to see more attention on this feature i think it makes the whole proses of machining a part much more manageable. thank you for all your hard work

@southsideboats
Copy link

I wonder was this feature abandoned altogether. If I were smarter I would try and figure it out... it's one thing that makes a Shapeoko so much more user friendly.

@petervanderwalt
Copy link
Contributor Author

Not abandoned no, just haven't been a priority use case as our Post Processors are optimised to split the files for you: See https://docs.openbuilds.com/doku.php?id=docs:software:cam

In between files you have full control over jogging/zeroing/probing

@cecheverria
Copy link

Hi guys,

I know OpenSource is hard to maintain, but after 3 months of research, I've almost decided to change My OpenBuilds CNC BlackBox for Acorn CNC or StepCraft machine just for the mere fact of supporting ATC with not much pain. And I'm being really honest, I prefer to spend money on you guys if you come up with a solution for ATC.

But here we go respectfully asking you guys: Are you delivering soon ATC support, hardware/software? or is this feature just abandoned?

Thanks a lot guys..!

@swarfer
Copy link
Collaborator

swarfer commented Jan 28, 2023

From my side (the post processor) coming when I get my X32 set up and can test it.
The X32 runs GRBLhal which can/does support tool changes.
An ATC may require some custom compiling of GRBLhal or maybe just a macro inserted into the Gcode for each toolchange, this is quite easy to do in the post.

@cecheverria
Copy link

@swarfer, wishing you the best testing out on the new X32, please post what results you get on.

I'm not the master of CNC/macros, that's why I'm looking for a stack that solves complexity as much as it could.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
No open projects
OpenBuilds CAM and CONTROL
Planned Feature: CONTROL
Development

No branches or pull requests

10 participants