Advanced Search

grandixximo wrote:

[code][code][code][code]If you post the full traceback, I can tell you which module it is.

[/code][/code][/code][/code]
 

Thanks, but I already found out.

This error occurred on several of my computers, with systems installed at different times, some from new iso files, others with dist-upgrade, so I was convinced that the problem must be of a general nature and not dependent on my hardware.
But when you wrote that it works for you, I remembered that I have a fresh Debian 13.7 on one computer, on which I have not installed any programs yet. I checked it and Qtdragon actually started and the error I mentioned was not there.
At this point it was simple - on all my computers I had to have some program that I needed and which conflicted with qtvcp.
As usual, the message displayed by Python was erroneous and misleading.
Everything was fine with numpy and it was in the correct version.

Qtdragon stops working after installing bcnc (pip install bcnc).
Specifically, the culprit is the opencv-python==4.5.5.64 package that bcnc needs.
After uninstalling bcnc and opencv-python==4.5.5.64 Qtdragon starts again.

Now we know what it is, but it still does not solve the problem, because bcnc is a sender to GRBL, i.e. a program from the cnc category, which may also be needed by someone.
For example, I have milling machines and lathes on LinuxCNC, but a CO2 laser on FluidNC, because it is such a simple machine that it would make no sense to control it with a complicated program.

Thanks again for your help.

Having had my machine slow to a crawl because it applied "in/min" to "degrees" (usually by accident, I use G93 most of the time), I would like an option to "do better".  Some ideas:
* Use radians instead of degrees if you have to use them at all, since those are much closer to linear distance.
* Scale by the WCS Z coordinate to figure out "actual" circumference/distance
* Specify the machine location of the rotary in the config, like Y=10 Z=-3 (which implies it points along X) and calculate circumference based on that
* manually specify some scaling factor

tuxcnc wrote:

This is of course not a solution to the problem, the solution will be to repair the LinuxCNC sources, but so far no one wants to do that...

Already replied about the issue in your other post, as far as I can tell the issue is not with the LinuxCNC sources as Chris Morley tried to explain (maybe poorly) in the other thread... Anyhow, if you want the devs to take action on issues you find, you should post an issue in github, or mail the dev mailing list This email address is being protected from spambots. You need JavaScript enabled to view it. if you'd rather do that, we are much more active there. This turn I think it is not a LinuxCNC issue, but next one might, so if you find anything you think is related to the LinuxCNC sources, please report to the channels where the devs are most active...

Follow-up: I reproduced the exact error, and it is not a LinuxCNC bug.

To reproduce your RuntimeError, I compiled a minimal Python extension against numpy 1.26.4 headers and imported it under numpy 2.2.4. Result, your exact message:

RuntimeError: module compiled against ABI version 0x1000009 but this version of numpy is 0x2000000

Same thing happens with a pip wheel from the numpy 1 era, for example opencv-python 4.8.x. So the error means: some binary Python extension on your system was built against numpy 1.x and is being loaded under numpy 2.x. The full traceback always names the module.

How to find and fix it:

Run the GUI from a terminal and read the traceback; the module named just above the RuntimeError is the culprit.
Check where it came from:If dpkg owns it,the package. If not, it is a pip or self-built copy;andare the usual hiding places.
Remove or rebuild the stale copy. For pip wheels,(recent wheels are built against numpy 2). Do not downgrade numpy; as you said, that breaks other software and is unnecessary.
One more thing: QtDragon_hd from persei802 on GitHub is a separate fork, not the qtdragon shipped with LinuxCNC. It has extra dependencies stock qtdragon does not have, including scipy (plugins/zlevel.py) and direct numpy use (lib/compensate.py). A stale pip scipy wheel produces exactly the error you saw. The qtdragon and qtplasmac included in LinuxCNC itself do not import scipy at all.

If you post the full traceback, I can tell you which module it is.

The RuntimeError quoted above:

RuntimeError: module compiled against ABI version 0x1000009 but this version of numpy is 0x2000000

is not a LinuxCNC source problem. LinuxCNC's GUI code is pure Python, nothing in it is compiled against numpy's ABI. That error means a binary Python extension on your system was built against numpy 1.x and is being loaded under numpy 2.x. The usual suspect is a pip-installed wheel (opencv-python is the classic one, since qtvcp's camview imports cv2) shadowing the apt packages. The traceback names the module; check it, then either apt install python3-opencv and remove the pip copy, or rebuild the offending module against numpy 2.

Two data points that qtvcp itself is fine on Debian 13:

The official trixie packages (both Debian's own 2.9.4 and linuxcnc.org's 2.9.9/2.9.10 debs) depend on python3-numpy 2.2 and the full qtvcp stack, and pass their respective CI.
I just booted the qtdragon and qtplasmac sim configs from a self-compiled current master (2.10.0~pre2) on a clean Debian 13.7 install with python 3.13.5 and numpy 2.2.4: both start and run with no errors.
Note that QtDragon_hd from persei802's GitHub is a separate, unofficial fork, not the qtdragon shipped in LinuxCNC. If that fork fails with numpy 2, it needs fixing there.

So before concluding "the LinuxCNC sources need repair", please post the full traceback. Odds are it points at a local pip/apt mix, which is fixable without touching any sources.

No, nothing breaks for me, I am on 13.7 I will investigate the other thread...

grandixximo wrote:

All qtvcp UI work on Debian 13, I'm not sure what python problem you are referring to, is this on the latest master?
 

Tuxcnc had some python package version issues when using Debian 13.7 which was only released on 12 September. Just try upgrading debian and see if master branch  breaks now.

Hello,

In my view, the decisive factor is whether or not kinematics are taken into account:
without kinematics, values ​​are specified in angular units; with kinematics, they are specified in linear units, as the lever arms are factored in.

All qtvcp UI work on Debian 13, I'm not sure what python problem you are referring to, is this on the latest master?

"G93 is fine for me" means nothing.
It is one thing when someone uses CAM and is not at all interested in how the g-code is created, and it is enough that it works, and it is completely different when someone writes the program themselves using functions, loops and subroutines.

bentiggin wrote:

I want to use 2.10 for some of the plasmac updates 

2.10 only partially supports Debian 13.
I can't check everything, but it looks like any qtvcp based gui won't work.
Changes in Python traditionally cause the problem.
A new version of numpy, but maybe something else too.
You can work around the problem by installing LinuxCNC on Debian 12, or downgrading some Python packages on Debian 13.
This is of course not a solution to the problem, the solution will be to repair the LinuxCNC sources, but so far no one wants to do that...

In my opinion FF1 and FF2 should be delayed. If the PID output is the velocity setpoint, then FF2 is not used, FF1 should be equal 1.0, but it would produce spikes at acceleration change. It could be improved by adding a 1st order delay to the setpoint value, before it gets compared to the actual value.

2.10 is currently transitioning to the a new hal API, so mind that is still somewhat work in progress, there is no 2.10 finished release

There are installable artefacts in the GitHub actions, get a GitHub account, download those for your system, and install, I would reccomend to use a system for which the CI already builds, you'll have yourself way less headaches

Hi All,

Thank you everyone for the already great response. The 50% discount offer closes on 4th October, just a few more days to grab it.

We will be launching Takshak Turn for mill turn and Takshak Burn for Lasers, EDMs, Waterjets and Plasma Cutter between October and November. They will launch with a discount as well.

Thanks all for the support