Possible Bug in G-code Interpreter

[gnrules]

Hello,
I report a possible bug in g-code interpreter in 4.35b (no mention found in next test releases).

I'll try to explain at my best:
during simulation of g-code I noticed that, if you have tools with different length offset (as usual, but I noticed in a case with big differences between tools), the interpreter fails to correct address Z coordinate if, after a tool change, we make a simple in-plane move before involving Z axis in any motion.
Let's make an example: suppose we have T5 with 100mm length and then T6 with 200mm length (just to better view the difference)

T5 M6 G43 H5
.....
G0 Z5
T6 M6 G43 H6
G0 X10 Y10 Z5

In this case everything is correct. But if I want to make first in-plane move a then Z move like this:

....
T6 M6 G43 H6
G0 X10 Y10
Z5

you will see, in G-viewer, that the tool will drop down in Z of the selected tool length and then, when interpreter executes (G0) Z5, it is restored at correct coordinate.
Looking under the skin, it is a normal behavious of the interpreter, because the G43 Hxx processing only updates the current_z of the interpreter and the find_ends function will only take into account possible deviation from current position due to tool radius compensation (just x and Y) but not in Z: in practice if there is not an explicit Z param in G0 line, the interpreter is stuck to current_z value that is correctly updated with tool length offset, but not in synch with programmed position if no explicit Z is given in G0. So I think it is perfectly normal that behaves like this.

Fortunately, in real life, we have to resynch position after a tool change, and this will cover the bug with respect to aactual axis motion. But it leads to a wrong visualization of the tool path and possible issues during operation (i.e. if position after tool change is not to be synch for any reason) .

I hope my explanation is clear

Best regards

Giancarlo

[TomKerekes]

Hi Giancarlo,

Sorry for the delay. This is complicated and I was trying to fully understand it.

But from what I see the behavior is reasonable.

you will see, in G-viewer, that the tool will drop down in Z of the selected tool length and then, when interpreter executes (G0) Z5, it is restored at correct coordinate.

Because a longer tool was inserted the tool tip will in fact drop down and be physically at a lower position. This is correctly shown by the GCode Viewer. On the next motion the plot shows a Black line from where the previous tool tip was to the new tool tip as a non machine motion "jump". And the DRO correctly shows the dropped down tool tip coordinate (-95mm)

If one then commands only an XY motion I believe the tool should only move in XY. I suppose what you are thinking is that the machine should do a possible XYZ diagonal motion from X10 Y10 Z-95 up to X10 Y10 Z5? Or possibly move to Z5 straight up then to X10 Y10? I think this might in some scenarios make an unexpected cutting motion through the part. I think it is reasonable to expect after changing the length of the tool to then require it to be positioned it to the desired height for cutting. Possibly a warning could be added something like "you have changed the length of the tool but not yet moved the tool tip to a specified height would you like to continue?"

[gnrules]

Hi Tom,
thank you for your answer. Yes I think it is reasonable, but, in general, it could happen only with manual tool change. With usual ATC, Z coordinate should change as result of the tool change procedure (and subsequent resynch will apply correct tool offset), so it is something you see on the simulation, but not in real part cutting.
I agree that a Z motion is not to be expected (because not commanded by the program), I was only wondering if it is correct to view this "jump" while during the real cut there is actually no jump at all (maybe it is useful for manual tool change, but in that case I think no one uses tool offset).

Apart from this consideration, I'm further investigating this thing because I have a strange behaviour on our software (vb.net based upon kmotion libraries). I think I have understood the problem, but I need some further testing before reporting it. The problem should be on our side but, linked to this particular approach of the interpreter.

In the next days I will try explain the details.
Thank you

Best regards

Giancarlo

[gnrules]

Hi Tom,
here I am again. I found an issue with this behaviour, but I think I found a workaround too.
Let me explain: we developed our control SW in vb.net. Unfortunately not all the C interfaces are exposed in vb.net.
So when we measure a tool (via C program and tool probe) and change on the fly the tool length offset (modifying interpreter.SetupParams.toolLengthOffset) it is a mess until a new power cycle occurs.
It happens because of the aforementioned behaviour and, in combination, a change in tool offset on the fly. The interpreter at the first motion does not update the Z coordinate (unless a Z motion is triggered) and the tool length is uncorrect.
Looking under the skin of KmotionCNC, when the offset is changed on the fly, along with tool offset update, it updates manually CurrentZ of the interpreter. this thing is not possible via .net.
We adopted a workaround calling a DoGcodeLine("G43Hxx") forcing the interpreter to update the offset via tool table and consequently updating CurrentZ. This is calid and acceptable only when interpreter is not busy so we have to manage a certain number of special cases (i.e. exit of simulation)

At the moment it is working well, but I'm wondering if there is a nother combination or sequence of operation that could lead to a possible mistake in tool length recognition. A wrong tool length is very upsaetting, because with a fast system like ours, it will destroy the mill and even make further damage.

Do you have any suggestion for a better management of the tool length offset?

Thanks

Best regards

Giancarlo

[TomKerekes]

Looking under the skin of KmotionCNC, when the offset is changed on the fly, along with tool offset update, it updates manually CurrentZ of the interpreter. this thing is not possible via .net.

I think updating the Interpreter's CurrentZ should be possible with this property. Does that help?

[gnrules]

Hi Tom,
that's great. I completely missed out that property; I thought was a readonly property.
In that case I think the better approach is to update the currentZ when Tool Length offset changes as in KmotionCNC.

Thank you.

Best regards

Giancarlo