Exposing settings_acceleration_override as a core M-Code

[Dietz0r]

Hey,
tinkering with the jerk settings for the motion planner sparked a discussion about using different machining profiles for different machining operations.
I know Datron has a 5 Step setup for different acceleration and jerk settings and Haas has 3 Profiles they defined as Roughing, SemiFinish and Finish .
I've successfully implemented a PostProcessor feature that simulates that behaviour with changing $120/121/122 on the fly in the g-code file

While sharing that with the community, I was told that there is a settings_acceleration_override function in grblhal that's only partially exposed in the openpnp plugin (No Z adjustments). And while this would be a much preferred solution since it's temporary overrides instead of changing controller settings directly i dont want to add mandatory plugins as a dependency for the grblHAL Postprocessor to keep it as general use for every grblHAL user out there as possible.

But i think this might warrant a core M-Code for grblhal since it would open up a lot of options to leverage different kinematics or programs for improved results and is found in lots of commercial controllers.

So could we please get this? :D

[terjeio]

In principle I am not too keen on adding "non-standard" gcodes to the core but may make an exception for this.
Is there a defacto standard such a gcode? From the link above it seems Haas uses G187.

... found in lots of commercial controllers

Are these using a common M-code or is each using their own?

[terjeio]

I went ahead and added preliminary support for G187 and up to 5 Profiles.

The HAAS spec is only for 3? So a grblHAL specific code should be defined instead?

First, the new code should be encapsulated in #if #endif to make it an compile time option. There are at least two reasons for this. First is that the new code may introduce bugs/side-effects that may affect users that does not need the new functionality. Second is that the new setting(s) will triggers a settings reset that will affect everybody that updates whether they need the new functionality or not.
I am also still of the opinion that G187 and G64 should not normally be enabled simultaneously in the code but could be made into a compile time option. This could be handled by one define in the same way I have done for the Modbus implementation by checking for bits in the #define symbol.

The next issue to handle is how to handle the new parameters. As I understand it G64/G187 should only affect motions sent to the planner after the commands are issued, not any that might already be in the planner. I have not studied the finer details of this but it could be that the relevant data has to be passed along to the planner instead of jerk and/or acceleration beeing overidden in settings when the commands are parsed.

[Dietz0r]

The HAAS spec is only for 3? So a grblHAL specific code should be defined instead?

Yep, HAAS only has 3. If you want to change to something grblHAL specific, i'm totally with you. I mean i asked for a M-Code before. :)

First, the new code should be encapsulated in #if #endif to make it an compile time option. There are at least two reasons for this. First is that the new code may introduce bugs/side-effects that may affect users that does not need the new functionality. Second is that the new setting(s) will triggers a settings reset that will affect everybody that updates whether they need the new functionality or not.

Will do, for both the Jerk and the Acceleration Profiles. 👍

I am also still of the opinion that G187 and G64 should not normally be enabled simultaneously in the code but could be made into a compile time option.

May I ask why? Maybe we're having different viewpoints or maybe something is unclear? I dont see the Problem with having both at the same time?

The next issue to handle is how to handle the new parameters. As I understand it G64/G187 should only affect motions sent to the planner after the commands are issued, not any that might already be in the planner. I have not studied the finer details of this but it could be that the relevant data has to be passed along to the planner instead of jerk and/or acceleration beeing overidden in settings when the commands are parsed.

As far as i am aware both of the options are "Idle-State" only changes? G64 P? Q? switches the way the planner handles junctions so the planner should be empty (or purged and rebuild?) when changing parameters or path control mode? And G187 switches the whole machine dynamic. And while i could come up with scenarios where it would be handy to switch the acceleration profile mid operation, I believe that the most use it has is to define the dynamics before or inbetween individual operations.

I have not studied the finer details of this but it could be that the relevant data has to be passed along to the planner instead of jerk and/or acceleration beeing overidden in settings when the commands are parsed.

I mean not changing the settings itself was the whole point of this thread. I could rig a gcode file that reads the needed $ entries and then modifies those too but it's not crash or usererror resistent. Or are you thinking about something else?

[terjeio]

The HAAS spec is only for 3? So a grblHAL specific code should be defined instead?

Yep, HAAS only has 3. If you want to change to something grblHAL specific, i'm totally with you. I mean i asked for a M-Code before. :)

If implementing G187 as HAAS compatible it should be according to that specification, if not another gcode should be selected, e.g. G327 or something like that. And it should be a G-code not a M-code since it will be in the core?

I am also still of the opinion that G187 and G64 should not normally be enabled simultaneously in the code but could be made into a compile time option.

May I ask why? Maybe we're having different viewpoints or maybe something is unclear? I dont see the Problem with having both at the same time?

Because I do not like having both available at the same time unless explicitly asked for at compile time. Select none, G64, G187 or both.

The next issue to handle is how to handle the new parameters. As I understand it G64/G187 should only affect motions sent to the planner after the commands are issued, not any that might already be in the planner. I have not studied the finer details of this but it could be that the relevant data has to be passed along to the planner instead of jerk and/or acceleration beeing overidden in settings when the commands are parsed.

As far as i am aware both of the options are "Idle-State" only changes?

Ok, then either error out or wait until the planner is empty before temporarily changing the settings.

I have not studied the finer details of this but it could be that the relevant data has to be passed along to the planner instead of jerk and/or acceleration beeing overidden in settings when the commands are parsed.

I mean not changing the settings itself was the whole point of this thread. I could rig a gcode file that reads the needed $ entries and then modifies those too but it's not crash or usererror resistent. Or are you thinking about something else?

I was thinking of reading from the settings in the parser and passing modified values along to the planner in the plan structure, not modifying the underlying settings values. Then the planner would read the values off the plan structure not from the settings directly. The code will be more logical this way, at least as how I see it.
The settings override function was added so that a plugin could modify the acceleration.

[Dietz0r]

If implementing G187 as HAAS compatible it should be according to that specification, if not another gcode should be selected, e.g. G327 or something like that. And it should be a G-code not a M-code since it will be in the core?
Because I do not like having both available at the same time unless explicitly asked for at compile time. Select none, G64, G187 or both.

oh god...
i think it just clicked why we're talking past each other.
You are talking about implementing the WHOLE HAAS routine ... G187 P-Value and E-Value and you are against having it alongside G64 because G64 the linuxcnc way does the same with P and Q values. I just wanted to implement the P-Values for the profiles and leave G64 alone. so i was sitting here all the time wondering why you'd be thinking pathblending and slower accelerations are a bad idea together.

for the record: i just want the profiles. i want to keep g64 like it is in linuxcnc and i dont want the g187 E-Values.
I'm with you in making it a grblHAL g-code if it is not exactly the same as HAAS's implementation so i'm ready to use whatever g or m-code you deem fit for those acceleration profiles and those alone.

I was thinking of reading from the settings in the parser and passing modified values along to the planner in the plan structure, not modifying the underlying settings values. Then the planner would read the values off the plan structure not from the settings directly. The code will be more logical this way, at least as how I see it.
The settings override function was added so that a plugin could modify the acceleration.

That sounds like a very elegant solution. Basically the structure goes as this $Setting -> write into variable of planner during block generation with all applicable modifiers -> generate block? and then the acceleration profile would just alter the modifier for the planner block variable. Wouldnt this also clear the problem of the Buffer being full when you call the acceleration change since it then already has the correct values present before generating more blocks?

[Dietz0r]

I've tried implementing this for the acceleration profiles now.
Added a global value for an active profile and using the limit_acceleration function of the planner with a lookup to adjust the max allowable accelerations before returning the limit_value, thus reducing the values that the machine moves at without changing the underlying settings.

and the gcode simply switches the active profile value.

Needs some testing now.