- GCode and Part Programs
- O Codes (subroutines) and NGCGUI
- [solved]HAL pins acting differently in subroutine of Gcode script
[solved]HAL pins acting differently in subroutine of Gcode script
12 Mar 2021 13:22 - 12 Mar 2021 15:02 #201959
by Stormholt
Hello
I am currently trying to create a .ngc macro that can probe a corner of a vice, and i wanted to add some error checking specifically making sure the probe does not hit anything on its way to each of the 3 G38.2 start points.
My idea for this was a do-while loop that would would check an incrementing value and move 1 mm closer each iteration as long as the probe wasn't triggered. Such a subroutine generally looks like this:
The hal pin motion.probe-input change appropriately using the hal meter and the simulate_probe tool.
however in the script the pin is always 1.
The pin is configured the following way in my hal file
Why is the pin behaving differently in my .ngc script?
I am running linuxcnc 2.8.1
Thank you in advance !
I am currently trying to create a .ngc macro that can probe a corner of a vice, and i wanted to add some error checking specifically making sure the probe does not hit anything on its way to each of the 3 G38.2 start points.
My idea for this was a do-while loop that would would check an incrementing value and move 1 mm closer each iteration as long as the probe wasn't triggered. Such a subroutine generally looks like this:
G30.1
#1=1
o100 do
o101 if[ #<_hal[motion.probe-input]> EQ 0 ]
F#<_ini[PROBE]MEASURE_RETRACT_VELOCITY>
G53 G1 Z[#5183 + #1]
o101 else
(print, probe triggered during jog)
#1 = [#1 +21]
o101 endif
#1 = [#1 + 1]
o100 while [#1 LT 21]The hal pin motion.probe-input change appropriately using the hal meter and the simulate_probe tool.
however in the script the pin is always 1.
The pin is configured the following way in my hal file
loadrt or2 names=probing.controllers
addf probing.controllers servo-thread
net probing.probe => probing.controllers.in0
net probing.toolsetter => probing.controllers.in1
net probing.probe-toolsetter <= probing.controllers.out
net probing.probe-toolsetter => motion.probe-inputWhy is the pin behaving differently in my .ngc script?
I am running linuxcnc 2.8.1
Thank you in advance !
Last edit: 12 Mar 2021 15:02 by Stormholt. Reason: solved
Please Log in or Create an account to join the conversation.
12 Mar 2021 15:04 #201977
by Stormholt
Replied by Stormholt on topic [solved]HAL pins acting differently in subroutine of Gcode script
Every time i give up and succumb and begin to asking on the forum i find the answers shortly after.
This is what i ended up during after find this thread: forum.linuxcnc.org/20-g-code/27055-machi...m-g-code-hal-support
This is what i ended up during after find this thread: forum.linuxcnc.org/20-g-code/27055-machi...m-g-code-hal-support
o<probe_corner_vice> sub
G91
#<start_x> = 213
#<start_y> = 150
#<start_z> = -104
G28.1
(Go to probe start off point)
F[#<_ini[PROBE]MEASURE_RETRACT_VELOCITY>*2]
G38.3 X[-1*[#5161 - #<start_x> ]]
G38.3 Y[-1*[#5162 - #<start_y> ]]
G38.3 Z[-1*[#5163 - #<start_z> ]]
(print, Probing +X direction )
o<xplus> call
(print, set zero also with vice fixed block offset)
G10 L20 P0 X[0 + 49.599 + #<_ini[PROBE]MEASURE_RETRACT_DISTANCE>]
G91
G38.3 Z20
G38.3 X10
o<zminus> call
G91
G38.3 Y20
G38.3 Z-7
o<yminus> call
(set zero also with vice fixed block offset)
G10 L20 P0 Y[0 - 33.597 + #<_ini[PROBE]MEASURE_RETRACT_DISTANCE>]
o<probe_corner_vice> endsub
M2
The following user(s) said Thank You: tommylight
Please Log in or Create an account to join the conversation.
13 Mar 2021 01:01 #202044
by andypugh
The #<hal_.....> parameters return the value of the HAL pin at the time that G-code execution started. (and occasionally update during execution, but not in a dependable way)
If you want a live state, use G38 to get the probe positions, and M65 (and friends) to read values from HAL.
Replied by andypugh on topic [solved]HAL pins acting differently in subroutine of Gcode script
Why is the pin behaving differently in my .ngc script?
The #<hal_.....> parameters return the value of the HAL pin at the time that G-code execution started. (and occasionally update during execution, but not in a dependable way)
If you want a live state, use G38 to get the probe positions, and M65 (and friends) to read values from HAL.
The following user(s) said Thank You: Stormholt
Please Log in or Create an account to join the conversation.
- GCode and Part Programs
- O Codes (subroutines) and NGCGUI
- [solved]HAL pins acting differently in subroutine of Gcode script
Time to create page: 0.064 seconds