Advanced Search

 So is there a bug in the PREEMPT_RT support in the 6.12 kernel, or is it simply not implemented the way LinuxCNC has come to expect? Obviously LinuxCNC needs to support a working standard.

camb0 wrote:

I assume you posted some info on your 4th axis build so I'll do some reading up on the homing.
 

• Solution - use the drive's internal home-to-encoder-index function (Copley XSL)
• I wound up using some relays and HAL logic so that when I pushed the "Home-A" button
  • LCNC sets home (i.e. G53 A0) without commanding the drive to do anything
  • joint.3.homing sends an output to trigger the A-drive to home itself
  • When the drive finishes homing, it sets an output that's connected to joint.3.home-sw-in

royka wrote:

Like you assumed before I think those patches indeed didn't make it to the mainline kernel, but those are not needed to make a fully preemptible kernel.

The sysfs patch is only needed because LinuxCNC checks that indicator. Later I saw that the source of Raspberry also already has the arch_supports_rt in the kconfig.
 

config ARCH_SUPPORTS_RT
-    bool
+    def_bool y

fully_defined wrote:

• First...a little background and perhaps some context.
  • As @rodw pointed out, PNCconf is not able to cover every hardware configuration available.  I know Clearpaths are pretty common now, but they weren't when PNCconf was created.  And there aren't a ton of folks using Clearpaths with LCNC now - at least not those who have reported/described/posted plenty of helpful configs to copy.
  • This means the HLFB signal is not 'typical' - especially since Teknic has made a boatload of different options available through that single output.
  • What you're gonna have to do is some manual editing of the HAL file once you get a basic configuration working (i.e. motors move like you want, more or less).
  • Note that the HAL file (or files, you can have more than one) is simply a text file with a bunch of what looks like gibberish... but represents a configuration of what logical functions inside LCNC are connected to various hardware.
  • Once you get a really basic config you (we) will then edit the HAL file to include the HLFB function.
• Can you get through PNCconf far enough to get the motors turning?
• Have you decided what function you want the HLFB signal to accomplish?
  • Simple motor fault?
  • Something exotic, like PWM output of motor load?
• Gantry homing/squaring
  • Clearpaths have home-to-hardstop and other features, but to keep everything simple you will disregard all the Teknic features and treat them like 'dumb' motors - albeit with encoders and fault outputs.
  • Clearpaths will be programmed to 'home in place' (I think that's the term/concept) - so they will never be internally homed.
  • At drive enable, they will just sit there until you tell LCNC to start the homing sequence.
    • LCNC will command both motors to move towards the limit switch(s), and LCNC will manage moving to the switch, then backing off until the switch just clears, then moving back until the switch just triggers.
  • The exact homing process is adjustable in LCNC, but be advised it can be annoying to wrap you head around the homing terminology.  This may be painful for you - it is for me, even now.
  • Two limit switches are require; one on each Y-axis side.

royka wrote:

For Raspberry I think following this guide should help: github.com/by/RT-Kernel

Only after git clone, download this patch:
forum.linuxcnc.org/media/kunena/attachme...ernel-realtime.patch
Then enter the Linux folder and enter: git apply ../sys-kernel-realtime.patch
After make menuconfig make sure that these are also selected:
forum.linuxcnc.org/38-general-linuxcnc-q...6-12?start=10#315643