kiri:moto arc moves incompatible with RRF2.x, work in 3.x
-
I am currently testing another slicer, the web based kiri:moto. It is an open source slicer running in the browser. One of the features it has is fitting segmented curves to Arc moves (G2/G3), much like the ArcWelder plugin for OctoPrint and Cura.
When running the generated GCode in simulation mode on my printer running RRF 2.0.5.1, I get errors:
Error: SetPositions called when DDA ring not empty Cancelled simulating file 0:/gcodes/MW_A-011.gcode after 0h 3m simulated time Warning: Tool 0 was not driven because its heater temperatures were not high enough or it has a heater fault Error: G2/G3: bad combination of parameter values
When running the generated GCode in simulation mode on another printer running RRF 3.3b1, the simulation completes fine.
The example GCode is attached below. A quick peek seems to indicate the G2 commands generated are valid (but I didn't check all 1900ish of them)
MW_A-011.gcode.I've also filed an issue with kiri:moto on this issue.
-
Printer configurations and versions:
RRF2.x printer at https://github.com/oliof/printerconfigs/tree/main/cr20/system
FIRMWARE_NAME: RepRapFirmware for Duet 2 WiFi/Ethernet FIRMWARE_VERSION: 2.05.1 ELECTRONICS: Duet WiFi 1.02 or later + DueX5 FIRMWARE_DATE: 2020-02-09b1
RRF3.x printer at https://github.com/oliof/printerconfigs/tree/main/v-core_pro/system
FIRMWARE_NAME: RepRapFirmware for Duet 3 MB6HC FIRMWARE_VERSION: 3.3beta1 ELECTRONICS: Duet 3 MB6HC v0.6 or 1.0 FIRMWARE_DATE: 2021-02-14 16:16:43
-
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.