Extra G01, G02, G03's in code

[djreiswig]

It doesn't seem to affect anything, but I noticed the other day that in the g-code for some of my parts there are lines that appear with just a G01, G02 or G03 but no coordinates. Sometimes the next line has an X or Y without the GXX which kind of makes sense I guess, but other times it is a different move on the next line. So one line will say G01 and then the next line is G02 X10.500, but the G01is not followed by any coordinates.

I stepped through the post processor and tried to capture this issue in the OnMove sub. I inserted an if/then to check if any of the axes current values are different from the end values, and only put the GXX in if there was a difference. It still shows up.

It seems line sheetcam is calling for a move, but it shouldn't be since there is no move happening.
Not a big deal, just caught my attention.
I've tried the 11J post as well as one that I have made extensive modifications to and the code is very similar.

[Les Newell]

This can happen for very short moves. For example say your post is configured for 4 decimal places. If the move is 0.00001 then no number will be output. Simply checking if the coordinates are the same won't catch this because there is a move, even though it is tiny.
If you really want to get rid of them something like this at the beginning of function OnMove will work:
if (math.hypot(endX - currentX, endY - currentY) * scale) < 0.001 and endZ == currentZ then return end
You will have to tweak the number to suit the number of decimal places you use.

[djreiswig]

Thanks Les. I was wondering if it wasn't something like that. Sheetcam must work with highly precise values.
Would I also have to do something with the decimal places on the Z or isn't that an issue?

[djreiswig]

My post is configured for 3 decimal places ( 0.001 ) so I left the line as you posted it.
I am now missing a move. The old post showed a move of 0.001 from X4.873 on the previous line to 4.872 on the next line. This line is now missing. Probably won't affect the part, but where did it go?
I also now seem to be missing the G# for the line following the line that is missing. The coordinates are there, but there is no G02 or G03 at the beginning of the line. That would be an arc move, so I'm not sure how the straight move is affecting that.

[Les Newell]

Would I also have to do something with the decimal places on the Z or isn't that an issue?

Theoretically yes but such a short move on Z is very unlikley.

My post is configured for 3 decimal places ( 0.001 ) so I left the line as you posted it.
I am now missing a move. The old post showed a move of 0.001 from X4.873 on the previous line to 4.872 on the next line. This line is now missing. Probably won't affect the part, but where did it go?

This is where it gets complicated. Say the previous move was actually to 4.8725. This is rounded up to 4.873. Say the next move is to 4.8720. This will be output as 4.872 but the actual move distance is only 0.0005 so your code traps it.

I also now seem to be missing the G# for the line following the line that is missing. The coordinates are there, but there is no G02 or G03 at the beginning of the line. That would be an arc move, so I'm not sure how the straight move is affecting that.

What was the previous line? If it was an arc in the same direction you could well be missing the G02/G03.
As you can see it all starts getting messy. One option is to use non modal numbers (post.NonModalNumber) instead of modal numbers for your X,Y coordinates. That way they are always output even if they do not change. On the down side you will occasionally see moves where the coordinates don't change.

[djreiswig]

Gotcha. Rounding issues. How about I just don't worry about the extra lines of code.
Thanks.

[djreiswig]

Well, I thought about it some more and did some testing and it was as you stated, a rounding issue.
The test you proposed was comparing the unrounded values. I figured I needed to check the rounded values since that is what is being output.
So here's what I came up with and it seems to have taken care of it.

function round(num)
--round a number to 3 decimal places
return math.floor(num * scale * 10^3 + 0.5) / 10^3
end

function OnMove()
--removes errant moves smaller than 0.001" that will not output anyway
if round(endX) ~= round(currentX) or round(endY) ~= round(currentY) or round(endZ) ~= round(currentZ) then
local len = math.hypot(endX - currentX , endY - currentY)
dist = dist + len
post.ModalText (" G01")
post.ModalNumber (" X", (endX + offX) * scale, "0.000")
post.ModalNumber (" Y", (endY + offY) * scale, "0.000")
post.ModalNumber (" Z", (endZ + offZ) * scale, "0.000")
post.ModalNumber (" F", feedRate * scale, "0.0##")
post.Eol()
end
end

For whatever reason, I don't seem to be seeing the G02's and G03's with blank coordinates. I'm not sure if I should put some sort of test in the OnArc function to head off future issues, or if there is something different in the calculations where this issue won't happen there.

[Les Newell]

You won't see very short arcs because they get converted to linear moves. That's what minArcSize in function Init() does.

[djreiswig]

Yeah, I remember that now.
I was also wondering if I needed to include the offX, offY, and offZ in the calculation somewhere, but I ran the post with a scribe tool and didn't get any extra G01's showing up so I must not need to.

[Les Newell]

You should not need to worry about offX etc because they should never change while moving at feed rate.