linuxcnc.stat.interpreter_errcode sticks at INTERP_ERROR once an error occurs and can't be reset

ZincBoy commented 3 years ago

Here are the steps I follow to reproduce the issue:

Using the python interface and version 2.8.1
linux.stat.interpreter_errcode will return INTERP_OK
Run an o code using linuxcnc.command.mdi that terminates with an (abort, msg)
After this linuxcnc.stat.interpreter_errcode will return INTERP_ERROR
linuxcnc.stat.interpreter_errcode will return INTERP_ERROR from then on
command.mdi strings can still be sent and will work correctly regardless of the state of stat.interpreter_errcode
linuxcnc.command.reset_interpreter() does not reset interpreter_errcode

This is what I expected to happen:

I expected the linuxcnc.command.reset_interpreter command to reset the interpreter_errcode but it does not. There does not seem to be a way to reset the interpreter_errcode to INTERP_OK. This happens in simulation as well as real-time mode.

This is what happened instead:

It worked properly before this:

I have not tested this on older releases so can't say if this is a new issue.

Information about my hardware and software:

I am using this Linux distribution and version (often, shown by lsb_release -a): Debian Buster
I am using this kernel version (shown by uname -a): Linux VK45 4.19.0-14-rt-amd64 #1 SMP PREEMPT RT Debian 4.19.171-2 (2021-01-30) x86_64 GNU/Linux
I am running ...
- [ X] A binary version from linuxcnc.org (including buildbot.linuxcnc.org)
- [ ] A binary I built myself
- [ ] A binary version from some other source besides linuxcnc.org
I am using this LinuxCNC version (shown in package manager or, for git versions, scripts/get-version-from-git): 2.8.1
I am using this user interface (GUI) (e.g., AXIS, Touchy, gmoccapy, etc): gmoccapy
I am using this interface hardware vendor and chipset (e.g., parallel port, ethernet port, FPGA card): Mesa Ethernet FPGA

andypugh commented 1 year ago

I have been keeping the email about this in my inbox since it was posted. I have finally got round to looking at it, and can't reproduce the problem. I am running this Python script.

#! /usr/bin/env python
import linuxcnc

codes = ["INTERP_OK", "INTERP_EXIT", "INTERP_EXECUTE_FINISH", "INTERP_ENDFILE", "INTERP_FILE_NOT_OPEN", "INTERP_ERROR"]
s = linuxcnc.stat()
s.poll
print(codes[s.interpreter_errcode])
c = linuxcnc.command()
c.mdi("O<abort_test> call")
s.poll
print(codes[s.interpreter_errcode])
c.reset_interpreter()
s.poll
print(codes[s.interpreter_errcode])
exit(0)

Where abort_test.ngc is:

O<abort_test> sub
(abort, aborting)
O<abort_test> endsub
M2

Maybe remapping needs to be active? Do you remember if it was active during your testing?

ZincBoy commented 1 year ago

I am sure I had the T and M6 codes remapped when I encountered that issue. They were both remapped with gcode and used the default prolog and epilog python code. The code had to do with probing and I am pretty sure no T or M6 calls were made in the ngc called by python.

LinuxCNC / linuxcnc