Is there any idiots guide to GUIs?

As you said qtdragon being python doesn't compile anything.
It preprocess somethings into to bytecode.
Sounds like numbpy is the wrong version.
But now we can investigate, thank you.

So you didn't home the machine while trying to decide if the screen is 'useful' ?
and there was extra information in the list that you didn't like?
Oh and the colors -colors were bad.
And that was worth going on the forum and ranting about how bad the software is?
Sounds like you didn't give it much of a chance.

Shake my head.

I'll try to replicate the numbpy problem.

cmorley wrote:

Sounds like numbpy is the wrong version.

More specifically, it looks like someone did some good work in the 2.9 branch (Qtdragon works with the new numpy 2.2.4), but didn't port it to the 2.10 branch...

Debian 13.7 was only released earlier this month (on 12 September) so its quite possible at this early stage that something Debian did with versions that broke LinuxCNC. Instead of complaining to all and sundry, why not raise an issue on GitHub so the devs can look at it? They are probably not aware of the issue.

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.

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; and are 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.

grandixximo wrote:

Code:

[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.

Did you try ? That should install it in its own env, and not conflict with qtDragon at all...

By the way, now that we have the issue pin pointed, I was able to find a small improvement on qtvcp side, it can be hardened so that the UI still runs but the camera widget doesn't, since that is all that actually breaks.

#4612

If you'd like to see when it merges...

Also on bCNC side the core problem is an issue opened in 2022
#1761

And I pushed a fix there as well

#1996

If they both land, then the problem will be totally fixed, and you can use pip, but for now pipx will install bCNC in its own env, and you should be able to work.

grandixximo wrote:

Did you try

Code:

pipx install bcnc? That should install it in its own env, and not conflict with qtDragon at all...

 

Works. Thanks.