Issue Parsing G4 Commands with Invalid Parameter

[sfroome]

Here are the steps I follow to reproduce the issue:

1. Load a file that has a deliberate typo ( G4 X2)
2. Press Start.

This is what I expected to happen:

LinuxCNC should throw an interpreter error when the file is either loaded or attempts to run.

Either the program is not allowed to run at all, or it throws a fault when it reaches the invalid line.

This is what happened instead:

LinuxCNC does print a warning through gcode graphics upon loading the file and again upon running the program, but internally either an interpreter error is thrown and immediately reset or the interpreter error is never thrown. This means that the program proceeds when I press start, but then gets stuck on the line with the typo.

While MDI commands and jogging can be performed after it gets "stuck", the bigger issue is the spindle remains turned on.

Information about my hardware and software:

• Gcode used:

G1 X0 Y0 U0 V0 F100

G1 X10 Y10 U10 V10
M3
G4 X2

G1 X100 Y53
M2

• I am using this Linux distribution and version (often, shown by lsb_release -a): Ubuntu 22.04.4
• I am using this kernel version (shown by uname -a):
• I am running a binary I built myself
• I am using this LinuxCNC version (shown in package manager or, for git versions, scripts/get-version-from-git): LinuxCNC 2.9.2
• I am using this user interface (GUI): AXIS
• I am using this interface hardware vendor and chipset (e.g., parallel port, ethernet port, FPGA card): Mesa 7i96S

[rmu75]

With lookahead for path optimization, the interpreter consumes more or less the whole file immediately and of course chokes on the G4 line and exits with an error. Up to this point motion segments are appended to a queue and emcmot is dutifully ececuting that queue until it is empty. I'm not sure if it is possible to retrieve the error in this case.

Perhaps the GUI should prevent running known-bad G-Code files, in other words, lock the run button if generation of preview yields INTERP_ERROR.

[satiowadahc]

status.interpreter_errcode successfully shows the error after loading a file, however it seems the error gets cleared after a few seconds.

[andypugh]

I wonder if the error flag clearing depends on the UI in use?

[satiowadahc]

Axis, QtDragon, Our custom one, all have the same issue.

[sfroome]

With lookahead for path optimization, the interpreter consumes more or less the whole file immediately and of course chokes on the G4 line and exits with an error. Up to this point motion segments are appended to a queue and emcmot is dutifully ececuting that queue until it is empty. I'm not sure if it is possible to retrieve the error in this case.

Perhaps the GUI should prevent running known-bad G-Code files, in other words, lock the run button if generation of preview yields INTERP_ERROR.

The GUI preventing running bad G-Code files would be the preferred outcome. LinuxCNC does appear to clear the error too fast in order to use it though.

To add, I did add some debugging statements in LinuxCNC to trace the error. The result value in parse_file (in gcodemodule.cc) does get set equal to 5 (aka INTERP_ERROR), but it seems like the interpreter_error is never really handled by emctask.