Hello. I have this gcode: G21 G90 G40 G91.1 G0 Z25.0 ( T0 : 3.175 ) ( Tool Taper coming soon ) ( TOOL/MILL,3.175,0.0,0.0,0 ) ( Profile1 ) G17 M3 S1000 G0 X89.777 Y149.5782 G0 Z7.0 G1 F300.0 Z6.0 G1 F800.0 X89.6845 Y128.5012 Z0.3524 G1Y78.4732 G3Y78.4731I247.0697J70.5799 G3X184.4821Y74.767I247.0697J70.58 The G3Y78.4731I247.0697J70.5799 causes blackbox to just continue the move and dont stop until machine limit is reached. I played with arc precission ($12), replaced arcs with G1 in ugs, truncate the digits (default 4 - I set it to 6) - no change. Only if I set $12 to like 0.05 the controller or ugs (im not sure) says that the command goes beyond machine limits. The gcode was generated by cambam but I narrowed it down to just those lines to make it error. In the past I had cases where my workflow would cause the path to have very tiny loop which makes enormous arcs but not this time. The UGS visualizer shows the path correctly. It does the outline properly too. CutViewer simulates it properly as well. I used newest UGS 2.1.3 and im running blackbox x4 After I switched cam bam to use g1 instead of g3 I was able to complete the cut. But the whole path was a bit jerky... Can anyone point me into a direction what is going on?
[/QUOTE] hardly surprising it goes mad, this is invalid Gcode these lines put the tool at X89.6845 Y78.4732 G1 F800.0 X89.6845 Y128.5012 Z0.3524 G1 Y78.4732 then this line tries to cut a full circle, radius about 260mm G3 Y78.4731 I247.0697 J70.5799 GRBL does not like doing full circles, I am sure the GRBL post for CAMBAM knows this and should split all arcs into < 180 degree segments. the next arc is completely invalid. start at X89.6845 Y78.4731 and end at X184.4821 Y74.767 with center at X337 Y149 you cannot draw that arc at all, the start radius is ~257mm and the end radius is ~169mm and my test controller gives an error 33 invalid arc, as expected So, something wrong with the drawing, or something wrong with the postprocessor. If linearizing is giving jerky movement, then either the resolution is too small (many ,many very small line segments) or too large. set the linearize resolution to bitdiam/10. even bitdiam/5 works fine and you can probably not see the segments.
Thanks for suggestions. I wonder why cutviever or ugs visualizer does not show/detect those arcs. In the past I remember seeing those in mach3. It was easier to fix geometry then. I will play a bit with the points and regenerate the gcode. Will let you know if that helped.
Update, with the nodes/points moved a bit all Gcode with G3 arcs worked fine. I still wonder why the visualizer was showing that all is fine but the cut went outside of the intended path.
because most visualizers are not parsers, they are not trying to actually make the cut so they don't care if there are some errors, they just guess and carry on drawing.
but cutviever also did not had any issue with that gcode and it is supposed to actually simulate the cut. I also did not find the small loops in the node placement. I suspect the nodes were really close and for some reason that gcode was wrongly interpreted by blackbox.
No, the blackbox does not wrongly interpret gcode and does detect incorrect gcode, it is a mature product running thoroughly debugged code that is in use by hundreds of thousands of machines around the world. Your case is unique to your gcode, though arc errors as seen in your second G3 line are quite common (mainly because the math behind generating an arc from a start point, end point, and center offsets is actually quite hard to do correctly, especially for small arcs and for short segments of large radius arcs. The gcode you posted was quite clearly wrong, if you posted exactly what cambam generated, then cambam made the mistakes OR the drawing is/was in some way faulty that is causing the gcode to be incorrect. If you had posted the entire original Gcode file we could have helped with more detail.
