kiri:moto arc moves incompatible with RRF2.x, work in 3.x
-
This sounds like the issue when you print a G2 or G3 arc of exactly 180 degrees, specifying a radius parameter (R) instead of the offsets to the arc centre (I and J), and the specified radius is slightly less than half the distance between the start and end points, or rounding error causes RRF to think that it is. It was fixed in RRF 3.2.2, however the fix wasn't quite right; so it was fixed again in RRF 3.3beta.
-
I can confirm that kiri:moto uses R notation and not I/J notation. It sounds like I will need to upgrade that machine to RRF3 then?
-
@oliof time to take the plunge!
-
I can see line 2968 might be a problem.
(All the g3s are NaN for the R parameter)G3 X-18.9677 Y9.8100 RNaN E0.6945
HERE'S my favorite GCODE viewer that does G2/3 right.
-
This might also be a problem.
G2 X12.7817 Y-7.4774 R21230140343422.7930 E0.0855 ; merged=2 len=3.2712 cp=15011976202389.71,15011976202366.37
-
Thanks for taking a closer look! I'll amend the bug report on the kiri:moto side.
-
@oliof it looks like each G2/3 move has the centre point (cp) in the comment after the command, so you could run a post processing script to use those as I and J values, rather than using R.
Ian
-
@droftarts thanks for the suggestion -- so far the kiri:moto developer was pretty responsive to bug reports, so I will hold off post processing unless they had a chance to look at this.
-
But now that it's established the GCode has invalid G3 commands, I think we should consider RRF3 being broken if it accepts
G3 ... RNaN
during simulation without throwing an error. @dc42 should I move that discussion to another thread, or keep this open? -
@oliof as they compute the centre point anyway, you could ask for a toggle to switch between radius/centre point G2/3 command generation.
Ian
-
@oliof said in kiri:moto arc moves incompatible with RRF2.x, work in 3.x:
But now that it's established the GCode has invalid G3 commands, I think we should consider RRF3 being broken if it accepts
G3 ... RNaN
during simulation without throwing an error. @dc42 should I move that discussion to another thread, or keep this open?I think the latest 3.1beta source code (but not the 3.3beta1 release) will throw an error on that line already.