Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

interp error in 2.9.3, started somewhere between 2.9.3-83-g1d5d02d836 and 2.9.3-2099-g9f5a1c8f50 #3174

Open
Lcvette opened this issue Nov 10, 2024 · 23 comments
Open

interp error in 2.9.3, started somewhere between 2.9.3-83-g1d5d02d836 and 2.9.3-2099-g9f5a1c8f50 #3174

Lcvette opened this issue Nov 10, 2024 · 23 comments

Comments

@Lcvette
Copy link

Lcvette commented Nov 10, 2024 •
edited
Loading

Here are the steps I follow to reproduce the issue:

  1. start axis sim from terminal
  2. look for USRMOT: ERROR command 30 timeout and emcMotionInit: emcTrajInit failed
  3. load the tool table with tools for a program and then load the program, on screen error message occurs: "parse_file interp_error"
  4. Terminal error shows as:

py3dev@py3dev:~/linuxcnc/configs/sim.axis$ linuxcnc axis.ini

LINUXCNC - 2.9.3-2099-g9f5a1c8f50

Machine configuration directory is '/home/py3dev/linuxcnc/configs/sim.axis'

Machine configuration file is 'axis.ini'

Starting LinuxCNC...

linuxcncsvr (8811) emcsvr: machine 'LinuxCNC-HAL-SIM-AXIS' version '1.1'

linuxcnc TPMOD=tpmod HOMEMOD=homemod EMCMOT=motmod

Note: Using POSIX realtime

milltask (8824) task: machine 'LinuxCNC-HAL-SIM-AXIS' version '1.1'

halui (8826) halui: machine 'LinuxCNC-HAL-SIM-AXIS' version '1.1'

Found file(lib): /usr/share/linuxcnc/hallib/core_sim.hal

Found file(lib): /usr/share/linuxcnc/hallib/sim_spindle_encoder.hal

Found file(lib): /usr/share/linuxcnc/hallib/axis_manualtoolchange.hal

Found file(lib): /usr/share/linuxcnc/hallib/simulated_home.hal

Found file(lib): /usr/share/linuxcnc/hallib/check_xyz_constraints.hal

Found file(REL): ./cooling.hal

USRMOT: ERROR: command 30 timeout

emcMotionInit: emcTrajInit failed

note: MAXV max: 5.000 units/sec 300.000 units/min

note: LJOG max: 5.000 units/sec 300.000 units/min

note: LJOG default: 0.250 units/sec 15.000 units/min

note: jog_order='XYZ'

note: jog_invert=set()

!!!emc/rs274ngc/gcodemodule.cc: parse_file() f=/home/py3dev/linuxcnc/nc_files/aa_error_test.ngc

!!!interp_error=1 result=2 last_sequence_number=16

It worked properly here: 2.9.3-83-g1d5d02d836

It shows error here: 2.9.3-2099-g9f5a1c8f50 (and possibly in between but i didn't test any of those)

systeminfo

  • I am using this Linux distribution and version (often, shown by lsb_release -a):
    Debian 12

  • I am using this kernel version (shown by uname -a):
    Linux py3dev 6.1.0-27-rt-amd64 1 SMP PREEMPT_RT Debian 6.1.115-1 (2024-11-01) x86_64 GNU/Linux

  • I am running ...
    [X ] A binary version from linuxcnc.org (including buildbot.linuxcnc.org)

  • I am using this user interface (GUI) (e.g., AXIS, Touchy, gmoccapy, etc):
    Axis gui

  • I am using this interface hardware vendor and chipset (e.g., parallel port, ethernet port, FPGA card):
    sim
@rodw-au
Copy link
Contributor

rodw-au commented Nov 10, 2024

My take on this is you should not be using the Secret Buildbot Debs at http://buildbot2.highlab.com/ for version 2.9. The current release 2.9.3 is set by a tag "v2.9.3" in git and the Debs are available on the official Linuxcnc repository.
We say that bug fixes will be added to the release version but until and if v2.9.4 is released you can't depend on it.
You can follow heading 7.1 in the Getting Linuxcnc docs to restore the sources files to point to toe correct repo.

In summary. only use the secret Buildbot for 2.10 master branch and use the released Debs for 2.9.3

In my view, the developers got into some bad habits when we maintained two versions for such a long time. I don't understand why there has been a continual stream of commits to 2.9. It seems to be way more than bug fxes pending the release of 2.9.4. If that is required, we should have released 2.10 and get back to better code integrity.

@rene-dev
Copy link
Member

  1. is probably not related to the issue you are having.
    you are using a stock sim config?
    can you share the tooltable and program?

@Lcvette
Copy link
Author

Lcvette commented Nov 10, 2024

  1. is probably not related to the issue you are having.
    you are using a stock sim config?
    can you share the tooltable and program?

yes sim config for axis, files below:

test_files.zip

@Lcvette
Copy link
Author

Lcvette commented Nov 10, 2024

My take on this is you should not be using the Secret Buildbot Debs at http://buildbot2.highlab.com/ for version 2.9. The current release 2.9.3 is set by a tag "v2.9.3" in git and the Debs are available on the official Linuxcnc repository. We say that bug fixes will be added to the release version but until and if v2.9.4 is released you can't depend on it. You can follow heading 7.1 in the Getting Linuxcnc docs to restore the sources files to point to toe correct repo.

In summary. only use the secret Buildbot for 2.10 master branch and use the released Debs for 2.9.3

In my view, the developers got into some bad habits when we maintained two versions for such a long time. I don't understand why there has been a continual stream of commits to 2.9. It seems to be way more than bug fxes pending the release of 2.9.4. If that is required, we should have released 2.10 and get back to better code integrity.

sudo apt install linuxcnc-uspace

is this the correct release for lockdown 2.9.3 from apt?

@rodw-au
Copy link
Contributor

rodw-au commented Nov 10, 2024

sudo apt install linuxcnc-uspace

Yes. provided your /etc/apt sources files are set as per the install ISO defaults, otherwise you will get a very old version on Debian12 but a more current version (possibly 2.93) on yet to be released Debian13. (testing).
There is no automatic buildbot for Debian. The source has to be uploaded to them.

@rmu75
Copy link
Contributor

rmu75 commented Nov 10, 2024

changing tool numbers to something below 24 makes the error go away... is there some (new) limit how high tool number can be?

@Lcvette
Copy link
Author

Lcvette commented Nov 10, 2024

changing tool numbers to something below 24 makes the error go away... is there some (new) limit how high tool number can be?

that number seems to be a moving target and isn't repeatable, the first person who noticed it the threshhold was below 199, whe i tested it was below 105, so something fishy is happening i couldn't see or find. I spent 2 days thinking it was in our build trying to find where we broke to find there was no change that caused it. thats when we noticed it went away on different lcnc builds.

@andypugh
Copy link
Collaborator

andypugh commented Nov 11, 2024 via email

@rmu75
Copy link
Contributor

rmu75 commented Nov 11, 2024

debugging this, I get

!!!emc/rs274ngc/gcodemodule.cc: parse_file() f=/home/robert/tmp/test_files/aa_error_test.ngc
!!!interp_error=1 result=2 last_sequence_number=16
task: main loop took 0.014381 seconds
Traceback (most recent call last):
  File "/home/robert/CNC/linuxcnc-master/bin/axis", line 1089, in change_tool
    StatMixin.change_tool(self, pocket)
  File "/home/robert/CNC/linuxcnc-master/lib/python/rs274/interpret.py", line 151, in change_tool
    self.tools[0] = self.tools[idx]
                    ~~~~~~~~~~^^^^^
IndexError: list index out of range

https://github.com/LinuxCNC/linuxcnc/blob/master/lib/python/rs274/interpret.py#L151

seems that code there assumes tool index = tool number. also, gcodemodule.cc needs to be fixed so comment is consistent with code around line 917 and exception is reported.

@rmu75
Copy link
Contributor

rmu75 commented Nov 11, 2024

I'm not able to find commit 9f5a1c8 but will try to search from v2.9.3 release tag.

@rmu75
Copy link
Contributor

rmu75 commented Nov 11, 2024

can't reproduce on 2.9

@Sigma1912
Copy link
Contributor

My tooltable (6 lines):

T1  P1  Z1.9968  D0.125  ;1/8 end mill
T4  P4  Z3.125  D0.25  ;1/4 endmill
T6  P6  Z2.25  D0.25  ;1/4 chamfer mill
T7  P7  Z3.555  D3.937  ;100mm facemill
T68  P68  Z2.875  D0.257  ;.257 drill
T220  P220  Z2.958  D0.375  ;3/8 endmill

in the GCODE I have 'T6 M6' (which works) and later 'T7 M6' (which fails)

Seems that 'idx' in that section of 'interpret.py' refers to the line in the tooltable.

Debugging gives :

DEBUG: idx:  6
i= 0
self.tools[i]:  (-1, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0)
DEBUG: self.tools[i]: tool_result(id=220, xoffset=0.0, yoffset=0.0, zoffset=2.958, aoffset=0.0, boffset=0.0, coffset=0.0, uoffset=0.0, voffset=0.0, woffset=0.0, diameter=0.375, frontangle=0.0, backangle=0.0, orientation=0)
i= 1
self.tools[i]:  tool_result(id=1, xoffset=0.0, yoffset=0.0, zoffset=1.9968, aoffset=0.0, boffset=0.0, coffset=0.0, uoffset=0.0, voffset=0.0, woffset=0.0, diameter=0.125, frontangle=0.0, backangle=0.0, orientation=0)
DEBUG: self.tools[i]: tool_result(id=220, xoffset=0.0, yoffset=0.0, zoffset=2.958, aoffset=0.0, boffset=0.0, coffset=0.0, uoffset=0.0, voffset=0.0, woffset=0.0, diameter=0.375, frontangle=0.0, backangle=0.0, orientation=0)
i= 2
self.tools[i]:  tool_result(id=4, xoffset=0.0, yoffset=0.0, zoffset=3.125, aoffset=0.0, boffset=0.0, coffset=0.0, uoffset=0.0, voffset=0.0, woffset=0.0, diameter=0.25, frontangle=0.0, backangle=0.0, orientation=0)
DEBUG: self.tools[i]: tool_result(id=220, xoffset=0.0, yoffset=0.0, zoffset=2.958, aoffset=0.0, boffset=0.0, coffset=0.0, uoffset=0.0, voffset=0.0, woffset=0.0, diameter=0.375, frontangle=0.0, backangle=0.0, orientation=0)
i= 3
self.tools[i]:  tool_result(id=6, xoffset=0.0, yoffset=0.0, zoffset=2.25, aoffset=0.0, boffset=0.0, coffset=0.0, uoffset=0.0, voffset=0.0, woffset=0.0, diameter=0.25, frontangle=0.0, backangle=0.0, orientation=0)
DEBUG: self.tools[i]: tool_result(id=220, xoffset=0.0, yoffset=0.0, zoffset=2.958, aoffset=0.0, boffset=0.0, coffset=0.0, uoffset=0.0, voffset=0.0, woffset=0.0, diameter=0.375, frontangle=0.0, backangle=0.0, orientation=0)
i= 4
self.tools[i]:  tool_result(id=7, xoffset=0.0, yoffset=0.0, zoffset=3.555, aoffset=0.0, boffset=0.0, coffset=0.0, uoffset=0.0, voffset=0.0, woffset=0.0, diameter=3.937, frontangle=0.0, backangle=0.0, orientation=0)
DEBUG: self.tools[i]: tool_result(id=220, xoffset=0.0, yoffset=0.0, zoffset=2.958, aoffset=0.0, boffset=0.0, coffset=0.0, uoffset=0.0, voffset=0.0, woffset=0.0, diameter=0.375, frontangle=0.0, backangle=0.0, orientation=0)
i= 5
self.tools[i]:  tool_result(id=68, xoffset=0.0, yoffset=0.0, zoffset=2.875, aoffset=0.0, boffset=0.0, coffset=0.0, uoffset=0.0, voffset=0.0, woffset=0.0, diameter=0.257, frontangle=0.0, backangle=0.0, orientation=0)
DEBUG: self.tools[i]: tool_result(id=220, xoffset=0.0, yoffset=0.0, zoffset=2.958, aoffset=0.0, boffset=0.0, coffset=0.0, uoffset=0.0, voffset=0.0, woffset=0.0, diameter=0.375, frontangle=0.0, backangle=0.0, orientation=0)
i= 6
self.tools[i]:  tool_result(id=220, xoffset=0.0, yoffset=0.0, zoffset=2.958, aoffset=0.0, boffset=0.0, coffset=0.0, uoffset=0.0, voffset=0.0, woffset=0.0, diameter=0.375, frontangle=0.0, backangle=0.0, orientation=0)
DEBUG: self.tools[i]: tool_result(id=220, xoffset=0.0, yoffset=0.0, zoffset=2.958, aoffset=0.0, boffset=0.0, coffset=0.0, uoffset=0.0, voffset=0.0, woffset=0.0, diameter=0.375, frontangle=0.0, backangle=0.0, orientation=0)
DEBUG: idx:  7
i= 0
self.tools[i]:  tool_result(id=220, xoffset=0.0, yoffset=0.0, zoffset=2.958, aoffset=0.0, boffset=0.0, coffset=0.0, uoffset=0.0, voffset=0.0, woffset=0.0, diameter=0.375, frontangle=0.0, backangle=0.0, orientation=0)
!!!emc/rs274ngc/gcodemodule.cc: parse_file() f=/home/user/git/linuxcnc-master-official/configs/sim/axis/nc_files/aa_error_test.ngc
!!!interp_error=1 result=2 last_sequence_number=117

@rmu75
Copy link
Contributor

rmu75 commented Nov 11, 2024

yes with some of rene's tool table refactoring something got lost. really confusing mix of tool number, pocket number and tool table index.

something like

diff --git a/lib/python/rs274/interpret.py b/lib/python/rs274/interpret.py
index 5eba95d246..8815f7f869 100644
--- a/lib/python/rs274/interpret.py
+++ b/lib/python/rs274/interpret.py
@@ -140,8 +140,9 @@ class StatMixin:
         self.tools = list(s.tool_table)
         self.random = r
 
-    def change_tool(self, idx):
+    def change_tool(self, tool_nr):
         global tool_in_spindle
+        idx = self.get_index(tool_nr)
         if self.random:
             self.tools[0], self.tools[idx] = self.tools[idx], self.tools[0]
             tool_in_spindle = idx
@@ -158,6 +159,14 @@ class StatMixin:
             return tuple(self.tools[idx])
         return empty_spindle_data
 
+    def get_index(self, tool_nr):
+        index = 1
+        for tool in self.tools[1:]:
+            if tool.id == tool_nr:
+                return index
+            index = index + 1
+        return 0
+
     def get_external_angular_units(self):
         return self.s.angular_units or 1.0

should do but I'm not sure that covers all cases.

I will prepare a PR and try to include some test cases.

@rmu75
Copy link
Contributor

rmu75 commented Nov 11, 2024 •
edited
Loading

in the GCODE I have 'T6 M6' (which works) and later 'T7 M6' (which fails)

does that change to tool 6 or to tool 220? or worse, change to tool 6 and apply offsets of tool 220? does it work on 2.9?

@Sigma1912
Copy link
Contributor

Sigma1912 commented Nov 11, 2024 •
edited
Loading

Actual tool change seems not affected (displayed tool number and tool offsets are correct).
I believe this bug may only affect the gremlin preview / Gcode Stats.

I'm testing on master currently.

@Sigma1912
Copy link
Contributor

Just checked out 2.9.3 and it works for me there. It seems that interpret.py 'change_tool(self, idx)' gets the correct line number. So something must have removed that looked which line in the tool table held the requested tool number.

@rmu75
Copy link
Contributor

rmu75 commented Nov 11, 2024

Just checked out 2.9.3 and it works for me there.

it should also work on tip of 2.9 branch. which raises the question what is going on in 2.9.3-2099-g9f5a1c8f50 whatever that is.

@Sigma1912
Copy link
Contributor

I know, I'm puzzled as to why this bug would be reported on Version 2.9.3.

@6XoCtujg2C0gne
Copy link
Contributor

6XoCtujg2C0gne commented Nov 11, 2024 via email

@rmu75
Copy link
Contributor

rmu75 commented Nov 11, 2024

I reported this or something very similar in my forum post “Inconsistent values from Versaprobe https://forum.linuxcnc.org/qtvcp/54169-inconsistent-values-from-versaprobe ” in mid October.

I don't see how that is remote similar -- can you please open a new issue if some problem still exists, and please post complete version info. thanks.

@6XoCtujg2C0gne
Copy link
Contributor

6XoCtujg2C0gne commented Nov 11, 2024 via email

@rmu75 rmu75 mentioned this issue Nov 11, 2024
Merged
@Sigma1912
Copy link
Contributor

Sigma1912 commented Nov 12, 2024 •
edited
Loading

Just found the same problem here (although it does not produce an error):
https://github.com/LinuxCNC/linuxcnc/blob/master/lib/python/rs274/glcanon.py#L301

in 2.9: 'self.tool_list' contains the tool table line [0, 5, 4, 6, 2, 1, 3, 0]
in master: 'self.tool_list' contains the tool number [0, 68, 48, 220, 4, 1, 22, 0]

[edit]
Looks like this is used for 'gcode_properties'

@Sigma1912
Copy link
Contributor

Sigma1912 commented Nov 12, 2024 •
edited
Loading

Actually this seems like an improvement in this particular case as it now displays actual tool numbers (left) rather than tool table index (right):

gcode_properties

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
7 participants
@rene-dev @andypugh @6XoCtujg2C0gne @rmu75 @rodw-au @Lcvette @Sigma1912