cnc machines...the basic three and four axis ones only make four moves....the hardest part about everything u guys are talking about is the g2 and g3 code aka block. this code/block defines an arc from where the tool is presently at...the final end point....and distance to center of the arc from where the tool is presently at.
can u or can u not handle that code/block...i have watched u guys ignore this code so many times...
the other two moves are linear...u can handle linear if u can handle the arc.
the rest can be rickety rackety but without the arcs u got nothing...
chip....by now i expected u to nail this one...why u not jumping in?
That particular project doesn't deal with acceleration / deceleration, but handling arcs is easier than you'd think. Most GRBL implementations / derivatives I've seen break arcs into linear segments to make the path planning code simpler, but handling them natively is clearly possible.
Ok, Einstein - show us how it's done. Two posts and all you have to offer is complaining that someone hasn't done something you suggest is easy, so go ahead - show us how easy it is.
Most GRBL implementations / derivatives I've seen break arcs into linear segments to make the path planning code simpler, but handling them natively is clearly possible.
JasonDorie,
I made my own CNC machine and did linear cuts only to keep it dead simple, figuring any arcs would simply be handled in preprocessing on the PC side. Looking at my sample generated "g code", doesn't seem to be that big deal size wise. (and I'm using serial link too) So if I ever released it as a commercial product, I shouldn't be too ashamed about this? I have no idea if this was common.
It's a very common approach from what I've seen. For my particular case, where I didn't have accel/decel planning, it ended up being faster to just run the step-accurate arc than to compute the linear segments. Computing the segments means you have to figure out when to stop subdividing, which means potentially expensive length computations and likely using sin/cos to compute the endpoints. Using an integer Bresenham circle algorithm I was able to run arcs with an inner loop that does very little math - mostly add/subtract/shift.
Comments
can u or can u not handle that code/block...i have watched u guys ignore this code so many times...
the other two moves are linear...u can handle linear if u can handle the arc.
the rest can be rickety rackety but without the arcs u got nothing...
chip....by now i expected u to nail this one...why u not jumping in?
start a cnc forum...
http://forums.parallax.com/discussion/163715/project-homebrew-laser-cutter
That particular project doesn't deal with acceleration / deceleration, but handling arcs is easier than you'd think. Most GRBL implementations / derivatives I've seen break arcs into linear segments to make the path planning code simpler, but handling them natively is clearly possible.
So let's see your version now.
but everybody will tell u that they can do great graphics and analog...i thought digital was easier...as long as it doesnt tequire math right.
tv is dead...da
JasonDorie,
I made my own CNC machine and did linear cuts only to keep it dead simple, figuring any arcs would simply be handled in preprocessing on the PC side. Looking at my sample generated "g code", doesn't seem to be that big deal size wise. (and I'm using serial link too) So if I ever released it as a commercial product, I shouldn't be too ashamed about this? I have no idea if this was common.
http://obex.parallax.com/object/85
Enjoy!
Mike