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

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.

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.

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?