kiri:moto arc moves incompatible with RRF2.x, work in 3.x
-
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.