Markers. They’re Magic for a reason.
1 Like
Oh yes they are …
1 Like
Yeah, they really require a different mindset. I really love these tools when I do regex work:
https://www.debuggex.com/
https://regexper.com/
(Might lower the amount of substances necessary for next time!)
1 Like
Fresh code, works a lot better (squashed two bugs), doesn’t delete the last commands at the end of the file. But still NQR (not quite right.
Anyway, the MothersDay gcode is still one of the best test files I’ve got, thanks.
git pull or clone.
Now it’s right, I found a weird little bug in my logic for DedupLinear that was allowing certain lines to be considered colinear when they weren’t.
Please retry.
1 Like
And I just fixed the bug that was causing it to drop the file terminators (the ‘%’ symbols).
So, any recommendations for weird and gnarly gcode? Although I’m not about to try expressions yet…
Much better, but still not quite perfect. It lopped off some of my 5x7 rectangles. This is from the latest on GitHub.
Jasonmothersday-gcc.nc (113.9 KB)
yep, I see that, I had to look very closely at the ‘rounded’ corners of those rectangles and I could see some (but not all) were still a little ‘lumpy’.
I’m thinking of adding a linear to arc dedup step, which should work on those rounded corners perfectly.
… and then I thought, I really should solve the lumpy corner problem first.
And it wasn’t DedupLinear being too ‘enthusiastic’, rather it was the clipping function.
It seems that inches do need 3 d.p. to work properly (so 100th’s), which shouldn’t surprise me really, because 0.01" = 0.254mm, which is very chunky.
1 Like
I’ve started on a line segment to arc dedup processing step now. And I’m getting an interesting result with @jnowell’s “MothersDay” file.
As below:
However, what’s confusing is that the path being followed means that all of the various radius center points should be to the same ‘side’ of the line, and therefore they should all be G02. But GroundControl and estlcam both give me this picture, until I change the commands for the lower left corner to G03.
Does anyone else have arcs going off in strange directions for different projects?
I’m going to assume that it’s my maths at fault here, so if someone know this bit of the code it would be handy.
Here’s the ‘special’ Mother’s Day file:MothersDay-gcc.nc (134.2 KB)
Ahh - figured out what I’m doing wrong (and by extension what estlcam and Groundcontrol are doing wrong) - I’ll get to fixin’ my code.
The I and J arguments I’m supplying are wrong and estlcam and GroundControl should fail them in some way.
how are they wrong? Inverted? I and J are curvature values for a clockwise or counterclockwise arc. this is intriguing.
It’s what should happen when they are incorrect (or the G2 / G3 X and Y are incorrect).
The NIST spec says that (ahem - clearing throat to read the proclamation):
It is an error if:
• when the arc is projected on the selected plane, the distance from the current point to
the center differs from the distance from the end point to the center by more than
0.0002 inch (if inches are being used) or 0.002 millimeter (if millimeters are being
used)
My mucked up numbers were out by rather a lot more than 0.0002 of an inch.
The next question is, what is the correct response when there is such a failure?
I’ve got the code to validate a G2 or G3 to those tolerances. But, I just can’t generate them yet … (getting closer I think).
Got there - The code is now in GitHub. However, for some gcode files the output may end up larger.
The DedupLinearToArc is currently only handling triplets of points. It needs to keep fitting points after the 3rd point, so long as the radius to center point is a fit.
I’ve also turned off the clip function until I can get the tolerance for arcs (using IJK) properly respected.
2 Likes
Since you are now fluent in gcode, do you know how to translate an X Y Z R gcode text to X Y Z I J gcode text? I would call it a line in the file, but it probably isn’t a straight line if R or I and J are being used.
do you know how to translate an X Y Z R gcode text to X Y Z I J gcode text?
Yep, But it ain’t pretty. It’s interesting (in a gcode nerd kinda way) that the NIST specs do not recommend using R except for specific arc ranges (measured in degrees). To quote:
Nearly full circles are outrageously bad, semicircles (and nearly so) are only very
bad. Other size arcs (in the range tiny to 165 degrees or 195 to 345 degrees) are OK
So working it through (apologies if I’m stating the obvious):
The preceeding line will give you your starting coordinates.
This current line, with the R, gives you your ending coordinates.
So its at the intersection of two circles (radius R) that are drawn at the starting and ending points.
Kinda like this:
So we need to solve that equation, and make sure we get the correct intersection of the circles (based on whether it is G2 or G3)
not obvious, just unknown to me. I’ll admit I did not yet study that NIST document. It sounds like an incredibly gripping narrative.
1 Like
It is a scintillating read, full of gripping narrative and devious characters.