Why doesn't feed rate override work while milling?

Why doesn’t feed rate override work while milling?

From what I see it modifies the Gcode so once the feedrate is sent there is nothing to change. Mach3 seems to modify the feedrate state in real time, which is what I think you are talking about. I miss that in Chilipeppr but to me the biggie is the memory limits that really killed a lot of my plans for using it on larger machines.

It can only change feed rate on the way into TinyG. So your planner with 32 gcode lines is already in there, thus the feed rate override only takes place after the 32 lines are chewed through.

I can’t even change it. It’s disabled. I push the play/start job button and it can’t update feed. Only when I stop it all first or start from scratch.

Oh, that’s the Gcode widget feed rate override you’re talking about. Screenshot would’ve helped us understand what you were talking about. Yeah, once you hit play you cannot change that value. If you have TinyG you can override in near real-time in TinyG widget.

Can you explain how you do that? Is a command you can type in the console?

Or is that in a video?

@jlauer thanks for that Sir!

Might be the time to inject that the “near real time” injects the new feedrates but there is some error I kept getting doing it where the machine stalled at the same spot every time it was on but ran fine using the OTHER override (confusing at first to me what was going on). I can get the SPJS -v but it was very consistent with my relief files that were in the range of 50x50mm and very consistent when z is increased from 2-4mm. The depth is really expensive. I just avoid it now.

I remember hearing Grbl can do change of feed rate well running with latest version. I do not believe ChiliPepper’s can take advantage yet.

@Peter_Hanse it should be able to do so in the grbl1.x experimental workspace jpadie. Luca and I implemented it but I have not tested it. the grbl specific overrides are in the grbl widget, not the gcode widget

Is their a listing of other workspaces?

I’ve thought about doing an auto-list of workspaces, but there’s so many it would get massively confusing. For now searching the Google+ forum might be best. The goals is to always get the best/latest changes pushed to the main production workspaces. We should attempt to get the jpadie workspace pushed into main Grbl soon as long as it is backward compatible with all versions of Grbl.

I think we should make directory that you can list your workspace in and give updates of work you have done and it’s limitations or items not working bugs.

it’s not in a ready state yet @jlauer . I’ve broken the contiguity of dimensions across gcode, grbl, reporting and axes. and the settings system needs work.

@Justin_Adie do you think it makes sense to have 2 main Grbl workspaces then? A pre 1.1 and a 1.1 and greater? That would be confusing for users, but the Grbl 1.1 changes seem significant enough maybe that’s just the reality of the platform now.

the workspace that Luca and I worked on is backwards compatible. it reconfigures itself depending on the detected version. the design goal was that it could be pulled into the main workspace.