I am getting some strange behavior for the open builds Control software. It is inverting one of my arcs and skipping an entire part of my cut. The .gcode behaves normally and as excepted in other software. Please help. Using an in house post processor, but I have had zero issues with it prior to this. Other arcs and lines are not affected by this in the same sketch either. OpenBuilds Control: NCViewer:
The error could possibly be isolated around line 13197: G3 X340.122 Y1914.37 R44.45 where the arc is created.
If it fails to calculate the arc, the only reason is the numbers are off. We're just the symptom of an issue with the Post... Also, Grbl prefers IJK arcs, don't use the R format Note what Grbl's own developer says: "It's just not recommended". Change your post to use the better IJK format instead and all will be peachy
agree with the 'dont use R format'... as an aside, many of your line segments in the Gcode are about 0.1mm long. This means your file is 16000+ lines long when it could be much shorter, and all machines will cut smoother with longer lines segments (unless the short segments are actually part of a curve), but yours ar enot, since we see code like this Code: X66.114 Y1807 X66.163 X66.263 X66.362 X66.411 X66.461 Y1807.01 X66.51 X66.708 X66.758 X66.807 Y1807.02 X66.857 X66.906 X67.005 X67.054 X67.104 X67.153 Y1807.03 X67.202 X67.252 X67.301 X67.4 X67.449 X67.498 Y1807.04 Which is really a collection of tiny X movements with occasional tiny Y movements (0.01mm, can your machine even step 0.01mm?). Quite inefficient. My rough and ready filter script reduces your file to ~1600 lines by keeping only movements longer than 1mm. loads faster, cuts faster, screen redraws faster. but this should really be done in the post, and try to avoid all the little the 'single axis' moves since they do mess with my filter.
@Peter Van Der Walt - you do have to look at the OB display code. from about line 9170 in his file there is a long string of small motions without G1, many many lines before it gets to the 'faulty' G3, and that section does not display correctly until I add a G1 every few pages in my editor. @PIOPIO - the correct IJK format of that G3 would be Code: g1 X295.759 Y1956.04 G3 X340.122 Y1914.37 I44.822 J3.265 The I and J are offsets from the start of the arc (in the preceding G1). GRBL always uses incremental mode, there is no other option here. Further to my comment on the many tiny movements, If I filter out as many of the X (or Y) only movements as possible I get a very nice curve with ~1mm movements instead of 0.1mm movements.
Thanks for the replies Peter and David. I ended up finding a workaround, but some really good comments on how to improve our post and we're implementing the suggestions you guys have made. Hopefully won't run into this issue again. Thank you for the prompt and knowledgeable responses!
