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.

Ok so I got it fixed by finding some settings in my notes that worked. So basically I entered these settings to the Z axis.
 
Now the torch still goes up initially but it doesnt hit the limit and it cuts just fine.
 
Im not entirely sure how these changes fixed my machine.

You could post your crosshair_panel.glade and crosshair_panel.hal then we will have a chance to help you

Hello everyone,
I have installed the latest version of NativeCAM under the Gmoccapy user interface of LinuxCNC. So far it works, but every time after transferring a new program to the control, I always have to press the start button twice to launch the program.
The first time I press it, the milling spindle starts briefly, stops immediately, and then I receive several error messages:

• invalid parameters in linear command
• linear move on line 38 would exceed positive limit of axis/joint 2
• linear move on line 38 would exceed positive limit of axis/joint Z

After that, I can restart the program again and again without any problems, until I transfer a new program (or the same one again) to the control.
What could be the cause of this error?
Thank you very much in advance for your help.

Thanks again for setting me on the right track again, this is really appreciated. In my case I only included 2 potmeters on the console: one for rapid traverse override and one for feedrate override. I copied this from a DMU 50 console which we have at work...

Using HALshow and setting halui.rapid-override.direct-value to True (1) and then setting halui.rapid-override.counts to a manual value (I discovered that a value of 10 corresponds to 100%) works well together with QTDragon_HD. With that I mean that it will probably provide me with the functionality I need. I already wrote some HAL lines using the lincurve component to ensure that the output of the potmeters correspond to the tickmarks (it is not a linear scale...).  By setting up the right net statements I should be able to connect these and have QTDragon follow this setting on the display. Same for halui.feed-override.direct-value and ..counts.

@cmorley: Luckily I didn't include a jog override pot on my console, as I now understand from you that this would not work in a similar manner. I did already buy a pendant (XHC with cable type) and maybe I will run into issues once I try to get that connected. For now I first want to get the spindle and servo's running .

Thank you all for helping me further.

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

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.

Thanks for all your work over the years!  I'd never have been able to finish up my latest build without your help and contributions.  

cmorley wrote:

Compiling problems aren't usually QtDragons fault - you didn't  mention what system you are compiling in so no one could help or evaluate the problem.

I'm sorry Qtdragon didn't suit you out of the box, but there is quite alot you could change.
For instance based on your pic, you could turn on the machine and home it, then the colors change from disabled to enabled and look like this:

 

 

First, about compilation issues.
My system is Debian 13.7 and the LinuxCNC sources are from the Git repository, main branch, i.e. version 2.10.
There is some misunderstanding here, because when LinuxCNC is compiled, the Python scripts are not compiled, but only copied to the right place. This means that if the scripts author screws up, it's his fault, because compilation itself doesn't change anything.
So we have the following flower:
 
This is what happens after compiling LinuxCNC yourself.
However, there are two live images that I ran.
1. linuxcnc_2.9.10-amd64.hybrid.iso
2. linuxcnc_2.10.pre1-amd64.hybrid.iso
Qtdragon starts in both, but neither suits my system.
In linuxcnc_2.9.10-amd64.hybrid.iso there is numpy 2.2.4 but LinuxCNC is 2.9.
In linuxcnc_2.10.pre1-amd64.hybrid.iso there is LinuxCNC 2.10, but Debian 12 with numpy 1.24.2.
Someone's sources have obviously gone wrong...

As for these "gray on grey" numbers, I wrote that I ran Qtdragon for the first time in my life and just took a look. I opened the tab called "offsets", so I thought there were offsets there and it didn't occur to me that it would only work after homing, because offsets have nothing to do with homing the machine.
Well, now I noticed that someone stuffed a machine position into the offsets, for unknown reason, because they can be seen much more conveniently in the window below. I started to wonder what else the authors of Qtdragon would surprise me with, but I think I'm less and less curious about it.
 

Thanks.

Hello,
I’ve installed the DebianNetInstall.iso without a desktop environment, and then installed the real-time kernel, LCNC, Openbox, and a very simple file manager via the terminal. It seems to be working—very low jitter.
Hans

"Vielen Dank für die lieben Worte! Ich hoffe, es wird dir nützlicher sein als FreeCAD."

KR,
George

Ok Georg und vielen Dank
Ich bin zwa nur auf der Hobby-Schiene in Holz aber es ist die Profiliga etwas ganz anderes wie das Cam von Freecad.


King regarde
Juergen

From what I've measured, the issue seems to be on the encoder side.

I initially thought that analog ground and power/system ground were connected. The original cables are currently in use. According to the diagrams, the analog signal for the axis is connected to the machine's frame/ground.

Is it better to isolate the analog ground from the system ground? Under what conditions is it strictly necessary to tie both grounds together?