HAL trigger M code

Hello Todd,

Feed Override does work actually, but the accelerated max speed for the 3D and 2D movements are become different. For reference i have attached one image where 2 different section is marked with numbers, mark 1 section has Z movement and mark 2 do not has Z movement this makes section 2D movement.

Now, when tool slide down from the leaf of flower if feed override set to 10% then speed reduce to some speed x but when running in between leafs the machine speed reach to 3-5x due to x-y acceleration. really required is feed percentage should set all the axis speed to same level and maintain that speed between part1 and 2.

Just to be clear:
Changing acceleration values during Gcode execution IS possible. But the changed values are only used AFTER the interpreter has encountered a queuebuster command (eg M66 E0 L0) in the gcode which forces a synchronization between the interpreter and actual motion control.
For an example of how to use custom MCodes to change ini values (eg axes-limits, -velocity and -acceleration ) see the included 'millturn' simulation config where these values are changed using M128/M129:
github.com/LinuxCNC/linuxcnc/blob/master...millturn/mcodes/M129

The queuebuster command (ie M66 E0 L0) is located in the preceding 'M428/M429' remap that call 'M128/M129' respectively:
github.com/LinuxCNC/linuxcnc/blob/master...ap_subs/429remap.ngc

The split in MCodes is necessary because it is not possible to set halpins directly through gcode but only through a hal command. On the other hand it is not possible to issue gcode commands to synch the interpreter using a hal command.

So what all this means is that changes to axis acceleration have to be inserted into the gcode program prior to program execution.

So It sounds like you are seeing parts of your code that are not reaching the programmed feed rate because of short line segments and acceleration limitations, but when you slow the feed override then those acceleration limited areas don't slow down the same as parts of your code that were not acceleration limited, is this correct? And you are asking for all parts of your code to slow at the same percentage regardless whether it was able to move at the programmed feed?

Todd Zuercher wrote:

So It sounds like you are seeing parts of your code that are not reaching the programmed feed rate because of short line segments and acceleration limitations, but when you slow the feed override then those acceleration limited areas don't slow down the same as parts of your code that were not acceleration limited, is this correct? And you are asking for all parts of your code to slow at the same percentage regardless whether it was able to move at the programmed feed?
 

Yes, Exectly Todd, slow each gcode line with the same speed.

Ideally your g-code should be designed and generated in a fashion that the tool is actually capable of achieving the programed feed rates. It isn't really a good practice to program code to execute at say F200 but the moves will only allow F40 and then expect to rely on that F40 as your feed.

Right now since the machine is trying to cut at the higher feed in the slow sections but "can't". When you slow the machine with the feed override, the slow sections will not slow down until the feed override percentage lowers the programmed feed rate below the actual capabilities of the machines parameter settings for those sections of code. So if the programmed feed is F200 but the machine can only reach F40 in a section, you would not see a reduction in feed in the slow section until the feed override is set below 20%.

If you were to insert realistic feed rates for the "slow" sections of code. Then the feed override should give you the results you are wanting.

Other things to do to improve this would be to increase the machine's acceleration capabilities in order to reduce affect of slowdowns caused by short moves. Run the code using G64 mode with more optimal blending settings (larger P and or Q tolerances.). Improve G-code optimization by using curves instead of approximating them with short line segments, increasing code segment lengths and making segments more co-linear (less corners). Really any thing you can do to make so the machine moves at the actual programmed g-code feed rate rather than at the limits imposed by the configuration settings/physical limitations.