wishlist

[Noobman]

If possible, i would suggest that having a start.gcode and end.gcode implementation would be quite useful. For example i have a procedure to put milling bit on top of the pcb for height adjustment and i normally use that as start.gcode.

Also one part which could be better is to have the moves made at elevated height as a travel speed, faster than the milling speed (at milling depth). Basically to have a travel speed for moving from one polygon to the other (at high Z). This would be neat for non-voronoi paths which generates more travel moves than otherwise.

[Traumflug]

Yes, start- and end-gcode read from a file is an excellent idea.

Movements above the PCB surface should be at travel/rapid speed already, written out as G0. Is there a configuration where it isn't?

[Noobman]

Dunno, in my case it seems to be done at the same speed. I see them as G0, but i should look at how my setup interprets F123, for some reason seems to keep it for both. To be fair i did messed up firmware g-codes quite a number of times now. Or perhaps if it would possible to have as an explicit G0 .... F123 it may be better.

And woau, this is the fastest response i ever had, really ever.
I'm in the process of adding another issue which i get with gerber files from kicad making zig-zag voronoi paths, i am preparing the other post now.

[Traumflug]

G0 and F don't really work together. G0 means "as fast as possible" and that's different on distinct machines/printers. At least Teacup firmware ignores a F on G0 moves and replaces it with MAX_FEEDRATE. To me it looks like your controller doesn't interpret G0 correctly.

[Noobman]

Aha you are right and i will check and patch the G0 on my firmware with max_ speeds. Indeed this makes a lot more sense than my initial thoughts. Thanks for clearing me up on this.