Changing feed rate on the fly

[oskanaan]

Hi,

Is there a way to change the feed rate while the machine is doing a job? I am using the Universal gcode sender. I've tried a couple of other gcode senders but couldnt find that feature, either that or I am not looking in the right place .

Thanks!

[WillAdams]

I can’t think of any that do.

Lessee, for this to work we’d need to:

- have an on-screen control which allows one to adjust the speed
- as lines are being sent to the system we’d need to multiply each F value by the current speed adjustment

One problem I can see w/ this is that the system would lag by however many commands are currently in the buffer, already sent to the machine.

[PAPPP]

I assume you're using a grbl device of some sort, AFIK, grbl doesn't currently support feed overrides, they have it on the desired list for 1.0 but it isn't there yet.

The machine controllers that do the pulse generation/g-code interpretation/interface on the same host (Mach, LinuxCNC, etc.) can easily do overrides, and many of the 3D printer firmwares support a nonstandard M220 code for speed override percent. I expect grbl will end up using the same hack as the printers, and some time later the various senders will gain support for it. I'm always surprised by things that the grbl ecosystem hasn't re-inherited from the 3D printer world (Octoprint is damn similar to a self-hosted ChiliPeppr, Marlin has grbl as an ancestor but has become dramatically more sophisticated, etc.)

[cvoinescu]

Marlin has a less sophisticated motion planner, for instance. A lot of the work in Marlin went into 3D-printer specific stuff that's not really useful for CNC. Some went into features that require lots more pins, or more RAM and flash than the 328P has, but would be nice to have (such as SD card and LCD support). The feed speed override is one of the few things GRBL could reasonably import -- if GRBL still used the same planner from when Marlin had forked it...

[PAPPP]

Right, I was only talking down about grbl a little bit , it's pretty remarkable for still supporting 328p parts, and a lot of the Marlin magic is 3D printing specific. I was more remarking that the degree of separation between the additive and subtractive desktop manufacturing communities surprises me, and thinking "more sophisticated" in terms of supported kinematic system types, the screens and SD support you mentioned, and g-code dialect. It is certainly the case that they are pretty well filling out an ATmega2560 with 3-4x as many pins/timers/PWM channels/etc. to do so.

Feed override is definitely a fussy feature since it means the machine isn't actually directly doing what the gcode says, and in doing so interferes with look-ahead/buffering etc. I also know my LinuxCNC workflow tends to involve twiddling overrides to adjust out misbehavior, and I've been using overrides pretty heavily since Pronterface sprung a good override control for dealing with iffy bed adhesion or features (and also that I've had it do weird buggy things on subsequent prints when the override was in use, though to be fair that machine is running a rather ancient customized Marlin build).

I'm hoping for good things in terms of both features and re-unification to happen as the LCP17xx-based designs get dominant (which I'm pretty sure will happen), as much as I love working with AVRs and especially Arduinos, it really looks like the more capable devices will ease some of the inherent compromises of using serial-attached motion controllers.

[oskanaan]

Thanks for your responses guys, things are more clear now.

[cvoinescu]

I would not even go as far as the LPC17xx; I'd be quite happy with a Cortex-M0+, such as the Atmel SAM D21x family. That should keep us in Arduino-land, even though it seems only the "evil twin" of Arduino has a board based on that at the moment.

Although, on second thought, the Arduino Due is probably a better target (more pins!).

[PAPPP]

Sorry to totally derail, at least the question was answered...

Are there any [open source] motion control boards on M0+ parts in the wild right now? I was thinking of the LPC17xx designs because the promising Smoothie family stuff already has some traction. The LPCXpresso LPC1769 minimum-barrier-to-entry boards for that are like $25 (Not including motor drivers or big switching devices, the base model pre-integrated Smoothieboards and Atzeeg X5s are still around $100 - I keep watching because I've been trying to suppress a desire to build a midsize delta printer on one).

The Arduino internal drama makes me sad.

[aldenhart]

We've been laying the groundwork for feedrate override in TinyG for a while. There are a couple of things to go, but I think we are pretty close now. --Alden

[cvoinescu]

Good point, G2 works on Cortex-M3 (including Arduino Due).