Advanced Search

 

In the process of setting up prprobebasic on my machine, coming from gmoccapy.
have configured as per the help files however am getting a error saying the file path for user tabs is missing (refer image)
any ideas what I may have missed?
 

Mini was depreciated in LinuxCNC 2.7.
You could make a similar GUI using Flex GUI.
gnipsel.com/linuxcnc/flexgui/index.html

JT

seuchato wrote:

Hi all
After a couple of years, I am finally back and ready to making chips. I have a router, use steppers on parport. Linuxcnc is 2.9.4, debian doodle jump :

Linux cnc0 6.1.0-35-rt-amd64 #1 SMP PREEMPT_RT Debian 6.1.137-1 (2025-05-07) x86_64 GNU/Linux

The router works, I can cut stuff etc. not the problem. The job that I want to do soon requires quite a few tool changes. So far I did it using the dowel method, but that is very time consuming. Sure an automatic tool changer would be perfect, but that's up for in a later stage. For now I have a tool length sensor, that I would like to use with my collet spindle to get tool length set after a manual tool change.

When I run tcdemo.ngc:

- goes to change position
- when I hit "Tool change complete", goes to zmax, tool sensor x and y, starts going towards the sensor.
- As soon as the sensor is touched, I get "Probe tripped during non-probe move" and program is stopped

How can I get over this?

I attach the relevant files in zipped folder "toollength_problem.zip"

Greez
chris
You might want to double-check that the

G38.x command is active before motion toward the sensor begins. Also, review your HAL and INI files to confirm the probe input isn't being tripped by noise or an early signal. Did you try adding a small delay before the probe move to stabilize the signal?

Aciera wrote:

Maybe have a look at the 'joint.N.unlock' pins:
linuxcnc.org/docs/html/man/man9/motion.9...OINT%20unlock%20pins
 

It seems to work for me.
Is there any example for unlocking an axis?

Does anyone have lathe working?

Run - python3 ncam and mill loads
Run - python3 ncam -c lathe and get the attached errors

Thanks
 

Maybe have a look at the 'joint.N.unlock' pins:
linuxcnc.org/docs/html/man/man9/motion.9...OINT%20unlock%20pins

Thank you so much.  I was able to create a 7i97t config.  No errors on starting or shutdown.  The 7i97t stays connected.  

​​​​

He was one of the wild ones, RIP.

Hey guys!
My linuxcnc / probebasic started to show a weird behaviour today.
After I start the system and home the machine, I get a popup saying "KeyError" _everytime_ when I jog any of the axes.
I can ignore that message, but it comes back everyime I jog again (no matter if via keyboard, softkey or pendant).

BUT - what I found out... as soon as I zero one of the axes (or all three), the error is gone.
I have not changed anything in my (software) config the last week, BUT I have modified my x axis yesterday and therefore moved the limitswitch a bit. 
Can this somehow be related? The popup says somewthing with "...active.WCSoffset..."... maybe some cached value doesnt fit anymore after I moved that switch?


Thx in advance!

net canMove not.0.out => stepgen.3.enable

My guess is that this causes the following error
when motion starts and this is still false.
That is, the commanded position is changing but
the stepgen is disabled so cannot follow ( so the
stepgen feedback is static) so you get a
following error.

Edit:

If linuxCNC is allowed to start motion before the brake is released,
Expanding the following error limits seem like the easiest solution.
However now this joint will lag the others so coordinated motion would
not be possible.

Is there some way to use digital inputs and outputs in the
gcode to manage the brake? That is, use a digital output
to enable the brake and a digital input to signal when the brake was
full applied and fully released. You would do this using M62,M63 and
M66 in the gcode and the hal digital input and output pins.

www.linuxcnc.org/docs/devel/html/gcode/m...e.html#mcode:m62-m65

If I understand the BUTTON_1_CODE correctly, the G10 L20 P0 coordinate system is always offset to the fixed values defined by X and Y. How does positioning the cross-hairs to a difference starting position translate the offsets to the new location correctly?

Well all I can say is that clearly your G54 offset values are wrong. So if those values are set in Fusion then you would need to look there.
Also you have tool offsets not only in Z but also in X and Y which is a bit unusual.

Hi,

No thanks, i already got it working with the same EL7 homecomp and forgot to update this
Was waiting for the beckhoff modules to arrive and got them today, so i can finally continue now!