Extremely slow travel moves b/w purge block and print. Palette2
Phaedrux last edited by
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
G1 Z7.6 F0explain why
G0 X171.285 Y130.094 Z7.6would 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 last edited by DocTrucker
Seen recently that minimum feedrate is 0.5mm/min. I'll try to find the reference.
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 last edited by
@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 last edited by 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?
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.