Faulty G-Code (maybe)

[gnrules]

Hi Tom,
I found a strange behaviour with a simple g-code file (see attachment)

Basically this file is a simple hole chamfer path replicated 6 times in a matrix fashion.
The strange thing is that in a random fashion, according to the coordinates used in file, the interpreted goes past the G0 statement even if that motion segment is still not completed. As a result kflop detects a following error and the axis is disabled. I payed attention to every single previous G0 line and the interpreter, correctly, does not proceed if the motion is not completed.

In the attached G-Code it happens at line 423 when positioning to the 5th hole (marked with arrow in the following code).

Code: Select all

...
G1 X111.4993 Y85.0 Z-2.0 
(Phase:Exit)
G0 Z19.5 
(Phase:Exit)
G0 Z99.5 
M9
(Phase:Approach)
G0 X149.499 Y35.000 Z99.500  <------
G0 Z19.500
(Phase:Direct Entrance)
M8
F250
G1 Z-2.000
(Phase:Open Profile)
F760
G1 X149.4993 Y35.0 Z-2.0 
...

It seems like the interpreted consider that line as a zero legth segment and passes over.
Please note that this happens only if we make a traverse X-Y combined move; if I change the line to make single axis move everything works fine.
i.e.

Code: Select all

(Phase:Approach)
(G0 X149.499 Y35.000 Z99.500)
G0 X149.499
G0 Y35.000
G0 Z19.500

Quite strange that the same code structure (but different coordinates) is repeated on ther previous passage from hole 2 to hole 3, but the problem does not arise. If I change slightly the overall coordinates (i.e. moving +-1mm left) the problem disappear or intensifies happening on every diagonal G0 move.
In simulation everything is ok.

I'm using 4.35f version with latest patch to GCodeInterpreter.
Params of TP are pretty standard, but we have CollinearTolerance to 0.0
Any idea?

Thanks

Giancarlo

[TomKerekes]

Hi Giancarlo,

Strange. I’m out of the office for a week and can look into it when I return.

So it is completely consistent with a specific GCode file until the file is changed?

You might try removing any patch to determine if it is related.

How are M8 and M9 configured? You might try removing those to determine if related.

Do you have any C Programs running?

Please post all your axis settings and KMotionCNC settings.

[gnrules]

Hi Tom,
the code I sent is just a part that reproduces the problem.
I left also the initial holes because, depite of the same path (apart from coordinates), it works as it should.
I repeated the test several times with consistent results.
I'll try to isolate the minimum relevant section.

M8 and M9 are simple bit switches for coolant. I can remove them in the next test.

The only C program is the main loop. It takes care of quite a lot of things, but I'll try to strip it to a bare minimum.
Do you have an idea of something in C code that can affect the interpreter behaviour?

I forgot to mention we are not using KmotionCNC, but our custom code in .net; this is the first time, however, this behaviour appears and no modification were made to the code since the end of the last year.
Moreover today 4 complex pieces were machined without any issue at all (about 4 hours machining with 4/6 programs).

I'm not sure that is not something caused by my code or C program ("maybe" in the title ), but I cannot imagine what can induce interpreter to skip a specific line of G-Code.
Anyway tomorrow I'll try to nail this problem reducing as many variables as possible.

thank you for your support.

Best regards

Giancarlo

[TomKerekes]

Hi Giancarlo,

I can’t think of a C example that would cause something like that other than something that corrupts something. Since it is reproducible you might just halt the C Program to see if it is related.

You might try running the GCode in KMotionCNC to see if it behaves the same.

[gnrules]

Hi Tom,
sorry for the late reply, but yesterday was holiday here in Italy.
BTW I made a few test on Friday and I can confirm that the problem is consistent, but it depends on the actual machine coordinates you run it on.
I stripped all unnecessary motion from the file and wandered around a bit to catch this behaviour (moving the G54 fix).
I finally found a spot that reproduces the problem each single time I run the code.
The I made some checks to better understand the source.

1 - If I change the G0 move to G1 everything works fine
2 - If I add a small amount to Zmove changing from G0 X111 Y35 Z99.5 to G0 X111 Y35 Z99.6 everything works fine (the previous command is G0 Z99.5)
3 - As previously stated if I separate each axis move (first X the Y) all is ok.
4 - I captured motion during event; X commanded position suddenly goes away from the planned path (as well as Y). This could be the result of skipping the G0 Line but still changing the destination. Please see attached pic.

I also begin to suspect something corrupting on my side. Can it happen for some faulty access to a pointer in C code (I mean accessing to wrong address)? I will try to reduce all the C code to its minimum (I don't know if I can stop it at all because of watchdog) and the repeat the tests.

[TomKerekes]

Hi Giancarlo,

Since it is repeatable it should be straightforward to track down. Since it shows in the commanded trajectory it shouldn't be dependent on any hardware. So you should be able to disconnect all hardware, set following errors to infinity, no watchdog, etc and still observe the problem.

If you do this I should be able to reproduce and help find the problem.