Advanced Search

Delaying FF1 will make the initial error spike worse.

You need to distinguish between 2 types of error spikes:

A: Errors during constant acceleration (that can be reduced with FF2)
These are relatively constant during the entire ramp up/ramp down
parts of a motion profile.

On a velocity mode servo systems these errors are for 2 reasons:

1. Finite servo drive velocity loop gain
2. Time delay between reading position and drives response to command

#1 can  likely just be guessed at, #2 needs setting FF2 to the time (in seconds) between
position read and drive response.

B: Errors just at the beginning and end of motion.

These are due to the step in acceleration (infinite jerk)  at the beginning and end of motion
and are unavoidable with 2nd order trajectory planners. This is because a step in acceleration
requires the force/torque to change instantly and this is not physically possible on servo systems.

The error can be minimized with better drive tuning or lowering the acceleration but the real solution
is to use a higher order trajectory planner. You might want to try LinuxCNC master's relatively  new
jerk limited trajectory planner, it could use more testers...

G93 works for me, but I just wanted to say a huge thanks for all your work.  I've been trying to keep up with what you're doing with the s curve stuff and the 5 axis tp work.  It's well beyond the level I could contribute anything, but I'm excited to see all the progress.  

G93 works for me, but I just wanted to say a huge thanks for all your work.  I've been trying to keep up with what you're doing with the s curve stuff and the 5 axis tp work.  It's well beyond the level I could contribute anything, but I'm excited to see all the progress.  

Das Handbuch kommt immer noch nicht…
Es kommt aber nur der Fehler :Not running on one of the supported Live systems“
So wie es aus sieht fehlt mir die Datai das appimaged.service in /etc/systemd/user/ 
wie bekomme ich das da rein ? 

king regard
Juergen

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.

The matter became clear.
The problem I described was caused by installing the bcnc program.
So you can use LinuxCNC 2.10 with Debian 13.
At least until you install something that breaks Python's dependencies...

djdelorie wrote:

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
 

These are mathematical heresies.
The whole problem is that it is in no way possible to convert an angle into a length.
They are simply concepts from different categories.
However, you can convert an angle into an arc length if you know the radius.
Since the radius is not listed anywhere in the g-code, it would have to be cleverly specified there.
In my opinion, a new G or M code would be best for this for three reasons:
1. As I wrote earlier, everything would be inside one file, which would eliminate the possibility of a nasty mistake.
2. The G or M code could be used many times in one file, because many diameters can be machined in one piece of material.
3. If someone didn't need it, they wouldn't use it and wouldn't have to be surprised that something was done differently than expected.

It seems you need higher spindle speeds—8,000+ RPM. I have a thread on the forum about a Mori Seiki retrofit. I also work primarily with aluminum, and this mill would be too slow for my parts. That’s why I plan to build a DIY mill with a high-speed spindle; it will produce my aluminum parts faster and consume less power.

forum.linuxcnc.org/12-milling/49821-mori...ofit?start=20#349146

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.