Something I noticed today. No matter what my default travel speed is set to in the smoothie config or what the travel moves value is set to on the gcode settings tab, my machine seems to default to the last used F value when skipping white space on a raster image.
So if my last command was something like G0 X0 F10000 then it seems 10000 is the speed it uses when it skips over the empty areas on a raster. If my last command was G0 X0 F100 then it uses 100 as the speed to skip the empty areas.
So with that in mind what exactly does the Travel Moves setting do on the gcode tab?
If you updated today then this could be a side effect from a feature to keep the last jog speed. Please imput there something really really slow like 5mms for XY and see if that’s it. I’m away from the machine for a couple of houres
Well it all started a couple of days ago, the build number will not shows every change. Of course it all depends when was the last time you did a git pull
Oh and I hope you guys don’t mind me posting bugs as I find them.
I’m a developer by trade (.Net/C#/MVC) but don’t know much about the graphics side or the gcode generation. But if I can help on the UI I’d be happy to.
I can put that fix in; I’m at my computer. @Carl_Fisher The way many of the GCode commands works is “sticky”: if you omit certain parameters, the firmware uses the last value for that param. So, Issuing a G0 command with a feedrate sets a “sticky” feedrate for future G0 commands that omit the feedrate. The problem here was that the feedrate was accidentally set on G1, not G0, so future G0 moves used whatever last value was specified.
@Monte_Krol I saw the check in for that, very cool and thank you. I’ll pull an update tomorrow as I don’t know if I’m going to get back in the shop today.