Live tool wear compensation

If you know the rate of wear and it is constant just adjust your path with your cam program to account for the changing diameter.

John

grandixximo wrote:

but i don't think it will work since the torch control actually override and take complete control over the Z axis so it would not follow any Gcode inputted on the Z, but instead i need to follow the Gcode trajectory i just have to slightly modify it while working..

Part of the solution mught be to use the HAL "offset" component:
www.linuxcnc.org/docview/html/man/man9/offset.9.html
You could put that in the path between axis.n.pos-cmd and stepgen.n.pos-cmd (or the equivalent in your system).
How do you propose to measure the tool diameter?

grandixximo wrote:

The tool have a wear ratio of 0,12-0,13mm every meter, i would like to have this value as a tool setting, and then have also 2 buttons on the interface that i could press to increase and decrease the offset if needed to...

The two buttons on the interface to increase/decrease the offset are easy, using GladeVCP and the "offset" component that I mentioned earlier.

How do you think i should get the diameter, can i know how far the machine has move in G1, and having the diameter go smaller as the machine moves?

I am not sure how well that would work, I would imagine tool wear would be a strong function of depth of cut and material type.
Perhaps you could use a laser distance gauge to measure tool diameter?

Do i really have no way of changing the diameter of the tools while working, and force EMC2 to read the changes and act accordingly??

No, because to a large extent all the path calculations are done ahead of time using the tool diameter loaded at tool-load time. The trajectory planner uses a lot of look-ahead to blend the moves, many programs are fully worked-out before the tool hits the work, so there is no way to alter the tool offset then.

Ah, I see.

For some reason I was visualising a cylindrical grinding machine, and all my ideas made sense in that context.

You might be able to do something in a pre-processor. If you inserted a G10 L1 in the code after each G1, based on the length of the preceeding move then the new diameter would be available to the trajectory planner when needed (interpret-time rather than run-time), and the path would be compensated according to normal G41 rules
www.linuxcnc.org/docview/html/gcode_tool...-Radius-Compensation

Once the path is calculated then the next place to intervene is in the kinematics module. It is possible to calculate the tangent to the current path (though not very nicely) inside the kinematics, and then offset the joint position commands accordingly at run-time.
I have made a custom kinematics which uses a similar approach to perform automatic kerf-angle correction on a 5-axis waterjet. Your situation is much simpler.

Your kinematics file would need to export two pins, one for diameter and one for left/right compensation choice. You could then write a custom realtime component that integrates path length (probably using the motion.distance-to-go pin,) and outputs a tool-wear estimate. It could also take button input for manual tweaking. That would be written in comp, and look something like(Totally untested, not even written on an emc2 machine, purely as an example of how writing HAL components isn't all that hard)