Live tool wear compensation

grandixximo wrote:

I can write function in C++ in the HAL file?

Well, sort-of. Comp (which is more like C) and in a HAL component.

linuxcnc.org/docs/html/hal_comp.html

grandixximo wrote:

I have read your post countless times, i still don't understand some things, you say to program a G10 L1 after every G1, but it's an error to write a G10 L1 while tool compensation on, so there is no recalculation unless i exit compensation and re enter it for each and every move.

I thought that you were trying to compensate something like a cylindrical grinder, where tool length is what needs to be compensated, not tool diameter. I that case I think you could continually update the tool length, though it would interrupt motion blending.

Wouldn't it be simpler to have a custom Mcode that set a pin to the wear value (managed with the cam according to the working distance), having this pin change gradually with limit.2, and then send it inside an hal component with the working direction from the kinematics, to calculate X and Y offsets.

Yes, this would be simpler, and there is actually no need for it to be an M-code. You could use a G-code analogue output into a HAL component.
The HAL component could track X and Y positions and calculate distance of cut, and then output offsets to be applied to the joint positions.

There is no way to do this at a lower level. The G-code is converted into a sequence of linear moves that are added to the motion queue and consumed by the real-time part of the motion system. A long straight move might be calculated once in the first microseconds of runtime, and then the actual move could last hours. Tool offsets are applied before the move gets to the queue and the tool offsets are not looked at again until the system hits a queue-buster such as toolchange (or, in fact, G10)
At least, I _think_ that is how it works, and it is likely to become more, not less, like that in the future.

grandixximo wrote:

When you say G-code analogue output, i think you mean M68, right?

No, M67. That gets inserted into the motion queue and doesn't break blending.

grandixximo wrote:

any suggestions on how should i get the direction pin out of the kinematics?

You could have a look at tangentkins: www.linuxcnc.org/index.php/german/forum/...t-to-path-xy?start=6

I will point out that it doesn't work perfectly. In an ideal world there would be a HAL pin directly driven by the motion planner.

grandixximo wrote:

How should i go at creating pins showing G41 or G42, can i do this in kinematics module also?.

I don't think kinematics is the natural place to do that.

In the development branch the current compensation mode is available to G-code as #<_comp> though that might not be any help to you:
www.linuxcnc.org/docs/devel/html/gcode/o....html#sec:parameters

I don't have access to the git repository at the moment, so I can't see the source code to work out if the required HAL pin already exists somewhere, though I think that the natural home for such a pin would be in halui
www.linuxcnc.org/docs/devel/html/man/man1/halui.1.html