Just curious if any of the code writers on this forum participate in GRBL development. If they do, maybe these functions could be introduced into a future version. It seems that several users are trying to push the capabilities of our entry level CNCs to make them more capable. Should those unsupported M commands be included?
That would be @chamnit — my understanding is that there was a major push to make Grbl as good as it could be on an Arduino — essentially done in v1.1 — and the next step is to change the focus to a different processor/board and to begin adding features.
It seems those commands would almost always require the sender app to handle them, as the controller doesn’t have any user I/O (there are no screens, for example, to display an instruction like to change a tool).
That’s correct. The Grbl on the Arduino Uno was made to be as good as possible with the most critical features prioritized due to limited space. The current development is not available online yet but it focuses on making the firmware abstract enough to be easily ported and allow others to add things fairly easily.
The timing of this couldn’t be more fortuitous.
I use Cut2D and am working on a project with multiple tools and thought it would be nice to output a single file.
The current post processor I’m using (G-Code Arcs (mm)) doesn’t support tool changing.
Which post processor are you using that supports both GRBL and tool changing?
Also, may I ask which version of UGCS you’re using?
Thanks for any help you can provide.
Adding the tool change to a V-Carve post is pretty simple.
- Commands output for tool change
to your post. I use GRBL (mm) with added support for Tool changes and dwells.
Does M6 work? Is your change all that is needed to make my G-Code arcs (mm) PP work?
It seems Bill had problems with M01 and is now using M00 and never mentions M06?
I’d like to avoid having to repeat his steps in deriving a solution if possible.
I’m 53 going on 54, trying to limit trial and error.
Sorry Phil. No, M6 won’t do anything by itself. Your sender would have to intercept the M6.
Bill was modifying the post to include all of the commands he needed for a tool change, replacing the standard M6.
If your Z probe location would be consistent (and not carved away), I think it’s doable, regardless of sender.
No problem, Neil.
I was just wondering if anyone had any simple tool changing code that works with GRBL (.9?) and Universal G-Code Sender (one of the later versions). All I really need it to do, is pause execution and allow me to jog and press my macro shortcut (F1) I use to re-zero the Z.
If anyone has anything like that and can share, that would be great.
I found what you were referencing. Wish I had known that earlier. The reason I selected the M01 in the first place was that when I was trying to get a grip on how GCode worked and was looking for a way to pause the machine, a search in the Wiki for available GCodes showed me there was no M00.
Here’s a snippet from the Wiki…
G94 ( G94:Inch per minute )
G95 ( G95:Per revolution feed )
G98 ( G98:Set Initial Plane default )
M01 ( M01:Optional Stop )
M02 ( M02:End of program…no rewind )
M03 ( M03:Spindle On )
M04 ( M04:Spindle CCW )
M05 ( M05:Spindle Stop )
M06 ( M06:Tool change )
I’m heading out to the shop this afternoon. I’ll look in later this evening.
I just tried replacing an M6 on a simple tool change test file with the following and it worked perfectly.
M0 ;pause to start process
G53 G0 Z-20
G53 G0 X-768 Y-340 ;probe location off workpiece
M0 ;pause to allow tool change and add probing wires
G38.2 Z-100 F100
G38.2 Z-5 F35
G10L20Z5.2 ;5.2mm was the predetermined difference between my probe height and my stock zero
M0 ;pause to remove probe wires, re-install dust boot, start spindle and vac
I’m attempting to modify the Shapeoko_inch_TC.pp to automatically insert the code for actually performing a tool change.
I’m using the Universal GCode Sender Platform Version available at https://github.com/winder/Universal-G-Code-Sender.
Tool Change Post Processors will allow you to create a GCode file with multiple tools, but will only insert the M06 Gcode in your program at the correct location. However, it does not insert the coding to actually carry out the tool change.
@neilferreri Neil is the one who explained that it was actually UGS that didn’t recognize the M06.
Hope this helps.
Unfortunately, jogging is disabled during a pause. That’s why it’s typically up to the sender to handle the M6.
Darn, I was hoping there would be essentially a pause option that UGCS would grab and then suspend execution while I made adjustments.
But at least I have some of the instructions and can google them with “UGCS” and see what others have done.
Very much appreciate the info guys!
I finally managed to get some time in the shop this afternoon to finish up the Post Processor modification.
The GCode program output by the Post works fine on my machine. The X,Y & Z locations are based on my XXL table and the height of my probe. I tried this out as a standalone gcode file run using UGS Platform before moving it inside the Post and it worked fine. By making it a part of the post, each program written will automatically have all the coding it needs built-in rather than pausing and running macros.
I use Vectric’s VCarve Destop software. Vectric lists 242 different Posts to choose from. If you use other software you may have to use one similar.
This is not a macro. I couldn’t find a way to get a macro of this length into UGS, ergo the Post route. The code is inserted into the Shapeoko_inch_TC.pp Post Processor found in the MyPost folder. If you use VCarve and don’t have that one listed when you go to save the GCode program, you need to copy if from the PostP folder into the MyPost folder.
I opened the Post using Notepad and scrolled down to the section shown below.
+--------------------------------------------------- + Commands output for tool change +--------------------------------------------------- begin TOOLCHANGE "M6 T[T]"
Removed the “M6 T[T]”
Then inserted my lines of coding in it’s place.
*** CAUTION ***: All instructions to be placed within the Post must be enclosed “within” quotation marks!
Then I saved the Post back to the MyPost folder. I went back into VCarve Desktop. Loaded the small two-tool test program that cuts a 1/4" x 2" and a 1/8" x 2" profile, one under the other. I then saved the GCode file using the modified Post.
After manually zeroing the workpiece XYZ to begin, the program cuts the first profile with the 1/4" tool then it runs into my code… Posting doesn’t seem to allow tabs, so reading this might be a little rough.
“G21” ; I work in inches, so Switch to Millimeters
“G0Z25”; Raise the bit and move to my
“G0G53X-700Y-830”; Tool Change Location hanging over the front rail
“M00”; and Pause. Change the tool and click continue.
'G0G53X-739Y-676"; The bit is moved to my probe location and pauses
'M00"; I place and connect the probe and click continue.
“G91G38.2Z-12.7F25.4”; The probe operation executes. My probe height
“G10L20Z19.30”; of 19.30 mm is made the Z height.
“G0Z5”; The bit is raised from the probe 5mm.
“M00”; Then a pause to remove the probe. Click continue.
“G90G0X0Y0Z0”; The bit is sent back to XYZ Zero.
“G20”; Switch back to “Inches” and the code for the second
profile line continues to the end.
This is my first shot at GCoding, so if you decide to give this idea a shot, please be careful. During testing, I manually inserted M00 commands like a Salt & Pepper shaker. Proceed a few lines, pause, proceed one line, pause… checking the GCode against what the machine was doing.
Anyway… over the next couple days, I’m going to sit down at the machine again and begin looking to see if I’ve made sure I’ve lifted the bit high enough for the various rapid moves in future programs etc.
Hope this helps. Please feel free to let me know if you see ways that it can be improved.
EDIT: Adding full GCode output file. Caution-- Do not run as-is on your machine.
Thanks for sharing the progress!
Is your probe on top of your workpiece?
I’d recommend a short dwell after the G10L20. That command writes to the EEPROM which takes time (insignificant amount of time for us, but might matter to the microcontroller). I’ve never had an issue with 1/4 second, but I’ve seen a half recommended.
No reason to send it back to zero unless you like the visual. Be cautious with the Z0, though. From there, your endmill might drag through something on its way back to where it needs to be. Especially if the router/spindle isn’t on yet.
For those just joining in…what Bill is doing here is creating and inserting a pure gcode snippet that can replace toolchange commands regardless of the CAD/CAM package or the machine control program. This would (should) work with any sender (there are some that do unexpected things with our machines, though).
Limitations would be that your probe location would need to be on your workpiece (if setting zero at the top of your workpiece), on your wasteboard (if using that as a reference) or at a known offset from one of those. I think that would cover most use cases. Problems might come when you carve your material surface away. There’d also be no adjustments once the job started as it’s part of the gcode file.
Just to understand how you envisage to use this in your work process.
You would use VCarve to produce your GCode then
open the text file in an editor
search for occurrence of M6
Replace the M6 with your standard GCode commands using a copy and paste
Save the updated file
Run the GCode using your GCode sender.
I guess that your Probe location would have to remain constant for each project or you would have to determine you probe location then modify your code to reflect this before inserting into the file.
Am I correct?
First, let me say that I do have a fixed location on my table that I use for most of my jobs. So, this procedure will only work for jobs that are placed in my fixed location bracket.
I created the bracket based on the video provided by Ben Myers at Myers Workshop. https://www.youtube.com/watch?v=RTthw9BU88I
Excellent video. Thanks Ben.
Here’s a pic of the bracket I use for positioning a workpiece so that each job will begin
at machine position X-755 Y-693.
With that said…
I’m not editing the GCode file produced by VCarve. I’ve edited the Post Processor that VCarve uses to produce your GCode file. That way each file you create with multiple tools will have the necessary tool change codes automatically inserted into them. You simply run your program and it will pause at the proper points to change your tool, connect your probe, probe the workpiece and allow you to remove your probe before continuing with the new tool.
You only need once insert the coding into your Post Processor. From then on, it will insert that coding into each program you create with VCarve.
Just a note…All XY positions used in the coding are Machine Coordinates accessed by using the G53 command. You would need to determine those locations you wish to use on your machine.
X-755 Y-693 is my bracket XY location.
X-700 Y-830 is my tool change location.
X-739 Y-676 is my probe location. Which is currently located on the workpiece’s lower left corner.
Hope this helps.
ps…Thanks to @neilferreri for his help and comments.
EDIT: Added my machine coordinates for reference to the code.
Thanks… I forgot that I saw several Dwell commands used in one of your other posts. I’ll insert that next time out in the shop and update my post.
Correct. That was a remnant from testing another pause that I removed before publishing.
The first instruction in the second tool cut raises the bit .2 inches before moving to the XY cut position.
Thanks for all your help.
Thank you for the clarification. Using the default position is great, I have something similar but I also use a center of the bed position for some projects. I guess that means making a copy of the Post Processor file for each instance.
That being said, while UGCS is unable to perform this, I wonder if CNCjs would be capable of doing this intercept. Neil @neilferreri already has several macros to perform tool changes, check tool length and reset Z0, in fact maybe it does already. I am still using CC and waiting on the availability of the CC probe but I see some of the limitations and advantages of changing to another code sender. CNCjs certainly appears to provide great features and abilities.