Advanced Search

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.

Okay; found a workaround.
Just in case someone is having the same issue:

I solved this with an additional AND gate and this
motion-digital-out-nn thingy, controlled via M64 and M65.

Example for a probe on a parport, here also with an additional
debug LED on parport pin 1 (strobe):


In the G-Code, just encapsulate the retraction move(s) with
M65 P0 and M64 P0:

Cheers
AS

I would like to find out how to tell LinuxCNC in absolute terms that your position is x,y,z.
Not relative. I want to set the actual position of x,y.z.
I do not have limit switches to home.
I manually home to a custom jig at the center of the machine.
After I do this, I need to tell LinuxCNC "you are here".
Everything I've tried creates a corresponding negative relative offset.
Please help, and thanks in advance.
--LoneWolf.Quest

Nope, Variable Reluctance resolvers require quite a bit more excitation drive, and not all resolver circuits can handle these. Tamagawa is a leading manufacturer of these, but they also make "brushless resolvers" which require MUCH less drive. In the data sheets, they sometimes state the excitation impedance as a complex number, something like 95 + 135j Ohms at some frequency. The higher these numbers, the less drive current the resolver requires. Common brands of brushless resolvers seen on older equipment are Singer-Kearfott and Harowe Controls.
Sin/Cos encoders are not magnetic devices, but often optical linear scales (can also be rotary) where the raw optical signal is brought out, either as a voltage or a current. The reason for this is interpolator boxes can be attached to increase the encoder resolution. Back in the "old days" linear scales often had native resolution of 100 lines per inch or so, so interpolation was required to get proper machine accuracy. Nowadays, high-resolution optical gratings can be made easily, so this stuff is rarely seen today.
Jon