Search Results (Searched for: Proma THC)
- tommylight

23 Oct 2025 21:14
Replied by tommylight on topic torch moving UP when it should be moving DOWN
torch moving UP when it should be moving DOWN
Category: Plasmac
-Turn OFF the plasma
-draw a circle in the wizard, some 10cm diameter
-set the Proma THC150 to test mode with at least 5 seconds of time between changes
-put something about 3-5cm above the plate for the probing and remove after probe
-run the circle with the torch ON in QtPlasmaC
Do not turn the plasma ON while testing this.
-draw a circle in the wizard, some 10cm diameter
-set the Proma THC150 to test mode with at least 5 seconds of time between changes
-put something about 3-5cm above the plate for the probing and remove after probe
-run the circle with the torch ON in QtPlasmaC
Do not turn the plasma ON while testing this.
- distro88
- distro88
23 Oct 2025 18:32 - 23 Oct 2025 18:33
torch moving UP when it should be moving DOWN was created by distro88
torch moving UP when it should be moving DOWN
Category: Plasmac
Hello everyone,
I’m having a strange issue with QtPlasmaC (version 2.9.238 / LinuxCNC 2.9.2) and my PROMA THC 150 connected to a Mesa 7i92 card.
Everything on my machine moves correctly — all axes jog fine, torch on/off works, ARC OK is detected correctly, and the THC UP and DOWN inputs show properly in HAL meter.
However, during cutting:
When the THC UP signal is active, the torch moves up
When the THC DOWN signal is active, the torch moves up instead of down
Both UP and DOWN signals appear normally in HAL meter as true/false.
Here’s my setup:
Controller: Mesa 7i92 + db25 bib (raw pins)
Plasma: PROMA THC 150
QtPlasmaC version: 2.9.238 (LinuxCNC 2.9.2)
QtPlasmaC Mode: External THC (UP/DOWN/ARC OK)
THC wiring: optocoupled to Mesa inputs
Firmware: 7i92_7i76x1D.
I’ll attach my .hal and .ini files below.
.hal[/code]
I’m having a strange issue with QtPlasmaC (version 2.9.238 / LinuxCNC 2.9.2) and my PROMA THC 150 connected to a Mesa 7i92 card.
Everything on my machine moves correctly — all axes jog fine, torch on/off works, ARC OK is detected correctly, and the THC UP and DOWN inputs show properly in HAL meter.
However, during cutting:
When the THC UP signal is active, the torch moves up
When the THC DOWN signal is active, the torch moves up instead of down
Both UP and DOWN signals appear normally in HAL meter as true/false.
Here’s my setup:
Controller: Mesa 7i92 + db25 bib (raw pins)
Plasma: PROMA THC 150
QtPlasmaC version: 2.9.238 (LinuxCNC 2.9.2)
QtPlasmaC Mode: External THC (UP/DOWN/ARC OK)
THC wiring: optocoupled to Mesa inputs
Firmware: 7i92_7i76x1D.
I’ll attach my .hal and .ini files below.
.hal
# Generated by PNCconf at Wed Oct 22 23:20:44 2025
# Using LinuxCNC version: Master (2.9)
# If you make changes to this file, they will be
# overwritten when you run PNCconf again
loadrt [KINS]KINEMATICS
loadrt [EMCMOT]EMCMOT servo_period_nsec=[EMCMOT]SERVO_PERIOD num_joints=[KINS]JOINTS num_spindles=[TRAJ]SPINDLES
loadrt hostmot2
loadrt hm2_eth board_ip="10.10.10.10" config="num_encoders=1 num_pwmgens=0 num_stepgens=5 sserial_port_0=00xxxxxx"
setp hm2_7i92.0.watchdog.timeout_ns 5000000
loadrt pid names=pid.x,pid.y,pid.y2,pid.z,pid.s
loadrt plasmac
addf hm2_7i92.0.read servo-thread
addf motion-command-handler servo-thread
addf motion-controller servo-thread
addf pid.x.do-pid-calcs servo-thread
addf pid.y.do-pid-calcs servo-thread
addf pid.y2.do-pid-calcs servo-thread
addf pid.z.do-pid-calcs servo-thread
addf pid.s.do-pid-calcs servo-thread
addf plasmac servo-thread
addf hm2_7i92.0.write servo-thread
setp hm2_7i92.0.dpll.01.timer-us -50
setp hm2_7i92.0.stepgen.timer-number 1
# ---PLASMA INPUT DEBOUNCE---
#values for these are in custom.hal
loadrt dbounce names=db_breakaway,db_float,db_ohmic,db_arc-ok
addf db_float servo-thread
addf db_ohmic servo-thread
addf db_breakaway servo-thread
addf db_arc-ok servo-thread
# ---JOINT ASSOCIATED WITH THE Z AXIS---
net plasmac:axis-position joint.3.pos-fb => plasmac.axis-z-position
# ---PLASMA INPUTS---
# ---all modes---
net plasmac:float-switch => db_float.in
net plasmac:breakaway => db_breakaway.in
net plasmac:ohmic-probe => db_ohmic.in
net plasmac:ohmic-sense-in => plasmac.ohmic-sense-in
# ---modes 0 & 1
net plasmac:arc-voltage-in => plasmac.arc-voltage-in
# ---modes 1 & 2
net plasmac:arc-ok-in => db_arc-ok.in
# ---mode 2
net plasmac:move-up <= plasmac.move-up
net plasmac:move-down <= plasmac.move-down
# ---PLASMA OUTPUTS---
# ---all modes---
net plasmac:ohmic-enable <= plasmac.ohmic-enable
net plasmac:scribe-arm <= plasmac.scribe-arm
net plasmac:scribe-on <= plasmac.scribe-on
# external output signals
# --- PLASMAC:TORCH-ON ---
setp hm2_7i92.0.gpio.030.is_output true
net plasmac:torch-on => hm2_7i92.0.gpio.030.out
setp hm2_7i92.0.gpio.030.invert_output true
# --- PLASMAC:LASER-ON ---
setp hm2_7i92.0.gpio.031.is_output true
net plasmac:laser-on => hm2_7i92.0.gpio.031.out
# --- DOUT-00 ---
setp hm2_7i92.0.gpio.032.is_output true
net dout-00 => hm2_7i92.0.gpio.032.out
# --- DOUT-01 ---
setp hm2_7i92.0.gpio.033.is_output true
#qtplasmac uses digital output dout-01:
#net dout-01 => hm2_7i92.0.gpio.033.out
# external input signals
# --- MIN-HOME-X ---
net min-home-x <= hm2_7i92.0.gpio.018.in
# --- MIN-HOME-Y ---
net min-home-y <= hm2_7i92.0.gpio.019.in
# --- MIN-HOME-Y2 ---
net min-home-y2 <= hm2_7i92.0.gpio.020.in
# --- MAX-HOME-Z ---
net max-home-z <= hm2_7i92.0.gpio.021.in
# --- PLASMAC:FLOAT-SWITCH ---
net plasmac:float-switch <= hm2_7i92.0.gpio.022.in
# --- PLASMAC:BREAKAWAY ---
net plasmac:breakaway <= hm2_7i92.0.gpio.023.in
# --- PLASMAC:ARC-OK-IN ---
net plasmac:arc-ok-in <= hm2_7i92.0.gpio.024.in
# --- PLASMAC:MOVE-UP ---
net plasmac:move-up <= hm2_7i92.0.gpio.025.in
# --- PLASMAC:MOVE-DOWN ---
net plasmac:move-down <= hm2_7i92.0.gpio.026.in
# --- ESTOP-EXT ---
net estop-ext <= hm2_7i92.0.gpio.027.in_not
#*******************
# AXIS X JOINT 0
#*******************
setp pid.x.Pgain [JOINT_0]P
setp pid.x.Igain [JOINT_0]I
setp pid.x.Dgain [JOINT_0]D
setp pid.x.bias [JOINT_0]BIAS
setp pid.x.FF0 [JOINT_0]FF0
setp pid.x.FF1 [JOINT_0]FF1
setp pid.x.FF2 [JOINT_0]FF2
setp pid.x.deadband [JOINT_0]DEADBAND
setp pid.x.maxoutput [JOINT_0]MAX_OUTPUT
setp pid.x.error-previous-target true
# This setting is to limit bogus stepgen
# velocity corrections caused by position
# feedback sample time jitter.
setp pid.x.maxerror 0.012700
net x-index-enable => pid.x.index-enable
net x-enable => pid.x.enable
net x-pos-cmd => pid.x.command
net x-pos-fb => pid.x.feedback
net x-output <= pid.x.output
# Step Gen signals/setup
setp hm2_7i92.0.stepgen.00.dirsetup [JOINT_0]DIRSETUP
setp hm2_7i92.0.stepgen.00.dirhold [JOINT_0]DIRHOLD
setp hm2_7i92.0.stepgen.00.steplen [JOINT_0]STEPLEN
setp hm2_7i92.0.stepgen.00.stepspace [JOINT_0]STEPSPACE
setp hm2_7i92.0.stepgen.00.position-scale [JOINT_0]STEP_SCALE
setp hm2_7i92.0.stepgen.00.step_type 0
setp hm2_7i92.0.stepgen.00.control-type 1
setp hm2_7i92.0.stepgen.00.maxaccel [JOINT_0]STEPGEN_MAXACCEL
setp hm2_7i92.0.stepgen.00.maxvel [JOINT_0]STEPGEN_MAXVEL
# ---closedloop stepper signals---
net x-pos-cmd <= joint.0.motor-pos-cmd
net x-vel-cmd <= joint.0.vel-cmd
net x-output => hm2_7i92.0.stepgen.00.velocity-cmd
net x-pos-fb <= hm2_7i92.0.stepgen.00.position-fb
net x-pos-fb => joint.0.motor-pos-fb
net x-enable <= joint.0.amp-enable-out
net x-enable => hm2_7i92.0.stepgen.00.enable
# ---setup home / limit switch signals---
net min-home-x => joint.0.home-sw-in
net min-home-x => joint.0.neg-lim-sw-in
net x-pos-limit => joint.0.pos-lim-sw-in
#*******************
# AXIS Y JOINT 1
#*******************
setp pid.y.Pgain [JOINT_1]P
setp pid.y.Igain [JOINT_1]I
setp pid.y.Dgain [JOINT_1]D
setp pid.y.bias [JOINT_1]BIAS
setp pid.y.FF0 [JOINT_1]FF0
setp pid.y.FF1 [JOINT_1]FF1
setp pid.y.FF2 [JOINT_1]FF2
setp pid.y.deadband [JOINT_1]DEADBAND
setp pid.y.maxoutput [JOINT_1]MAX_OUTPUT
setp pid.y.error-previous-target true
# This setting is to limit bogus stepgen
# velocity corrections caused by position
# feedback sample time jitter.
setp pid.y.maxerror 0.012700
net y-index-enable => pid.y.index-enable
net y-enable => pid.y.enable
net y-pos-cmd => pid.y.command
net y-pos-fb => pid.y.feedback
net y-output <= pid.y.output
# Step Gen signals/setup
setp hm2_7i92.0.stepgen.01.dirsetup [JOINT_1]DIRSETUP
setp hm2_7i92.0.stepgen.01.dirhold [JOINT_1]DIRHOLD
setp hm2_7i92.0.stepgen.01.steplen [JOINT_1]STEPLEN
setp hm2_7i92.0.stepgen.01.stepspace [JOINT_1]STEPSPACE
setp hm2_7i92.0.stepgen.01.position-scale [JOINT_1]STEP_SCALE
setp hm2_7i92.0.stepgen.01.step_type 0
setp hm2_7i92.0.stepgen.01.control-type 1
setp hm2_7i92.0.stepgen.01.maxaccel [JOINT_1]STEPGEN_MAXACCEL
setp hm2_7i92.0.stepgen.01.maxvel [JOINT_1]STEPGEN_MAXVEL
# ---closedloop stepper signals---
net y-pos-cmd <= joint.1.motor-pos-cmd
net y-vel-cmd <= joint.1.vel-cmd
net y-output => hm2_7i92.0.stepgen.01.velocity-cmd
net y-pos-fb <= hm2_7i92.0.stepgen.01.position-fb
net y-pos-fb => joint.1.motor-pos-fb
net y-enable <= joint.1.amp-enable-out
net y-enable => hm2_7i92.0.stepgen.01.enable
# ---setup home / limit switch signals---
net min-home-y => joint.1.home-sw-in
net min-home-y => joint.1.neg-lim-sw-in
net y-pos-limit => joint.1.pos-lim-sw-in
#*******************
# Tandem AXIS Y2 JOINT 2
#*******************
setp pid.y2.Pgain [JOINT_2]P
setp pid.y2.Igain [JOINT_2]I
setp pid.y2.Dgain [JOINT_2]D
setp pid.y2.bias [JOINT_2]BIAS
setp pid.y2.FF0 [JOINT_2]FF0
setp pid.y2.FF1 [JOINT_2]FF1
setp pid.y2.FF2 [JOINT_2]FF2
setp pid.y2.deadband [JOINT_2]DEADBAND
setp pid.y2.maxoutput [JOINT_2]MAX_OUTPUT
setp pid.y2.error-previous-target true
# This setting is to limit bogus stepgen
# velocity corrections caused by position
# feedback sample time jitter.
setp pid.y2.maxerror 0.012700
net y2-index-enable => pid.y2.index-enable
net y2-enable => pid.y2.enable
net y2-pos-cmd => pid.y2.command
net y2-pos-fb => pid.y2.feedback
net y2-output <= pid.y2.output
# Step Gen signals/setup for tandem axis
setp hm2_7i92.0.stepgen.04.dirsetup [JOINT_2]DIRSETUP
setp hm2_7i92.0.stepgen.04.dirhold [JOINT_2]DIRHOLD
setp hm2_7i92.0.stepgen.04.steplen [JOINT_2]STEPLEN
setp hm2_7i92.0.stepgen.04.stepspace [JOINT_2]STEPSPACE
setp hm2_7i92.0.stepgen.04.position-scale [JOINT_2]STEP_SCALE
setp hm2_7i92.0.stepgen.04.step_type 0
setp hm2_7i92.0.stepgen.04.control-type 1
setp hm2_7i92.0.stepgen.04.maxaccel [JOINT_2]STEPGEN_MAXACCEL
setp hm2_7i92.0.stepgen.04.maxvel [JOINT_2]STEPGEN_MAXVEL
# ---closedloop stepper signals---
net y2-pos-cmd <= joint.2.motor-pos-cmd
net y2-vel-cmd <= joint.2.vel-cmd
net y2-output => hm2_7i92.0.stepgen.04.velocity-cmd
net y2-pos-fb <= hm2_7i92.0.stepgen.04.position-fb
net y2-pos-fb => joint.2.motor-pos-fb
net y2-enable <= joint.2.amp-enable-out
net y2-enable => hm2_7i92.0.stepgen.04.enable
# ---setup home / limit switch signals---
net min-home-y2 => joint.2.home-sw-in
net min-home-y2 => joint.2.neg-lim-sw-in
net y2-pos-limit => joint.2.pos-lim-sw-in
#*******************
# AXIS Z JOINT 3
#*******************
setp pid.z.Pgain [JOINT_3]P
setp pid.z.Igain [JOINT_3]I
setp pid.z.Dgain [JOINT_3]D
setp pid.z.bias [JOINT_3]BIAS
setp pid.z.FF0 [JOINT_3]FF0
setp pid.z.FF1 [JOINT_3]FF1
setp pid.z.FF2 [JOINT_3]FF2
setp pid.z.deadband [JOINT_3]DEADBAND
setp pid.z.maxoutput [JOINT_3]MAX_OUTPUT
setp pid.z.error-previous-target true
# This setting is to limit bogus stepgen
# velocity corrections caused by position
# feedback sample time jitter.
setp pid.z.maxerror 0.012700
net z-index-enable => pid.z.index-enable
net z-enable => pid.z.enable
net z-pos-cmd => pid.z.command
net z-pos-fb => pid.z.feedback
net z-output <= pid.z.output
# Step Gen signals/setup
setp hm2_7i92.0.stepgen.03.dirsetup [JOINT_3]DIRSETUP
setp hm2_7i92.0.stepgen.03.dirhold [JOINT_3]DIRHOLD
setp hm2_7i92.0.stepgen.03.steplen [JOINT_3]STEPLEN
setp hm2_7i92.0.stepgen.03.stepspace [JOINT_3]STEPSPACE
setp hm2_7i92.0.stepgen.03.position-scale [JOINT_3]STEP_SCALE
setp hm2_7i92.0.stepgen.03.step_type 0
setp hm2_7i92.0.stepgen.03.control-type 1
setp hm2_7i92.0.stepgen.03.maxaccel [JOINT_3]STEPGEN_MAXACCEL
setp hm2_7i92.0.stepgen.03.maxvel [JOINT_3]STEPGEN_MAXVEL
# ---closedloop stepper signals---
net z-pos-cmd <= joint.3.motor-pos-cmd
net z-vel-cmd <= joint.3.vel-cmd
net z-output => hm2_7i92.0.stepgen.03.velocity-cmd
net z-pos-fb <= hm2_7i92.0.stepgen.03.position-fb
net z-pos-fb => joint.3.motor-pos-fb
net z-enable <= joint.3.amp-enable-out
net z-enable => hm2_7i92.0.stepgen.03.enable
# ---setup home / limit switch signals---
net max-home-z => joint.3.home-sw-in
net z-neg-limit => joint.3.neg-lim-sw-in
net max-home-z => joint.3.pos-lim-sw-in
# ---motion control signals---
net in-position <= motion.in-position
net machine-is-enabled <= motion.motion-enabled
# ---digital in / out signals---
net dout-00 <= motion.digital-out-00
#qtplasmac uses digital output dout-01:
#net dout-01 <= motion.digital-out-01
# ---estop signals---
net estop-out <= iocontrol.0.user-enable-out
net estop-ext => iocontrol.0.emc-enable-in
# ---QTPLASMAC TOOLCHANGE PASSTHROUGH---
net tool:change iocontrol.0.tool-change => iocontrol.0.tool-changed
net tool:prep iocontrol.0.tool-prepare => iocontrol.0.tool-prepared
.ini
[code]# Generated by PNCconf at Wed Oct 22 23:20:44 2025
# Using LinuxCNC version: Master (2.9)
# If you make changes to this file, they will be
# overwritten when you run PNCconf again
[EMC]
MACHINE = test-2
DEBUG = 0
VERSION = 1.1
[DISPLAY]
DISPLAY = qtvcp qtplasmac
POSITION_OFFSET = RELATIVE
POSITION_FEEDBACK = ACTUAL
MAX_FEED_OVERRIDE = 2.000000
INTRO_GRAPHIC = linuxcnc.gif
INTRO_TIME = 5
PROGRAM_PREFIX = /home/x/linuxcnc/nc_files
INCREMENTS = 10mm 1mm .1mm .01mm .001mm
POSITION_FEEDBACK = ACTUAL
DEFAULT_LINEAR_VELOCITY = 6.000000
MAX_LINEAR_VELOCITY = 25.000000
MIN_LINEAR_VELOCITY = 0.500000
DEFAULT_ANGULAR_VELOCITY = 12.000000
MAX_ANGULAR_VELOCITY = 180.000000
MIN_ANGULAR_VELOCITY = 1.666667
GEOMETRY = xyz
CYCLE_TIME = 100
[FILTER]
PROGRAM_EXTENSION = .ngc,.nc,.tap GCode File (*.ngc, *.nc, *.tap)
ngc = qtplasmac_gcode
nc = qtplasmac_gcode
tap = qtplasmac_gcode
[TASK]
TASK = milltask
CYCLE_TIME = 0.010
[RS274NGC]
PARAMETER_FILE = linuxcnc.var
RS274NGC_STARTUP_CODE = G21 G40 G49 G80 G90 G92.1 G94 G97 M52P1
SUBROUTINE_PATH = ./:../../nc_files
USER_M_PATH = ./:../../nc_files
[EMCMOT]
EMCMOT = motmod
COMM_TIMEOUT = 1.0
SERVO_PERIOD = 1000000
[HMOT]
# **** This is for info only ****
CARD0=hm2_7i92.0
[HAL]
HALUI = halui
HALFILE = test-2.hal
HALFILE = qtplasmac_comp.hal
HALFILE = custom.hal
POSTGUI_HALFILE = custom_postgui.hal
SHUTDOWN = shutdown.hal
[HALUI]
[KINS]
JOINTS = 4
KINEMATICS = trivkins coordinates=XYYZ
[TRAJ]
SPINDLES = 3
COORDINATES = XYYZ
LINEAR_UNITS = mm
ANGULAR_UNITS = degree
DEFAULT_LINEAR_VELOCITY = 2.50
MAX_LINEAR_VELOCITY = 25.00
[EMCIO]
EMCIO = io
CYCLE_TIME = 0.100
TOOL_TABLE = tool.tbl
#******************************************
[AXIS_X]
# MAX_VEL & MAX_ACC need to be twice the corresponding joint value
MAX_VELOCITY = 50.0
MAX_ACCELERATION = 1500.0
OFFSET_AV_RATIO = 0.5
MIN_LIMIT = -0.01
MAX_LIMIT = 2000.0
[JOINT_0]
TYPE = LINEAR
HOME = 0.0
FERROR = 10.0
MIN_FERROR = 1.0
MAX_VELOCITY = 25.0
MAX_ACCELERATION = 750.0
# The values below should be 25% larger than MAX_VELOCITY and MAX_ACCELERATION
# If using BACKLASH compensation STEPGEN_MAXACCEL should be 100% larger.
STEPGEN_MAXVEL = 31.25
STEPGEN_MAXACCEL = 937.50
P = 1000.0
I = 0.0
D = 0.0
FF0 = 0.0
FF1 = 1.0
FF2 = 0.0
BIAS = 0.0
DEADBAND = 0.0
MAX_OUTPUT = 0.0
# these are in nanoseconds
DIRSETUP = 10000
DIRHOLD = 10000
STEPLEN = 5000
STEPSPACE = 5000
STEP_SCALE = 100.0
MIN_LIMIT = -0.01
MAX_LIMIT = 2000.0
HOME_OFFSET = 0.000000
HOME_SEARCH_VEL = -1.000000
HOME_LATCH_VEL = 0.500000
HOME_FINAL_VEL = 0.000000
HOME_USE_INDEX = NO
HOME_IGNORE_LIMITS = YES
HOME_SEQUENCE = 2
#******************************************
#******************************************
[AXIS_Y]
# MAX_VEL & MAX_ACC need to be twice the corresponding joint value
MAX_VELOCITY = 50.0
MAX_ACCELERATION = 1500.0
OFFSET_AV_RATIO = 0.5
MIN_LIMIT = -0.01
MAX_LIMIT = 3000.0
[JOINT_1]
TYPE = LINEAR
HOME = 0.0
FERROR = 10.0
MIN_FERROR = 1.0
MAX_VELOCITY = 25.0
MAX_ACCELERATION = 750.0
# The values below should be 25% larger than MAX_VELOCITY and MAX_ACCELERATION
# If using BACKLASH compensation STEPGEN_MAXACCEL should be 100% larger.
STEPGEN_MAXVEL = 31.25
STEPGEN_MAXACCEL = 937.50
P = 1000.0
I = 0.0
D = 0.0
FF0 = 0.0
FF1 = 1.0
FF2 = 0.0
BIAS = 0.0
DEADBAND = 0.0
MAX_OUTPUT = 0.0
# these are in nanoseconds
DIRSETUP = 10000
DIRHOLD = 10000
STEPLEN = 5000
STEPSPACE = 5000
STEP_SCALE = 100.0
MIN_LIMIT = -0.01
MAX_LIMIT = 3000.0
HOME_OFFSET = 0.000000
HOME_SEARCH_VEL = -1.000000
HOME_LATCH_VEL = 0.500000
HOME_FINAL_VEL = 0.000000
HOME_USE_INDEX = NO
HOME_IGNORE_LIMITS = YES
HOME_SEQUENCE = -3
[JOINT_2]
TYPE = LINEAR
HOME = 0.0
FERROR = 10.0
MIN_FERROR = 1.0
MAX_VELOCITY = 25.0
MAX_ACCELERATION = 750.0
# The values below should be 25% larger than MAX_VELOCITY and MAX_ACCELERATION
# If using BACKLASH compensation STEPGEN_MAXACCEL should be 100% larger.
STEPGEN_MAXVEL = 31.25
STEPGEN_MAXACCEL = 937.50
P = 1000.0
I = 0.0
D = 0.0
FF0 = 0.0
FF1 = 1.0
FF2 = 0.0
BIAS = 0.0
DEADBAND = 0.0
MAX_OUTPUT = 0.0
# these are in nanoseconds
DIRSETUP = 10000
DIRHOLD = 10000
STEPLEN = 5000
STEPSPACE = 5000
STEP_SCALE = 100.0
MIN_LIMIT = -0.01
MAX_LIMIT = 3000.0
HOME_OFFSET = 0.000000
HOME_SEARCH_VEL = -1.000000
HOME_LATCH_VEL = 0.500000
HOME_FINAL_VEL = 0.000000
HOME_USE_INDEX = NO
HOME_IGNORE_LIMITS = YES
HOME_SEQUENCE = -3
#******************************************
#******************************************
[AXIS_Z]
# MAX_VEL & MAX_ACC need to be twice the corresponding joint value
MAX_VELOCITY = 50.0
MAX_ACCELERATION = 1500.0
OFFSET_AV_RATIO = 0.5
MIN_LIMIT = -200.0
MAX_LIMIT = 0.01
[JOINT_3]
TYPE = LINEAR
HOME = 0.0
FERROR = 10.0
MIN_FERROR = 1.0
MAX_VELOCITY = 25.0
MAX_ACCELERATION = 750.0
# The values below should be 25% larger than MAX_VELOCITY and MAX_ACCELERATION
# If using BACKLASH compensation STEPGEN_MAXACCEL should be 100% larger.
STEPGEN_MAXVEL = 31.25
STEPGEN_MAXACCEL = 937.50
P = 1000.0
I = 0.0
D = 0.0
FF0 = 0.0
FF1 = 1.0
FF2 = 0.0
BIAS = 0.0
DEADBAND = 0.0
MAX_OUTPUT = 0.0
# these are in nanoseconds
DIRSETUP = 10000
DIRHOLD = 10000
STEPLEN = 5000
STEPSPACE = 5000
STEP_SCALE = 100.0
MIN_LIMIT = -200.0
MAX_LIMIT = 0.01
HOME_OFFSET = 0.000000
HOME_SEARCH_VEL = -1.000000
HOME_LATCH_VEL = 0.500000
HOME_FINAL_VEL = 0.000000
HOME_USE_INDEX = NO
HOME_IGNORE_LIMITS = YES
HOME_SEQUENCE = 1
#******************************************
Any help or working HAL example with PROMA 150 + Mesa hardware would be greatly appreciated!
Thank you in advance - tommylight

23 Oct 2025 16:10
Replied by tommylight on topic Stahlwerk Plasma Cutters THC Interface
Stahlwerk Plasma Cutters THC Interface
Category: Plasma & Laser
Yes i am, i have 3 or 4 of those in daily use, 1 with Proma THC150 and others with Mesa THCAD.
I also have a china one with same electronics and pilot arc, the HF type, i intentionally wired the THCAD10 to the main terminals with 1MOhm resistors on each side, still in daily use for nearly a year, no issues.
The thing is, with correct wiring and grounding and shielding, it works fine, but any wiring error will result in burnt electronics the first time the torch fires, hence i refrain from advising such things.
I also have a china one with same electronics and pilot arc, the HF type, i intentionally wired the THCAD10 to the main terminals with 1MOhm resistors on each side, still in daily use for nearly a year, no issues.
The thing is, with correct wiring and grounding and shielding, it works fine, but any wiring error will result in burnt electronics the first time the torch fires, hence i refrain from advising such things.
- rodw

12 Oct 2025 19:08
Replied by rodw on topic Upgrade of CNC Plasma Cutting Table with Mesa 7i96S, THCAD-2 And MyOhmic PRO
Upgrade of CNC Plasma Cutting Table with Mesa 7i96S, THCAD-2 And MyOhmic PRO
Category: Driver Boards
Looks great. I will be interested in how you go with the My Ohmic Pro. I was sent an evaluation one and its beautifully engineered. I just had nothing to try it out on. The THCAD for Ohmic struggles on Water tables so hopefully it proves a more robust solution. Lukaz at Proma said he was very proud of the water handling of the My Ohmic Pro
Be sure to add an EMI filter on your mains input to avoid electrical noise. You can get them built into an IEC connector. even with a power switch and fuse built in.
Be sure to add an EMI filter on your mains input to avoid electrical noise. You can get them built into an IEC connector. even with a power switch and fuse built in.
- Hendrixx
- Hendrixx
10 Oct 2025 02:46
Any progress on QTLazerC or was created by Hendrixx
Any progress on QTLazerC or
Category: Other User Interfaces
The last cool thing i remeber reading or putting any effort into was the gentleman from Proma on a Monokrom thread asking people to beta test his. Capactive THC Analog DC converter, I wonder how that went? And then ther was the makerspace that hacked together a usable motion control to build their fiber system from some clever manipulation of QTPlasma . other then finding a laser power source which will happen sooner then laater "fingers cross"
- souh-hil

26 Sep 2025 09:57
Replied by souh-hil on topic Firmware Request for 7i92 – Plasma CNC Build
Firmware Request for 7i92 – Plasma CNC Build
Category: Driver Boards
Hello again everyone,First, I apologize for the late reply — I’ve been working on revising my plan and wiring, and it took longer than expected.I’ve updated my wiring/architecture plan (see attached diagram), and here’s where I’m at:
- Mesa 7i92 over Ethernet
- Two 5-axis breakout boards (5ABOB ×2)
- DM556 drivers for NEMA34 motors (3.5 Nm, 3 A/phase)
- THC Proma 150 for torche height control (Arc OK, Up, Down signals)
- Relays for torch, laser, pump, etc.
- E-stop, limits, probe via optoisolators
- Power supplies: 5 V/8 A, 24 V/3 A, 36 V/12 A
- With that setup (7i92 + 2 × 5ABOB), is the wiring architecture I’m proposing feasible?
- I was thinking of starting with the G540 HAL/INI config in pncconf as a base, then editing it . Is that a sensible approach, or is there a better workflow to generate a clean HAL/INI for this sort of layout?
- Kempinger
- Kempinger
05 Aug 2025 22:35 - 05 Aug 2025 22:35
Acr ok/Up/Down not working was created by Kempinger
Acr ok/Up/Down not working
Category: Plasmac
Hi guys,
I'm having some troble with my Plasmac setup: Signals for Up/Down/Arc do not show up in GUI, in HAL monitor pins from mesa 7i96s act like they should (Proma THC Compact set to Test mode). No response for "Virtual LEDs" in GUI. Tried idle and also duringe a simulated cutting operation.
Float-Switch works perfectly, also axis movement. Machine was configured using pncconf wizzard, set to mode 2.
Thanks for any information!
I'm having some troble with my Plasmac setup: Signals for Up/Down/Arc do not show up in GUI, in HAL monitor pins from mesa 7i96s act like they should (Proma THC Compact set to Test mode). No response for "Virtual LEDs" in GUI. Tried idle and also duringe a simulated cutting operation.
Float-Switch works perfectly, also axis movement. Machine was configured using pncconf wizzard, set to mode 2.
Thanks for any information!
- zzrzzr
- zzrzzr
20 Jul 2025 06:06
PlasmaC Voltage Divider was created by zzrzzr
PlasmaC Voltage Divider
Category: Plasmac
Hi,
i'm looking for a good plasmacutter that works with plasmac.
What if the plasmacutter doesn't have an internal voltage divider ? Then the THCAD 300 would be good, but its out of stock everywhere. What is the alternative if I want to use THAD 5 oder 10 ?
To buy a Proma voltage-divider or is there another professional-looking alternative ?
And maybe you can recommend a plasmacutter for plasmaC ?
Thanks.
i'm looking for a good plasmacutter that works with plasmac.
What if the plasmacutter doesn't have an internal voltage divider ? Then the THCAD 300 would be good, but its out of stock everywhere. What is the alternative if I want to use THAD 5 oder 10 ?
To buy a Proma voltage-divider or is there another professional-looking alternative ?
And maybe you can recommend a plasmacutter for plasmaC ?
Thanks.
- yngndrw
- yngndrw
27 Apr 2025 22:49
Replied by yngndrw on topic Thought experiment: Let's design a modern THC (+ Closed loop discussions)
Thought experiment: Let's design a modern THC (+ Closed loop discussions)
Category: Plasma & Laser
Okay, I don't think I've done a very good job of explaining what I was getting at and why. I also think in retrospect the suggestion of a modern THC may have been taken as an offensive dig at what's already in LinuxCNC - It's certainly not intended to be that way and my thoughts are not aimed at any one platform.
I'm in full agreement that an integrated system offers many tangible benefits over the completely separate systems that you can buy off the shelf today, both in terms of anti-dive and also in terms of co-location of configuration.
The point I was trying to make was that the standalone hardware that we have today is a frankly weird setup, which seems confused about responsibility. The Proma SD is the perfect example of this confusion, but even the non-SD version is still a bit confused.
To try and make my point clearer, consider motor drivers. The old way of closing the loop was to run everything back to the motion controller and have a dumb motor driver (or amplifier). The "modern" approach is to have two loops - A "smart" driver which closes the loop with the hardware, then a second closed loop between the motion controller and the motor driver. (Step/Direction out, fault in) The advantage of the new approach is that each unit is smaller and better defined, it allows you to change the motor/driver combination for any which follow the same contract. It also allows for a higher bandwidth control loop on the motor side of things.
My thoughts were the same for THC:
- The current standalone solutions are weird. (See above)
- The software solution is very similar to the old analogue motor driver solution, with one massive control loop over the top of everything.
- It therefore stands to reason that there's a version of the standalone solution that deals with target arc voltage rather than position, with two closed loops that are more akin to the modern drivers that we have. A solution which still supports the software THC benefits of anti-dive support. One which would be applicable to all motion controllers, just as motor drives are today. One that could even communicate with the motion controller over Ethercat.
In this scheme, the motion controller gets much simpler. It doesn't need to know or care about anti-dive, or how to pierce and dwell, or to know when to strip out Z motion or really know anything about plasma. It just needs to output coordinated target arc voltage as it does the positions for the other motors (Strip the units and Volts are the same as mm or inches to the motion planner), and it needs to output the current motion velocity so that the THC can deal with that complexity.
Is that a clearer and less offensive way of explaining it, or am I just spouting nonsense? I'm sorry if I am, it can be hard to explain something when it's stuck in your own head.
I'm in full agreement that an integrated system offers many tangible benefits over the completely separate systems that you can buy off the shelf today, both in terms of anti-dive and also in terms of co-location of configuration.
The point I was trying to make was that the standalone hardware that we have today is a frankly weird setup, which seems confused about responsibility. The Proma SD is the perfect example of this confusion, but even the non-SD version is still a bit confused.
To try and make my point clearer, consider motor drivers. The old way of closing the loop was to run everything back to the motion controller and have a dumb motor driver (or amplifier). The "modern" approach is to have two loops - A "smart" driver which closes the loop with the hardware, then a second closed loop between the motion controller and the motor driver. (Step/Direction out, fault in) The advantage of the new approach is that each unit is smaller and better defined, it allows you to change the motor/driver combination for any which follow the same contract. It also allows for a higher bandwidth control loop on the motor side of things.
My thoughts were the same for THC:
- The current standalone solutions are weird. (See above)
- The software solution is very similar to the old analogue motor driver solution, with one massive control loop over the top of everything.
- It therefore stands to reason that there's a version of the standalone solution that deals with target arc voltage rather than position, with two closed loops that are more akin to the modern drivers that we have. A solution which still supports the software THC benefits of anti-dive support. One which would be applicable to all motion controllers, just as motor drives are today. One that could even communicate with the motion controller over Ethercat.
In this scheme, the motion controller gets much simpler. It doesn't need to know or care about anti-dive, or how to pierce and dwell, or to know when to strip out Z motion or really know anything about plasma. It just needs to output coordinated target arc voltage as it does the positions for the other motors (Strip the units and Volts are the same as mm or inches to the motion planner), and it needs to output the current motion velocity so that the THC can deal with that complexity.
Is that a clearer and less offensive way of explaining it, or am I just spouting nonsense? I'm sorry if I am, it can be hard to explain something when it's stuck in your own head.
- tommylight

27 Apr 2025 21:03
Replied by tommylight on topic Thought experiment: Let's design a modern THC (+ Closed loop discussions)
Thought experiment: Let's design a modern THC (+ Closed loop discussions)
Category: Plasma & Laser
Went through this twice, still have no clue what ...
We have a modern THC, fully implemented in LinuxCNC, including PID and closed loop and everything, with a bit to much added functionality for my taste. All made possible by Mesa THCAD.
Have a look at PlasmaC and QtPlasmaC, everything mentioned is already there and working properly, and much more.
THC has a single purpose: to keep the torch the set amount of height from the material while cutting.
Everything else are added features that a THC might or might not have, be it in software or hardware.
-
Proma THC 150 SD is the stand alone version that intercepts step/dir signals from Z axis
Proma THC 150 sends UP/DOWN/ARC OK signals to PC, and the PC makes the moves, so not stand alone, and can be considered closed loop for sure.
We have a modern THC, fully implemented in LinuxCNC, including PID and closed loop and everything, with a bit to much added functionality for my taste. All made possible by Mesa THCAD.
Have a look at PlasmaC and QtPlasmaC, everything mentioned is already there and working properly, and much more.
THC has a single purpose: to keep the torch the set amount of height from the material while cutting.
Everything else are added features that a THC might or might not have, be it in software or hardware.
-
Proma THC 150 SD is the stand alone version that intercepts step/dir signals from Z axis
Proma THC 150 sends UP/DOWN/ARC OK signals to PC, and the PC makes the moves, so not stand alone, and can be considered closed loop for sure.
- yngndrw
- yngndrw
27 Apr 2025 16:25 - 27 Apr 2025 16:26
Thought experiment: Let's design a modern THC (+ Closed loop discussions) was created by yngndrw
Thought experiment: Let's design a modern THC (+ Closed loop discussions)
Category: Plasma & Laser
Hello,
Let me start off with the purpose of this thread. I've never built a plasma CNC and I've never used a THC. The purpose of this thread is partially to confirm some of the research I've done and partially to probe as a bit of a thought experiment, as from what I can see, things seem to be in a transitional state between a few control schemes. I don't know if what I've identified is valid, or if there's a reason behind it. Maybe it doesn't matter, but either way, I thought it might be fun to design a system (At a high level) from scratch and ask "what if?".
Let's take a step back and first talk about closed loop, older analogue controls and the like as that's quite important. (Or at least, my understanding. I'm basing some of this on an old Cincinnati Sabre 500 VMC with Fanuc controls I researched a while ago as I was looking to purchase it - It turns out that a 4t machine is a logistical nightmare, but the control findings were interesting.)
In ye-olde-days, you had motor drives with an analogue velocity signal. The drive didn't know what the position was, nor did it care. The motion control managed the position, and you had a full closed-loop setup. This was, I suspect, because back in those days, sharing digital signals over multiple devices was a pain, so it was easier to keep the digital stuff inside the motion controller and to have a fully analogue motor driver with analogue signals. An interesting part of this was the spindle motor orientation used for the tool changer - The spindle drive had a motor orientation board which was connected to the encoder. This meant that when the motion controller stopped the spindle, the spindle drive would automatically park it in a specific orientation. The motion controller didn't control this, it just told the drive to sort it out and the responsibilities were clear.
Next we have our standard step/direction drives, with stepper motors operating in a fully open loop. The motion controller assumes that when it commands a movement, that the motor and driver will keep up and hopes for the best. We know about the limitations, so let's not dwell.
After this, we have the hybrid closed-loop setups with step/direction signalling controlling either a "closed loop" stepper or an AC servo. (Which is closed-loop by nature) Some would say that these are not true closed-loop systems, but as long as there's a fault signal being fed back into the motion controller, it really is closed-loop by definition. Some servo drives allow a second machine encoder for increased accuracy.
Most of the more expensive Centroid offerings include ways to close the loop right back to the motion controller, but I believe this is more for compatibility with older hardware. (See above) I don't believe there's any benefit in a new setup as long as the motor drive can report a fault back to the motion controller; they are both closed-loop, just with different responsibility splits.
I wanted to take that detour about exactly what closed loop means because I think it applies to THC. There are many approaches, but I think it's also worth considering where the respective responsibilities should live between each component, and I think a good test is whether or not the system could, at least in theory, support buffered motion planning. I know that doesn't apply to LinuxCNC, but I think it's a good benchmark for responsibility splits either way.
As with motor drivers, there are many ways of approaching THC:
- You have "fully" stand-alone systems such as the Proma unit, which intercept the Z-axis motor control and over-ride it mid-cut.
- You have fully closed-loop systems where the THC is implemented within the motion controller in software with a hardware interface such as the Mesa THCAD.
I think most people would say that software solutions are superior as they can look ahead, implementing features such as anti-diving. However, from my research, I'd argue that the stand-alone systems are not actually standalone; there's a lot of confusion regarding responsibility, as both parts in these standalone systems control Z axis position. I'd also argue that a purely software solution isn't ideal when you start getting into Ethercat and certainly doesn't allow for offloading via buffered motion planning. I would propose that there's another way.
Fully stand-alone THC, with "fully" no longer in quotation marks. Consider the following statement: The motion controller does not care about the Z-axis position for a CNC plasma machine at all. It cares about the target arc voltage, it cares about anti-dive, it cares about the initial torch height - But it doesn't directly care about the torch height. What if the motion controller told the torch height controller about the target arc voltage, when to start/stop the torch, what initial torch height and dwell to use when starting, and when anti-dive should be considered? What if the THC handled probing and piercing itself, if it fully and directly controlled the Z axis, including the limit switches? What if the THC told the motion controller when it was good to start the motion, rather than just when the ARC is okay?
This is the step which I think is missing. You could wrap all of this up into an Ethercat device and it's a lot closer to being able to handle buffered motion. (Although it's not perfect, as the X/Y motor drivers would need to wait until the all-clear from the THC before they start their motion.) It could handle all things plasma, including gas and current control (E.g. Hypertherm's RS485 interface), it could report back all of the diagnostics (Such as current arc voltage, current torch height relative to the probe position, information about the torch tip. I think this would also be much closer aligned to the modern Fibre laser setups with how their focus control works.
I'm curious about people's thoughts. Have I made any mistakes or misunderstood anything? Is it nonsense or even just a waste of time? I'm also hoping my explanation on closed loop helped others understand what it really means, as it took quite a lot of research to get my head around what exactly it meant and why "proper" CNC machines used to have velocity control.
Let me start off with the purpose of this thread. I've never built a plasma CNC and I've never used a THC. The purpose of this thread is partially to confirm some of the research I've done and partially to probe as a bit of a thought experiment, as from what I can see, things seem to be in a transitional state between a few control schemes. I don't know if what I've identified is valid, or if there's a reason behind it. Maybe it doesn't matter, but either way, I thought it might be fun to design a system (At a high level) from scratch and ask "what if?".
Let's take a step back and first talk about closed loop, older analogue controls and the like as that's quite important. (Or at least, my understanding. I'm basing some of this on an old Cincinnati Sabre 500 VMC with Fanuc controls I researched a while ago as I was looking to purchase it - It turns out that a 4t machine is a logistical nightmare, but the control findings were interesting.)
In ye-olde-days, you had motor drives with an analogue velocity signal. The drive didn't know what the position was, nor did it care. The motion control managed the position, and you had a full closed-loop setup. This was, I suspect, because back in those days, sharing digital signals over multiple devices was a pain, so it was easier to keep the digital stuff inside the motion controller and to have a fully analogue motor driver with analogue signals. An interesting part of this was the spindle motor orientation used for the tool changer - The spindle drive had a motor orientation board which was connected to the encoder. This meant that when the motion controller stopped the spindle, the spindle drive would automatically park it in a specific orientation. The motion controller didn't control this, it just told the drive to sort it out and the responsibilities were clear.
Next we have our standard step/direction drives, with stepper motors operating in a fully open loop. The motion controller assumes that when it commands a movement, that the motor and driver will keep up and hopes for the best. We know about the limitations, so let's not dwell.
After this, we have the hybrid closed-loop setups with step/direction signalling controlling either a "closed loop" stepper or an AC servo. (Which is closed-loop by nature) Some would say that these are not true closed-loop systems, but as long as there's a fault signal being fed back into the motion controller, it really is closed-loop by definition. Some servo drives allow a second machine encoder for increased accuracy.
Most of the more expensive Centroid offerings include ways to close the loop right back to the motion controller, but I believe this is more for compatibility with older hardware. (See above) I don't believe there's any benefit in a new setup as long as the motor drive can report a fault back to the motion controller; they are both closed-loop, just with different responsibility splits.
I wanted to take that detour about exactly what closed loop means because I think it applies to THC. There are many approaches, but I think it's also worth considering where the respective responsibilities should live between each component, and I think a good test is whether or not the system could, at least in theory, support buffered motion planning. I know that doesn't apply to LinuxCNC, but I think it's a good benchmark for responsibility splits either way.
As with motor drivers, there are many ways of approaching THC:
- You have "fully" stand-alone systems such as the Proma unit, which intercept the Z-axis motor control and over-ride it mid-cut.
- You have fully closed-loop systems where the THC is implemented within the motion controller in software with a hardware interface such as the Mesa THCAD.
I think most people would say that software solutions are superior as they can look ahead, implementing features such as anti-diving. However, from my research, I'd argue that the stand-alone systems are not actually standalone; there's a lot of confusion regarding responsibility, as both parts in these standalone systems control Z axis position. I'd also argue that a purely software solution isn't ideal when you start getting into Ethercat and certainly doesn't allow for offloading via buffered motion planning. I would propose that there's another way.
Fully stand-alone THC, with "fully" no longer in quotation marks. Consider the following statement: The motion controller does not care about the Z-axis position for a CNC plasma machine at all. It cares about the target arc voltage, it cares about anti-dive, it cares about the initial torch height - But it doesn't directly care about the torch height. What if the motion controller told the torch height controller about the target arc voltage, when to start/stop the torch, what initial torch height and dwell to use when starting, and when anti-dive should be considered? What if the THC handled probing and piercing itself, if it fully and directly controlled the Z axis, including the limit switches? What if the THC told the motion controller when it was good to start the motion, rather than just when the ARC is okay?
This is the step which I think is missing. You could wrap all of this up into an Ethercat device and it's a lot closer to being able to handle buffered motion. (Although it's not perfect, as the X/Y motor drivers would need to wait until the all-clear from the THC before they start their motion.) It could handle all things plasma, including gas and current control (E.g. Hypertherm's RS485 interface), it could report back all of the diagnostics (Such as current arc voltage, current torch height relative to the probe position, information about the torch tip. I think this would also be much closer aligned to the modern Fibre laser setups with how their focus control works.
I'm curious about people's thoughts. Have I made any mistakes or misunderstood anything? Is it nonsense or even just a waste of time? I'm also hoping my explanation on closed loop helped others understand what it really means, as it took quite a lot of research to get my head around what exactly it meant and why "proper" CNC machines used to have velocity control.
- tommylight

14 Apr 2025 07:38
Replied by tommylight on topic Retrofitting my Fadal VMC15 to LinuxCNC w/MESA
Retrofitting my Fadal VMC15 to LinuxCNC w/MESA
Category: Milling Machines
What type of control do the drives/VFD take?
What encoders/resolvers are on the motors?
If they do turn out to be analog +-10V ones, a Mesa 7i97T should do just fine, and if you do need more I/O you can add a 7i84 with 32 inputs and 16 outputs.
Here are some topic to give you an idea of what is involved:
forum.linuxcnc.org/30-cnc-machines/31792...-sbz-130-01-retrofit
forum.linuxcnc.org/30-cnc-machines/33529-hurco-bmc-20p-retrofit
forum.linuxcnc.org/show-your-stuff/34986...nd-proma-thc?start=0
And detailed info on wiring and tuning
forum.linuxcnc.org/10-advanced-configura...to-example-mesa-7i77
What encoders/resolvers are on the motors?
If they do turn out to be analog +-10V ones, a Mesa 7i97T should do just fine, and if you do need more I/O you can add a 7i84 with 32 inputs and 16 outputs.
Here are some topic to give you an idea of what is involved:
forum.linuxcnc.org/30-cnc-machines/31792...-sbz-130-01-retrofit
forum.linuxcnc.org/30-cnc-machines/33529-hurco-bmc-20p-retrofit
forum.linuxcnc.org/show-your-stuff/34986...nd-proma-thc?start=0
And detailed info on wiring and tuning
forum.linuxcnc.org/10-advanced-configura...to-example-mesa-7i77
- rodw

14 Mar 2025 08:55
I had a job which I filled a 8' x 4' sheet with some flanges and small parts. I cut it in 3 sections on a 4' x 4' table and there were heaps of probing so over time I tweaked the probing routine heights etc. I was using my hypersensing which uses a THCAD for the ohmic sensing. it does not like Hypertherm machines on a water table but it would work for you by the look.
Part of the speed comes from the way it breaks contact on up travel because as soon as it senses a fall in voltage, probing finishes (before the contact is broken).
I've been sent a ohmic circuit from Proma Elextronika in Poland. Its a very nice piece of kit and have some very good reviews on it. This will by my water table solution.
Replied by rodw on topic QTPlasmaC post processor - SheetCam?
QTPlasmaC post processor - SheetCam?
Category: Plasmac
I assume you mean this oneI just watched your YouTube video on you high speed ohmic and it’s impressive.
I had a job which I filled a 8' x 4' sheet with some flanges and small parts. I cut it in 3 sections on a 4' x 4' table and there were heaps of probing so over time I tweaked the probing routine heights etc. I was using my hypersensing which uses a THCAD for the ohmic sensing. it does not like Hypertherm machines on a water table but it would work for you by the look.
Part of the speed comes from the way it breaks contact on up travel because as soon as it senses a fall in voltage, probing finishes (before the contact is broken).
I've been sent a ohmic circuit from Proma Elextronika in Poland. Its a very nice piece of kit and have some very good reviews on it. This will by my water table solution.
- Badutis
- Badutis
02 Feb 2025 17:10
Replied by Badutis on topic CNC Plasma cutters, DIY, building info and guide
CNC Plasma cutters, DIY, building info and guide
Category: Plasma & Laser
thanks tommylight for your quick reply. Well, I'm not sure about that in Arc Pilot, that's why I wrote likely. I relied on the information I was able to find on the Internet. However, I have no doubt that you are right and cutter is not an Arc Pilot. Does it change anything? I think I saw somewhere that you have implemented projects with HF plasma and THCAD300. Could you tell me where exactly those wires should be connected? anyway, if it is necessary to make this cutter work with CNC, I also have PROMA THC 150,
Time to create page: 2.132 seconds