Advanced Search

And for 6.12 the patches from kernel.org are still required, other wise you can only select a low-latency desktop, not a fully_preemptible model, which would appear to be "a proper realtime kernel" suitable for a RTOS.

I've work through the image builder for 6.12.y, and I can say from configuring the kernel, that the patches from kernel.org are required. Depending on the commit you chose in the 6.12.y branch there may not be a matching patchset.

So it's not just a case of choosing the 6.12.y branch but also the commit that matches a patchset that is available.

Image below shows a kernel from the 6.12.y branch, commit 236f36133619216a5c8faea1a8c2c93c83efc2f4, which is kernel 6.12.8. This is has been patched with those from kernel.org and a patch, required for the build process to succeed, from Rods repo. As you can see there is an option to select the full preemptible kernel. Without the patch this does not appear. Yes while the sysfs patch does add the ability to report to Linuxcnc the kernel is "realtime" the kernel is only a low-latency-desktop.
As I type I'm running an image build on another machine.
 
 

blazini36 wrote:

A gradient would be good for something like a progressbar unless there's some other way to express zones.

Was messing with the qss builder a bit.....it definately needs an "open" function.

Also doesn't seem to be any way to apply the background colors. I assumed this would be part of "All" but it doesn't seem to work like that.

 

Gradients can be used to style buttons etc.

What would the open function do?

Can you elaborate on apply the background colors?

JT

No not all the realtime code is there (it is a very confusing situation, mainly thanks to tech bloggers, and other sundry types that aren't trying to build a fully preemptive arm kernel), there are still patches up on kernel.org. Without the patches at kernel.org there is no way to select a fully_preemptible kernel (and another one if working on the 6.1.69 kernel). The highest level you can chose is a low-latency desktop, but this is not the model really required for realtime. In another thread I post the differences between the different kernels, forum.linuxcnc.org/38-general-linuxcnc-q...6-12?start=30#318731

This has been a bit of a headache all weekend, I've built a successful image using the 6.1.y branch (unfortunatley first attempt didn't include the Linuxcnc binaries), the commit chosen is 6.1.69, the latest commit on that branch doesn't have a corresponding patch set is available.

I tried with the 6.12.y branch, but there was an issue with the build of the final image.

Finally working with the 6.1.y branch and the 6.1.69 commit it appears that I have a successful image, with the Linuxcnc binaries and spi turned on as default.

I think one reason for "rolling our own image" is to get away from any RPi Foundation branding. Another reason is that we can insert our own modifications in as well.

Note that some drives (even high quality ones like mitsubishi and yaskawa) have a noticeable lag in the simulated incremental encoder signal when using position loop.
forum.linuxcnc.org/10-advanced-configura...pain?start=30#193073

Absolute encoders should be very accurate but you may struggle to get the encoder data into Linuxcnc (ie to get the multiturn AND motor position ). If it does not offer the multiturn information then you would need a second signal from the rotary to indicate the correct rough orientation for the motor position to be valid. This would be very accurate if you can get a good index signal from the drive.

As an alternative you could also mount a separate incremental encoder directly on the rotary axis and use the encoder index signal for homing.

Yes but we were talking about 6.12 and up, of course for 6.1.x you still need patches.