Advanced Search

Yeah just change it to match the name in the ini file, I think the names are pretty agnostic, think variables or similar in C, with a convention in naming that makes it more readable. As long as the value on the right hand side is correct.
If I'm wrong you have my permission to beat me with a stick.
Cheers
Rob

Nevermind, I just tried to run QtDragon and got the following error:
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.2
Machine configuration directory is '/home/cnc/linuxcnc/configs/sim.qtdragon.qtdragon_xyz'
Machine configuration file is 'qtdragon_metric.ini'
INIFILE=/home/cnc/linuxcnc/configs/sim.qtdragon.qtdragon_xyz/qtdragon_metric.ini
VERSION=1.1
PARAMETER_FILE=qtdragon.var
TPMOD=
HOMEMOD=
TASK=milltask
HALUI=halui
DISPLAY=qtvcp qtdragon
COORDINATES=XYZ
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
Starting HAL User Interface program: halui
linuxcnc TPMOD=tpmod HOMEMOD=homemod EMCMOT=motmod
Found file(lib): /usr/share/linuxcnc/hallib/core_sim.hal
Found file(lib): /usr/share/linuxcnc/hallib/simulated_home.hal
Starting TASK program: milltask
Starting DISPLAY program: qtvcp
Unexpected realtime delay on task 0 with period 100000
This Message will only display once per session.
Run the Latency Test and resolve before continuing.

Shutting down and cleaning up LinuxCNC...
task: 1466 cycles, min=0.000018, max=0.017806, avg=0.010056, 0 latency excursions (> 10x expected cycle time of 0.010000s)
Removing HAL_LIB, RTAPI, and Real Time OS modules
Removing NML shared memory segments

Debug file information:
Note: Using POSIX realtime
Unexpected realtime delay on task 0 with period 100000
This Message will only display once per session.
Run the Latency Test and resolve before continuing.
link (updating variable file): No such file or directory
QStandardPaths: wrong permissions on runtime directory /run/user/1000, 0770 instead of 0700
[QTvcp.QTVCP.LIB.SYS_NOTIFY][[33mWARNING[0m] Desktop Notify not available:: org.freedesktop.DBus.Error.ServiceUnknown: The name org.freedesktop.Notifications was not provided by any .service files (sys_notify.py:71)
[QTvcp.QTVCP.LIB.QT_NGCGUI.NGCGUI][[33mWARNING[0m] The ngc_sub path does not exist: /home/cnc/nc_files/ngcgui_lib/slot.ngc (ngcgui.py:508)
[QTvcp.QTVCP.LIB.QT_NGCGUI.NGCGUI][[33mWARNING[0m] The ngc_sub path does not exist: /home/cnc/nc_files/ngcgui_lib/qpocket.ngc (ngcgui.py:508)
/usr/bin/linuxcnc: line 977: 9651 Segmentation fault $EMCDISPLAY -ini "$INIFILE" $EMCDISPLAYARGS $EXTRA_ARGS
9611
9647
Stopping realtime threads
Unloading hal components
Note: Using POSIX realtime

All I can add is a bit of advice on replacing the chip.
My method of removal is to carefully cut the leads on the chip, not too much pressure just lightly with an exacto knife. Then clean up the pads with desoldering braid.
There's also the flood method, but it requires some very deft action with the soldering iron.
Replacement is pretty easy, lookup the "drag method" on YouTube.
If you have experience with a proper desoldering station and hot air gun, ignore what I've said as you probably realised I'm a ham fisted Aussie.

except you are confused between the torch tip and the shield. Some torches (Hypertherm, and Thermal Dynamcs for example) Have a seperate shield that is not shorted to the workpiece.

So in general if you have an exposed tip you can't do ohmic sensing because its shorted to the material.

Some machines (ie Swiftcut) lower a seperate probe and ohmic probe off that. This can be done fairly easily in QTplasmac with a pneumatic cylinder as all the required signals are there.

I had burned up a few outputs on my 7i84, was able to replace the chip, its the same one as above it in the top row. Worked ever since. As for the blown chip, do the relays have diodes? Is there any potential for a spark from AC to travel back to the mesa from the relay? I personally use mosfet output protectors to protect the expensive mesa cards

Yeah, an instant dead short on the 24V rail could damage the output chips.
It may be repairable by replacing (probably both) NCV7608s
Unfortunately they are obsolete so a bit hard to find, I can probably
mail a couple to you if you want to try.

To make sure the damage is limited to the output chips, so worth repairing,
you could remove the output chips and see if you still have communication
with the 7I84.

Other option would be to replace it with a 7I84U (which is fully compatible
and a bit more rugged)