Advanced Search

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

Preemption ModelsThe various preemption models are kernel specific. In principle, user space programs are always preemptible.Preemption of a running task is performed by the scheduler. This action can be triggered by a kernel interaction like a system call or an asynchronous event like an interrupt. The scheduler saves the context of the preempted task and restores the context of the new task.The Linux kernel implements several preemption models. The desired model is selected at build time of the kernel. The “Fully Preemptible Kernel” preemption model must be selected to obtain Linux as an RTOS. For the sake of completeness a list and a short explanation of the existing Linux preemption models is given. The last two entries are available only with the PREEMPT_RT patch.

• No Forced Preemption (server) – the traditional Linux preemption model, geared towards throughput . System call returns and interrupts are the only preemption points.
• Voluntary Kernel Preemption (Desktop) – reduces the latency of the kernel by adding more “explicit preemption points” to the kernel code [. . . ] at the cost of slightly lower throughput . In addition to explicit preemption points, system call returns and interrupt returns are implicit preemption points.
• Preemptible Kernel (Low-Latency Desktop) – reduces the latency of the kernel by making all kernel code (that is not executing in a critical section) preemptible. An implicit preemption point is located after each preemption disable section.
• Preemptible Kernel (Basic RT) – resembles the “Preemptible Kernel (Low-Latency Desktop)” model. Besides the properties mentioned above, threaded interrupt handlers are forced (as when using the kernel command line parameter

  threadirqs

  ). This model is mainly used for testing and debugging of substitution mechanisms implemented by the PREEMPT_RT patch.
• Fully Preemptible Kernel (RT) – all kernel code is preemptible except for a few selected critical sections. Threaded interrupt handlers are forced. Furthermore several substitution mechanisms like sleeping spinlocks and rt_mutex are implemented to reduce preemption disabled sections. Additionally, large preemption disabled sections are substituted by separate locking constructs. This preemption model has to be selected in order to obtain real-time behavior.

JT wrote:

Messing around with QLinearGradients and thinking of adding them to the Stylesheet Builder.

Is it worth it?

JT