What are people using for cutter radius compensation? #385
Comments
|
@unicornswag : As far as I understand, cutter comp is generally used for tweaking the tool radius when a tool wears and gets smaller. In cam software, I would imagine this would be easy, because you would just need to adjust the tool radius you enter when you generate the g-code. If you do write a script of some sort, let us know, so we can ween the concepts later when Grbl moves up in processors. |
|
Cutter comp is used to compensate for tool wear. Not to offset the tool Regarding doing a shell script, it would be interesting to see what you -Edward On Wed, Apr 2, 2014 at 9:19 AM, Sonny Jeon notifications@github.com wrote:
|
|
Okay, sorry for the confusion, I am referring to general tool offsets. For example, I am using a 1/8 inch diameter bit, so all coordinates need to be offset by 1/16th inch from the center-line to account for this. If I write a shell script to handle this, I will definitely share it here. |
|
The functionality is there (in the G-Code standard) to enable CAD-like programming, i.e. having the G-Code identically reflect the geometry in the CAD file and have the CNC Control figure out the actual toolpath at runtime using tool parameters previously stored. It's not an easy job as it requires a fair amount of math with little room for error (in most cases you'll destroy the tool or the part if you get it wrong). The PC-based CNC Controllers do it (LinuxCNC, Mach3 etc.), but I don't think there's enough room or math-muscle on an Arduino for that unfortunately. If you're interested in the math involved (and don't have a copy of Peter Smid's book handy), see here and here. |
|
@unicornswag All CAM programs should allow you to input the cutter diameter to compensate when the G code is generated. Cutter Comp in the CNC program is used to compensate for the fact that your .250" diameter cutter is actually .245". |
|
@csdexter : Very nicely done with your g-code parser! I'm in the throes of re-writing Grbl's, and I'm glad there is something to reference and perhaps ween. There were some undefined things that I could not track down, such as:
|
|
I guess I might be in a little over my head with the math side of things when it comes to simultaneous x and y motion. However, straight vertical and horizontal feeds and arcs should be fairly simple just by adding or subtracting the radius from the original path. |
|
@unicornswag "Famous last words" :-) I was thinking the same thing and before I knew it it took me a couple weeks to get it right "just for straight lines and arcs" :D @chamnit Thanks for the compliment. The codebase I pointed to sacrifices smartness for standard coverage. In this case, this means the last value stored in F will be used, regardless of whether that makes sense or not (similar to what happens when you switch from inch to mm). This is consistent with what old (?) controllers are doing, because they have physical registers to hold the numbers for each of the letter addresses. Normal and careful usage would be to have a new F word on the same line as a G93 to G94 switch. I have no idea about the behaviour of G28.1/G30.1/G92.1 when axis words are present on the same line. If I were a controller manufacturer, I'd flip a coin and either extend the standard by having the .1 version store the given coordinates instead of the current machine position OR error out and call it a syntax error. Same goes for an F or zero. I would flip a coin between not moving (and thus acting like a light-speed G-Code parse check mode) and shouting to the user that F0 is not a good idea :-) |
|
G41 and G42 are absolutely crucial for using GRBL. I use a modern day diode laser cutter, coming from an industrial machine and can't believe there is no support for these G-codes.. Actually this must be totally unacceptable to many users. Please please implement G41 and G42 into GRBL !! |
|
The terms "totally unacceptable" for an open source volunteer driven
project is an interesting choice of words. Do you understand that this
isn't a product that is being sold to you? How much did you pay for GRBL ?
Feel free to review the completely free and open source code and make
whatever modifications you dream of.
None of the contributors for this project get any form of compensation. If
this is something you need, then you could a) do it yourself, b) hire
someone to do so, c) ask in a really better way to see if someone would be
willing to drop what their doing and perform this work for you free of
charge.
…-Scott
On Tue, Jun 11, 2024 at 4:30 PM bwoostdam ***@***.***> wrote:
G41 and G42 are absolutely crucial for using GRBL. I use a modern day
diode laser cutter, comming from an industrial machine and can't believe
there is no support for these G-codes.. Actually this must be totally
unacceptable to many users. Please please implement G41 and G42 into GRBL !!
—
Reply to this email directly, view it on GitHub
<#385 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAEQC2B3J6ZGQ4VMASLKFKLZG5M65AVCNFSM6AAAAABJFBJ5KSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCNRRGU2TMNRRGU>
.
You are receiving this because you are subscribed to this thread.Message
ID: ***@***.***>
|
|
Reviewing the history of this issue, GRBL running on the Arduino is an
exercise in optimization and priority. There simply isn't enough resources
on the chip to perform every feature, this is likely the reason why it was
not implemented.
See above comment. Porting this to a larger micro with more resources would
allow likely many features that are not currently implemented.
The solution above is to simply use the vary capable CAD/CAM Post processor
to generate the modified gcode (as a work around).
If you think about it, it's super impressive that all of this runs on an
Atmega 328p that costs < $25.
I know there was some efforts many years ago to port this, I'm not sure
where it's at, I haven't gone back to look...
There might be some compelling hardware now that we are 10 years into the
future when this issue was first created.
…-Scott
On Tue, Jun 11, 2024 at 5:32 PM PHarmer.ai ***@***.***> wrote:
Reviewing the history of this issue, GRBL running on the Arduino is an
exercise in optimization and priority. There simply isn't enough resources
on the chip to perform every feature, this is likely the reason why it was
not implemented.
See above comment. Porting this to a larger micro with more resources
would allow likely many features that are not currently implemented.
The solution above is to simply use the vary capable CAD/CAM Post
processor to generate the modified gcode (as a work around).
If you think about it, it's super impressive that all of this runs on an
Atmega 328p that costs < $25.
I know there was some efforts many years ago to port this, I'm not sure
where it's at, I haven't gone back to look...
There might be some compelling hardware now that we are 10 years into the
future when this issue was first created.
—
Reply to this email directly, view it on GitHub
<#385 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAEQC2HJCFS2X5BYVXXF3BLZG5UH5AVCNFSM6AAAAABJFBJ5KSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCNRRGYZTGMJRHA>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
|
Yes, you are right. I apoligize for the wording. But I would like to explain myself a bit more. As an avid RC modeler I took to flying racing quads besides airplanes. I have seen the development in that field and we went from a Model T-Ford (awsome in its time) to a High-End SUper car in a mere 5 years or so. I declined the 3D printers because the things produced were for several reasaons not useable for me. I heard fellow modelers stories about how the driver boards progressed and the steppermotors become quiet because of higher driving frequencies because of the introduction of 32bit. I thought, just as with drones, that the MCU had been upgraded to a more capable model. Apparently I am wrong. I wrote my own geometry analysis software (gcode generator) for AutoCAD (and alike) and it functions well, but... totally depending on the assumption that G41 and G42 were possible. It never occured to me that the millions of 3D printers, vinyl cutters, laser-engravers (cutters) are all (still) running on the Atmega. As I am not capable of joining in on the GRBL delevopment I will investigate the complexity of implementing G41/G42 in my own code. Thank you for your response and enlightenment. I hope someone will have a bright idea on how to implement this in GRBL. As the number of diode laser-engravers(cutters) is rising, the need for it might inspire some new developments. Besides, I am surprised to learn that all these 3D printers etc. worldwide are running on the free GRBL. That makes it an AWESOME achievement. Apologies indeed well deserved and given. |
|
I believe the most common port of grbl to 32 bit ARM processors is grblHAL: https://github.com/grblHAL I think most modern 3D printers use firmware like Marlin or Klipper that has lots of extra 3D printing specific functionality. |
|
Implementing G41/G42 on the current device is probably never going to
happen. Porting it to another device and expanding its features will
require some serious time and dedication.
In the meantime, if you're trying to get some production off the ground,
you could take a look at the likes of Mach4 (Has extensive G/M-Code support)
https://www.machsupport.com/wp-content/uploads/2014/05/Mach4%20Mill%20GCode%20Manual.pdf
If I see anything out there, I'll drop a line, there have been some forks
of this project, but nothing I've seen has really gained traction.
…-Scott
On Wed, Jun 12, 2024 at 2:23 AM bwoostdam ***@***.***> wrote:
Yes, you are right. I apoligize for the wording. But I would like to
explain myself a bit more. As an avid RC modeler I took to flying racing
quads besides airplanes. I have seen the development in that field and we
went from a Model T-Ford (awsome in its time) to a High-End SUper car in a
mere 5 years or so. I declined the 3D printers because the things produced
were for several reasaons not useable for me. I heard fellow modelers
stories about how the driver boards progressed and the steppermotors become
quiet because of higher driving frequencies because of the introduction of
32bit. I thought, just as with drones, that the MCU had been upgraded to a
more capable model. Apparently I am wrong. I wrote my own geometry analysis
software (gcode generator) for AutoCAD (and alike) and it functions well,
but... totally depending on the assumption that G41 and G42 were possible.
It never occured to me that the millions of 3D printers, vinyl cutters,
laser-engravers (cutters) are all (still) running on the Atmega. As I am
not capable of joining in on the GRBL delevopment I will investigate the
complexity of implementing G41/G42 in my own code. Thank you for your
response and enlightenment. I hope someone will have a bright idea on how
to implement this in GRBL. As the number of diode laser-engravers(cutters)
is rising, the need for it might inspire some new developments. Besides, I
am surprised to learn that all these 3D printers etc. worldwide are running
on the free GRBL. That makes it an AWESOME achievement. Apologies indeed
well deserved and given.
—
Reply to this email directly, view it on GitHub
<#385 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAEQC2BLTSPFL4VQFAUAT5DZG7SM3AVCNFSM6AAAAABJFBJ5KSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCNRSGE4TKOJTG4>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
|
Thank you all for your suggestions. I did look at GrblHAL but as an former MCSE I already realized beforehand what HAL means. Reading the documentation confirmed that GRBL itself is not different. The HAL was created to prevent forking of the source. |
|
grblHAL is a fork of grbl that supports many 32 bit processors, has lots of additional features and improvements, and is still under active development. You are mistaken if you think the core is no different from that in the 8 bit version of grbl. The documentation describes it as "a rewrite of grbl 1.1 aimed at 32-bit processors". |
|
Then I need to invetigate further. I read this: https://www.grbl.org/what-is-grblhal |
Like the title says, I'm curious as to how (or if) people are implementing cutter radius compensation in their work with grbl. Since the standard G41/G42 codes are not currently supported, it would need to be handled by the cam software or some sort of post-processor that alters each coordinate to match the tool. Most simple 2.5D CAM software such as dxf2gcode either don't do offsets at all or use G41/42. I may end up writing a shell script that can convert standard g-code with no offsets to tool-specific code with a specified left or right offset. Unless there is an easier way?
The text was updated successfully, but these errors were encountered: