Extremely slow travel moves b/w purge block and print. Palette2

Phaedrux

I'm trying to get the Mosaic Palette 2 working nicely with the Duet. I intend to write up a bit of a guide once I get things going smoothly. It hasn't been tested or designed with the Duet and RepRapfirmware in mind obviously, so there have been some hiccups.

Long story short, it looks like Chroma (their app to process sliced gcode) is inserting moves with a feedrate of 0, and this seems to be causing extremely slow travel moves between the purge block and print.

Here is a section of gcode from Cura:

G1 X140.738 Y151.177 E0.27392
G1 X142.518 Y152.956 E0.13039
M566 X1800 Y1800
G10
;MESH:NONMESH
G0 F12000 X171.285 Y130.094
;TIME_ELAPSED:426.846361
;LAYER:37
;MESH:geo_top.STL
G0 X171.285 Y130.094 Z7.6
M566 X900 Y900
;TYPE:WALL-INNER
G11
G1 F4200 X176.255 Y145.383 E0.83294
G1 X173.978 Y152.387 E0.38158
G1 X160.972 Y161.838 E0.83297

And here is the same layer change after Chroma processing

G1 X113.4775 Y170.5926 E0.84172 F3600
G1 X123.0234 Y170.5926 F3600
G1 X125.1772 Y168.4387 E0.15496 F3600
G1 Z7.6 F0
; leaving transition tower
G0 X171.285 Y130.094 Z7.6
M566 X900 Y900
;TYPE:WALL-INNER
G11
G1 X176.255 Y145.383 E0.83294 F4200
G1 X173.978 Y152.387 E0.38158
G1 X160.972 Y161.838 E0.83297

So would G1 Z7.6 F0 explain why G0 X171.285 Y130.094 Z7.6 would take over a minute to complete?

Looking at gcode files produced by canvas (their cloud based slicer) and Slic3r PE gcode after being processed by Chroma, they don't appear to contain the same feedrate 0 moves. I've only had a chance to do one print each with slic3r and canvas, and they were small, but I don't think they had such slow movements.

Other confounding factors that may or may not matter. The Duet is being sent gcode over USB by a raspberry pi 3b+ running octoprint.

I've already started a support thread with Mosaic with these details, but I'd like to clarify how the Duet would actually be handling a feed rate 0 move like that.

DocTrucker

Seen recently that minimum feedrate is 0.5mm/min. I'll try to find the reference.

Edit:
From: https://duet3d.dozuki.com/Wiki/Gcode#Section_G0_G1_Move

For CNC users especially: RRF has a minimum movement speed of 0.5mm/sec

I suspect the feedrate of 0 is being replaced by 0.5mm/min to save a complete hang. Perhaps in another firmware this means move as fast as possible? Bizarre if so.

Phaedrux

@doctrucker I suspected as much on a minimum feed rate. Thanks for that.

Now that the 2 hot print that took 8 hours finished I'll try again with the f0 removed.

Phaedrux

Can now confirm that manually editing the F0 to F6000 has completely solved the problem.

@dc42 Is F0 behaving correctly when in printer mode versus CNC mode? In other words, is this something that Mosaic needs to fix in Chroma to prevent generating F0 moves, or is it something that RRF should ignore when in printer mode?

dc42

In the absence of any specification about what F0 is supposed to mean in a G1 command, I think RRF is behaving entirely reasonably, and Chroma should be fixed.