Something I noticed today.

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

This is build 30253 from a few days ago install.

I’m also away from it for a bit but was just going through some of my test results from this morning and figured I’d mention it.

I’ll try a really slow setting when I get back out there later.

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

I’ve been following the group pretty close, not sure how I’m missing some of these re: first reported by Wolfmanjm

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.

sent you my git username over on hangouts.

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.

This is fixed up now.

@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.