Advanced Search

I'm converting over an old Koike Oxy Fuel table that has a Burny controller on it to run on Qtplasmac. Swapped out all the electronics. Can move the axes around how I want and it'll run whatever shape I program. However a few issues in running into, probably just me overlooking ini file settings.
1. The torch won't activate at all when the program is running. The torch only works when I manually hit the "Torch Pulse" button. 
2. I have a manually controlled Z Axis, no need for that auto height stuff on Oxy Fuel cause the height not being right is more forgiving. But the problem I run into is when I go to run a program without homing, it follows the path it should, but when I do home it goes to cut the shape and then the Z Axis starts moving on the screen and it throws the error "bottom limit reached while probing down". I feel like there's some simple solution that might fix both of these problems that I'm just not seeing. 
3. Also a third random question while I'm here, I know I can set various pierce times for different materials but it's there a way to force the machine into always manually piercing, like a M1. But in the parameters/in, I that itll pause and make me hit like cycle start or something to do the pierce. Cause while I can let it run auto, pierce times are more finicky with oxy fuel and it can vary day to day and plate to plate.

Did not work.

sudo apt purge --autoremove raspi-firmware
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
The following packages will be REMOVED:
  linux-image-6.1.0-35-rt-amd64 raspi-firmware*
0 upgraded, 0 newly installed, 2 to remove and 0 not upgraded.
4 not fully installed or removed.
After this operation, 409 MB disk space will be freed.
Do you want to continue? [Y/n] y
(Reading database ... 230177 files and directories currently installed.)
Removing linux-image-6.1.0-35-rt-amd64 (6.1.137-1) ...
/etc/kernel/postrm.d/initramfs-tools:
update-initramfs: Deleting /boot/initrd.img-6.1.0-35-rt-amd64
/etc/kernel/postrm.d/z50-raspi-firmware:
raspi-firmware: missing /boot/firmware, did you forget to mount it?
run-parts: /etc/kernel/postrm.d/z50-raspi-firmware exited with return code 1
dpkg: error processing package linux-image-6.1.0-35-rt-amd64 (--remove):
 installed linux-image-6.1.0-35-rt-amd64 package post-removal script subprocess returned error exit status 1
dpkg: too many errors, stopping
Errors were encountered while processing:
 linux-image-6.1.0-35-rt-amd64
Processing was halted because there were too many errors.
W: Can not find PkgVer for 'raspi-firmware'
E: Sub-process /usr/bin/dpkg returned an error code (1)

skunkworks wrote:

Yes - unchecking autovolts then uses the material voltage. Duh

thanks again
sam

Yes, this is preferred in my book. You want to know the torch height and the voltage quoted in cut charts may not be correct due to worn/eroded electrodes etc so its far better to sample the torch voltage once the voltage has stabilised and keep that constant. There is a very high correlation between torch voltage and torch height so  its an excellent process control variable. This is covered in the Plasma Primer in the docs.

This is a known Debian bug
try
sudo apt purge --autoremove raspi-firmware
sudo apt update

Hi, can someone help me with this error? It's a fresh install on a laptop.

sudo apt upgrade
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
Calculating upgrade... Done
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
4 not fully installed or removed.
Need to get 0 B/69.1 MB of archives.
After this operation, 0 B of additional disk space will be used.
Do you want to continue? [Y/n] y
Setting up initramfs-tools (0.142+deb12u3) ...
update-initramfs: deferring update (trigger activated)
Setting up linux-image-6.1.0-37-rt-amd64 (6.1.140-1) ...
/etc/kernel/postinst.d/dkms:
dkms: running auto installation service for kernel 6.1.0-37-rt-amd64........]
dkms: autoinstall for kernel: 6.1.0-37-rt-amd64.
/etc/kernel/postinst.d/initramfs-tools:
update-initramfs: Generating /boot/initrd.img-6.1.0-37-rt-amd64
raspi-firmware: missing /boot/firmware, did you forget to mount it?
run-parts: /etc/initramfs/post-update.d//z50-raspi-firmware exited with return code 1
run-parts: /etc/kernel/postinst.d/initramfs-tools exited with return code 1
dpkg: error processing package linux-image-6.1.0-37-rt-amd64 (--configure):
 installed linux-image-6.1.0-37-rt-amd64 package post-installation script subprocess returned error exit status 1
dpkg: dependency problems prevent configuration of linux-image-rt-amd64:
 linux-image-rt-amd64 depends on linux-image-6.1.0-37-rt-amd64 (= 6.1.140-1); however:
  Package linux-image-6.1.0-37-rt-amd64 is not configured yet.

dpkg: error processing package linux-image-rt-amd64 (--configure):
 dependency problems - leaving unconfigured
Processing triggers for initramfs-tools (0.142+deb12u3) ...
update-initramfs: Generating /boot/initrd.img-6.1.0-37-rt-amd64
raspi-firmware: missing /boot/firmware, did you forget to mount it?
run-parts: /etc/initramfs/post-update.d//z50-raspi-firmware exited with return code 1
dpkg: error processing package initramfs-tools (--configure):
 installed initramfs-tools package post-installation script subprocess returned error exit status 1
Errors were encountered while processing:
 linux-image-6.1.0-37-rt-amd64
 linux-image-rt-amd64
 initramfs-tools
E: Sub-process /usr/bin/dpkg returned an error code (1) 

Thank you very much Andy.
I will give this a try too, although I first need to understand this, hehe.

After some testing, my proposal does not work reliably.
After a couple of probing commands, the error comes back.

I first thought about a race condition, so I also tried the synced
M62/M63 and isolated everything with G04 dwell commands,
up to 1s, like this one here:

After some debugging, it's clear, that the G38 command itself
triggers this error. Most likely dIrectly after the probe made contact.
The short time between the (sucessful) end of G38 and my custom
"probe off" command seems to be the zone, where this happens.

If this is true, probably not even Andy's solution would work here.

To be clear, yes, there is a _lot_ of bouncing involved here.
I am directly probing with a 0.1mm cutter and the touch probe
is connected to the galvanically isolated material.

But this all was working in the past; I almost used this daily,
with previous versions.

Is there a latching element available in HAL?
A flipflop? That might help here, if it's fast enough.

Otherwise, the last resort would be a HW latch - if the bouncing
is the cause of this. If it's just the static "probe HIGH" signal;
well - no go.

You are welcomed to post as much as you like, always, but it seemed you were hoping someone will answer at this hour, so i thought it would be OK to remind you this is the time when no one is here, except members form both Americas.
You were a bit late as from 11PM to 1AM my time (Central Europe) is when there are most users active here, and also at mid day is usually busy.
Sorry, but i never used extra joints, so i can not help.
In about 2 hours the Asia and Australia will be up, plenty of our members form there, so someone might just be able to help, if that is not to late for you.
I am off to bed, 3:52 AM, watching "how much do we actually know about space" on the "Spark" channel on youtube.

I apologize, it wasn't my intention, I couldn't edit it so I added it below, it wasn't my intention to rush anyone

Gladly, if i can log into google mail again, something is changing with payments AND my country is being de-listed again as i could not log into paypal also about a month ago.

Picture? Drawing? anything that would help explain what you're trying to achieve.
If you are comfortable editing the ini file, try changing HOME_OFFSET and HOME, see if it works for you.

Wait.
It seems you are not aware that most of planet earth is sleeping right now, it is 2:16AM here, it is still night all over the world, except both Americas, so the only option is to wait. OK, might be early morning in Japan...
-
This reply was prompted as a result of both of his posts being made inside of an hour.

If any of the developers could help me, I’d really appreciate it. I’ve searched extensively for information on the use of NUM_EXTRA_JOINTS, but haven’t found any practical examples of someone actually using this feature. However, it is documented in the official LinuxCNC sources. This feature would solve a specific problem I’m currently facing with a machine. Thank you in advance for any assistance.

Incidentally, there are two INI settings related to this, but I don't think that they help here:

linuxcnc.org/docs/stable/html/config/ini...tml#sub:ini:sec:traj

NO_PROBE_JOG_ERROR = 0 - Allow to bypass probe tripped check when you jog manually.

NO_PROBE_HOME_ERROR = 0 - Allow to bypass probe tripped check when homing is in progress.

You could try making a fast probe-away move (G38.5) to clear the probe from the work. (fast so that it overshoots out of the probe dither region)

It is possible to set up the HAL so that the probe signal is only seen during a probe move.

It's not a particularly elegant fix, as you need to use motion.motion-type
linuxcnc.org/docs/stable/html/man/man9/m...9.html#MOTION%20PINS
and only send through the probe signal when motion.motion-type = 5.
Unfortunately I haven't found a single component that can compare a signed integer (like motion-type) and outut a logical.

So it might be better to use a custom HAL component:
linuxcnc.org/docs/stable/html/hal/comp.html

I'm using LinuxCNC 2.9.4 with trivkins and want to use an extra joint that doesn't go through the path planner. I've already configured it in the .ini file.

[KINS] KINEMATICS = trivkins coordinates=XY
Joint = 3

[EMCMOT] num_extrajoints = 1

Even so, it doesn't work correctly. LinuxCNC either won't load or gives a joint mapping error.

❓ Has anyone used num_extrajoints successfully? Is there any additional details beyond that?
The idea is to just have normal X and Y coordinates, and a free joint controllable via HAL, outside of the path planner.