Search Results (Searched for: )
- f355
16 Aug 2025 14:55
Z probe and tool setter combo was created by f355
Z probe and tool setter combo
Category: Basic Configuration
Hello everybody!
The 3-axis machine I'm trying to retrofit has a tool setter button fixed on the bed, as well as a spindle Z probe, and I'm trying to make it work (using qtdragon, if that matters). I don't know the length of the probe, and I don't want to use a fixed value for it due to the possible spindle clamping variations, so I'd like to measure it against the tool setter before every probing routine.
In order to do that, I need to move the probe down until BOTH the probe and the tool setter contacts are closed, to compensate for the probe's action distance. In other situations - probing the stock or setting the end mill length - I need the machine to go until EITHER of the contacts is closed.
The issue is, there are no separate HAL pins to feed the tool setter and the probe signals into, just motion.probe-input. I can combine the signals with or2/and2 and it works for one of the scenarios, but obviously not for the other.
How do you folks solve that? I can't imagine I'm the first one with this question, but digging the forums did not produce anything helpful for me.
Thanks in advance!
The 3-axis machine I'm trying to retrofit has a tool setter button fixed on the bed, as well as a spindle Z probe, and I'm trying to make it work (using qtdragon, if that matters). I don't know the length of the probe, and I don't want to use a fixed value for it due to the possible spindle clamping variations, so I'd like to measure it against the tool setter before every probing routine.
In order to do that, I need to move the probe down until BOTH the probe and the tool setter contacts are closed, to compensate for the probe's action distance. In other situations - probing the stock or setting the end mill length - I need the machine to go until EITHER of the contacts is closed.
The issue is, there are no separate HAL pins to feed the tool setter and the probe signals into, just motion.probe-input. I can combine the signals with or2/and2 and it works for one of the scenarios, but obviously not for the other.
How do you folks solve that? I can't imagine I'm the first one with this question, but digging the forums did not produce anything helpful for me.
Thanks in advance!
- funkenjaeger
- funkenjaeger
16 Aug 2025 14:55 - 16 Aug 2025 15:09
Replied by funkenjaeger on topic Getting stuck on G1 (but not G0) in NGC M6 remap
Getting stuck on G1 (but not G0) in NGC M6 remap
Category: General LinuxCNC Questions
Reviving this from the dead, as I once again ran into this same issue in my tool changer routine. Clearly, my original "fix" of just not running the spindle in my M6 remap was just a workaround, not an actual solution. In my tool changer routine, I was (of course) stopping the spindle via M5 prior to changing tools, and this was causing it to wait on the first G1 move. I'm not willing to change that to a G0 because I don't want the machine slamming tools in and out of their pockets at full speed.
I haven't been able to easily find a crystal clear definition of this in the official docs, but numerous sources have led me to understand that after each commanded spindle speed change (including stop/start), upon encountering the next feed-rate move (e.g. G1, G2, G3 and probably others) the motion controller will wait for spindle at-speed to become true. This wait will only occur once after each spindle speed change (i.e. subsequent G1/G2/G3's won't wait) and does not apply to rapid moves (G0).
One aspect that made this issue more insidious and appear to be more elusive during troubleshooting is that it doesn't behave the same when commanding things manually via GUI or MDI, versus when running an actual program in Auto mode which contained tool changes. I'm guessing that whatever internal flag is associated with this one-time wait gets reset each time execution stops after a manual command.
This behavior is logical enough in the context that G1/G2/G3 are meant to be "cutting" moves whereas G0 rapids moves are not. However in the context of a tool change or probing or similar, a controlled feed rate while NOT cutting is desired, and there is no such thing as a non-cutting controlled-feedrate g-code command in linuxcnc to my knowledge.
Fortunately, I found a way to fake it out:Thankfully, based on my testing, a zero-distance G1 move seems to be interpreted as a no-op but still consumes the one-time wait.
Adding this before the first "real" G1 move in my tool changer routine has eliminated this issue - at long last!
Other thoughts I had on alternative ways to work around this include:
1) add side-channel logic between the motion and spindle controllers that can stop the spindle without actually changing the commanded spindle speed via G-code (M3/M5 or S commands), so the one-time wait doesn't get triggered in the first place. This could still be sensitive to this issue if the user g-code program happened to trigger the one-time wait just before triggering the remap subroutine(s).
2) add side-channel logic to fake out spindle at-speed (hold it true) for the duration of the subroutine even when the spindle is stopped.
Both of these options seem more risky to me because of the possibility of getting into a bad state in the event of an error in the subroutine and returning to the user program with the normal spindle control still bypassed in some way, but just throwing them out as food for thought...
I haven't been able to easily find a crystal clear definition of this in the official docs, but numerous sources have led me to understand that after each commanded spindle speed change (including stop/start), upon encountering the next feed-rate move (e.g. G1, G2, G3 and probably others) the motion controller will wait for spindle at-speed to become true. This wait will only occur once after each spindle speed change (i.e. subsequent G1/G2/G3's won't wait) and does not apply to rapid moves (G0).
One aspect that made this issue more insidious and appear to be more elusive during troubleshooting is that it doesn't behave the same when commanding things manually via GUI or MDI, versus when running an actual program in Auto mode which contained tool changes. I'm guessing that whatever internal flag is associated with this one-time wait gets reset each time execution stops after a manual command.
This behavior is logical enough in the context that G1/G2/G3 are meant to be "cutting" moves whereas G0 rapids moves are not. However in the context of a tool change or probing or similar, a controlled feed rate while NOT cutting is desired, and there is no such thing as a non-cutting controlled-feedrate g-code command in linuxcnc to my knowledge.
Fortunately, I found a way to fake it out:
G91 (incremental distance mode)
G1 X0 F1 ("move" 0 distance at an arbitrary non-zero feed rate - this consumes the one-time wait after a spindle speed change)
G90 (optional - restore absolute distance mode if needed)Adding this before the first "real" G1 move in my tool changer routine has eliminated this issue - at long last!
Other thoughts I had on alternative ways to work around this include:
1) add side-channel logic between the motion and spindle controllers that can stop the spindle without actually changing the commanded spindle speed via G-code (M3/M5 or S commands), so the one-time wait doesn't get triggered in the first place. This could still be sensitive to this issue if the user g-code program happened to trigger the one-time wait just before triggering the remap subroutine(s).
2) add side-channel logic to fake out spindle at-speed (hold it true) for the duration of the subroutine even when the spindle is stopped.
Both of these options seem more risky to me because of the possibility of getting into a bad state in the event of an error in the subroutine and returning to the user program with the normal spindle control still bypassed in some way, but just throwing them out as food for thought...
- COFHAL
- COFHAL
- gundamgear
- gundamgear
16 Aug 2025 14:05
Replied by gundamgear on topic Arduino IO Expansion
Arduino IO Expansion
Category: Show Your Stuff
yes that will only go away when i run terminal halrun and loadusr arduino-connector
it like hal file loadusr arduino-connector not properly load or something
it like hal file loadusr arduino-connector not properly load or something
- tommylight
16 Aug 2025 13:59
Replied by tommylight on topic Arduino IO Expansion
Arduino IO Expansion
Category: Show Your Stuff
From your error report
./test.hal:95: Pin 'arduino.din.9' does not exist- gundamgear
- gundamgear
16 Aug 2025 13:51 - 16 Aug 2025 14:02
Replied by gundamgear on topic Arduino IO Expansion
Arduino IO Expansion
Category: Show Your Stuff
Hello I try to use arduino connector when I set hal file to loadusr arduino-connector it not load and when I start linuxcnc it spit pin does not exist
only when I use terminal to run halrun and loadusr arduino-connector then I can start linuxcnc normally but when I quit program halrun is reset and I has to load it again in order to run linuxcnc.
What I try so far
loadusr arduino-connector at begin of hal file
loadusr arduino-connector at end of hal file
[HAL]TWOPASS = on in .ini
loadusr python3 /usr/bin/ardino-connector
loadusr -Wn arduino-connector
non of it work only run halrun in terminal work.
Error report created by /usr/lib/tcltk/linuxcnc/show_errors.tcl:
Print file information:
RUN_IN_PLACE=no
LINUXCNC_DIR=
LINUXCNC_BIN_DIR=/usr/bin
LINUXCNC_TCL_DIR=/usr/lib/tcltk/linuxcnc
LINUXCNC_SCRIPT_DIR=
LINUXCNC_RTLIB_DIR=/usr/lib/linuxcnc/modules
LINUXCNC_CONFIG_DIR=
LINUXCNC_LANG_DIR=/usr/lib/tcltk/linuxcnc/msgs
INIVAR=inivar
HALCMD=halcmd
LINUXCNC_EMCSH=/usr/bin/wish8.6
LINUXCNC - 2.9.4
Machine configuration directory is '/home/cnc/linuxcnc/configs/test'
Machine configuration file is 'test.ini'
INIFILE=/home/cnc/linuxcnc/configs/test/test.ini
VERSION=1.1
PARAMETER_FILE=linuxcnc.var
TPMOD=
HOMEMOD=
TASK=milltask
HALUI=
DISPLAY=axis
COORDINATES=X Y Z
KINEMATICS=trivkins coordinates=XYZ
Starting LinuxCNC...
Starting LinuxCNC server program: linuxcncsvr
Loading Real Time OS, RTAPI, and HAL_LIB modules
Starting LinuxCNC IO program: io
linuxcnc TPMOD=tpmod HOMEMOD=homemod EMCMOT=motmod
Found file(REL): ./test.hal
Shutting down and cleaning up LinuxCNC...
Removing HAL_LIB, RTAPI, and Real Time OS modules
Removing NML shared memory segments
Debug file information:
Note: Using POSIX realtime
./test.hal:95: Pin 'arduino.din.9' does not exist
7233
Stopping realtime threads
Unloading hal components
Note: Using POSIX realtime
-----------------------------------------------------------------------
Info report created by linuxcnc_info:
The file: /tmp/linuxcnc_info.txt
can be posted to a forum or a web site like:
http://pastebin.com
in order to provide information about the linuxcnc
system and configuration.
Date: Sat Aug 16 20:30:11 +07 2025
UTC Date: Sat Aug 16 13:30:11 UTC 2025
this program: /usr/bin/linuxcnc_info
uptime: 20:30:11 up 1:44, 1 user, load average: 0.24, 0.30, 0.33
lsb_release -sa: Debian Debian GNU/Linux 12 (bookworm) 12 bookworm
linuxcnc: /usr/bin/linuxcnc
pwd: /home/cnc/linuxcnc/configs/test
USER: cnc
LOGNAME: cnc
HOME: /home/cnc
EDITOR:
VISUAL:
LANGUAGE:
TERM: dumb
COLORTERM:
DISPLAY: :0.0
DESKTOP: lightdm-xsession
display size: 1920x1080 pixels (508x286 millimeters)
PATH: /usr/bin:/home/cnc/linuxcnc/configs/test/bin:/usr/bin:/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games
uname items:
nodename -n: raspberrypi
kernel-name -s: Linux
kernel-vers -v: #1 SMP PREEMPT_RT Mon Jan 27 00:10:15 AEDT 2025
machine -m: aarch64
processor -p: unknown
platform -i: unknown
oper system -o: GNU/Linux
/proc items:
cmdline: reboot=w coherent_pool=1M 8250.nr_uarts=1 pci=pcie_bus_safe cgroup_disable=memory numa_policy=interleave smsc95xx.macaddr=2C:CF:67:BC:6D:E4 vc_mem.mem_base=0x3fc00000 vc_mem.mem_size=0x40000000 console=ttyAMA10,115200 console=tty1 root=PARTUUID=a27d77aa-02 rootfstype=ext4 fsck.repair=yes loglevel=5 net.ifnames=0 processor.max_cstate=1 isolcpus=2,3 firmware_class.path=/lib/firmware/updates/brcm rootwait
model name:
cores:
cpu MHz:
parport:
serial:
Versions:
gcc: gcc (Debian 12.2.0-14) 12.2.0
python: Python 3.11.2
git: git version 2.39.5
git commit: NA
tcl: 8.6
tk: 8.6
glade: not_in_PATH
linuxcnc_var all:
LINUXCNCVERSION: 2.9.4
LINUXCNC_AUX_GLADEVCP: /usr/share/linuxcnc/aux_gladevcp
LINUXCNC_AUX_EXAMPLES: /usr/share/linuxcnc/aux_examples
REALTIME: /usr/lib/linuxcnc/realtime
RTS: uspace
HALLIB_DIR: /usr/share/linuxcnc/hallib
PYTHON: /usr/bin/python3
dpkg -l '*linuxcnc*':
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name Version Architecture Description
+++-===================-=================-============-=====================================================================
un linuxcnc <none> <none> (no description available)
un linuxcnc-dev <none> <none> (no description available)
un linuxcnc-doc <none> <none> (no description available)
ii linuxcnc-doc-en 1:2.9.4 all motion controller for CNC machines and robots (English documentation)
un linuxcnc-doc-es <none> <none> (no description available)
un linuxcnc-doc-fr <none> <none> (no description available)
ii linuxcnc-ethercat 1.40.0.g8a607c0-0 arm64 LinuxCNC EtherCAT HAL driver
un linuxcnc-sim <none> <none> (no description available)
un linuxcnc-sim-dev <none> <none> (no description available)
ii linuxcnc-uspace 1:2.9.4 arm64 motion controller for CNC machines and robots
ii linuxcnc-uspace-dev 1:2.9.4 arm64 PC based motion controller for real-time Linuxonly when I use terminal to run halrun and loadusr arduino-connector then I can start linuxcnc normally but when I quit program halrun is reset and I has to load it again in order to run linuxcnc.
What I try so far
loadusr arduino-connector at begin of hal file
loadusr arduino-connector at end of hal file
[HAL]TWOPASS = on in .ini
loadusr python3 /usr/bin/ardino-connector
loadusr -Wn arduino-connector
non of it work only run halrun in terminal work.
Time to create page: 0.363 seconds