Advanced Search

No, i mean when i push the Button on the left upper corner in NativCAM then the Programm will load autmomaticly in linuxcnc in program drive.
The video i will send you later.

Ok much appreciated here is my current hal and ini files 
   
And yes my z axis home/limit is at the top of travel.

I would first check the encoders, the thin slotted disk sometimes rusts and keeps getting worse with time.
You can check the Granite Devices, i did use Argon drives and they are quite versatile, but knowing how much time it takes, i would just go for the cheap china drives with motors.

By any chance do you mean 626VM3 ?
Is this it?
forum.linuxcnc.org/30-cnc-machines/33529-hurco-bmc-20p-retrofit
Unfortunately, i do not have access to it anymore as the shop moved.

Nice plane, looks great made out of wood.
As for machinist, i am building a styrofoam cutter to make wings for RC planes, after building some 15 drones and a single 3D printed plane that has yet to fly.
I have built several styro cutters,eve a huge 5 axis one, but his one is for me.

What do you mean by "new program to the control" ?
Do you have 2 PC's running this and the one at the machine has issues, or what exactly?
Can you do a short video and upload to youtube or google drive?

If you want, you can post a backup of your config here, and I'll take a look at.

Your Z axis limit switch is at the top of travel right?

Moved to "user exchange".
-
I am in Europe and i can speak German, but i am of no use for probing, i still did not build a proper mill. I can figure out everything for sure, but the time it would take is probably much longer than someone with experience.
Also, i never charge for helping here or whatever is initiated from here.

Japoo_Ness wrote:

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

Shielded cable, shielding grounded on the Mesa side.

Japoo_Ness wrote:

According to the diagrams, the analog signal for the axis is connected to the machine's frame/ground.

Analog cable has 2 wires plus shielding, shield must be grounded on the Mesa side, and one of those 2 wires is the analog ground.

Japoo_Ness wrote:

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

There is no exact reference for it, see above, use a DVM to measure between analog and machine ground both in AC and DC mode > if any of those read more than a Volt or two = do not connect. If that is all correct but still does not work, you can try grounding the analog ground to machine ground through a 1K resistor for a single line, test with only a single line/analog drive/connection to mesa.
-
As a general rule, use a very good power supply for the Mesa as the encoders are powered from it.

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