Advanced Search

Maybe some kind of burnt offering or sacrifice as well. This is purely meant in jest.

Tho I think my "life choices ability" requires an exorcist or something.

The Rpi5 will work fine with the posted image on the download page. Will be fine for mesa ethernet.
For SPI you'll have to compile Linuxcnc from the most recent sources, master or 2.9.3, as they include the spi driver thats supports the RPi5. If using ethernet nothing needs to be done.

This may be worth a read
github.com/by/RT-Kernel

Along with this post
forum.linuxcnc.org/38-general-linuxcnc-q...6-12?start=40#318767

I'm actually getting fed up with my RPi5, for the second time for Linuxcnc, it's a Me Issue which I fully admit to. Hopefully I'll be able to gently with great care put it back into the container rather than forcibly inserting into the wall, which will make other people mad at me.

@alangibson @cornholio, thanks for the clarifications.

I've been trying to simply update the kernel to 6.12, install LinuxCNC in uspace and go. I've been playing with this for a week. I took the blogs that said the kernel now supports PREEMPT_RT a bit too literally. (First version of this sentence was considerably less kind to the bloggers)

The post about the differences between the different kernels is very enlightening. I've been using Linux for years at work & home. I had thought there was "The One Linux Kernel" at the heart of Debian, Fedora, Ubuntu, Mint, etc. Based on this conversation I guess that's not the case.

thank you tommy,

yes, I plan to use parallel port. Just for my understanding, why would then be Wheezy the better option?

Indeed I spend countless hours on debian sites and where doing a lot of try and error. but not yet any of the hints I found where successful.

What I can say abot the HW is:

Hmmmm might be just easier to use an amd64 platform and EPP interface. Or just sell up and try something else.

1) What shows the progressbar bar?
Progress of loading file? (AXIS has this functionality)
If the file is loaded, the progressbar should be hidden after file loading.

Progress of realization program?

It should be described as
"Program proccess - 13%"
or
"Loading file - 13%"

If you think this progressbar might bother someone, make its display optional in the setup using the "Show progressbar" checkbox.

Personally, I don't mind this progressbar.


2) Picture of GUI looks good, BUT what is source of data?
Are the data computed automaticaly?
If yes, this is fantastic stuff.

Must it be calculated by CAM system?
If yes, so only a few users will customize the postprocessor in CAM so that this table gives the correct numbers. In this case I would make the table optional in setup and disabled by default.


I dont know, what do you mean by this:
?

3,4) Every buttons has comments for help. I'm a conservative person. I like Norbert's pictures. Feel free to change them to a different style.

5) The weak point of the chooser page is that it lacks a tree:
 

Like I said I was using rodw's rpi-image builder, so that what I was doing different. And using a 6.12.8 kernel. So that's our differences. Apparently the commit for the 6.12.8 didn't include patches for the full preempt kernel (god I could be wrong here as well).

We used this around Nov-Dec 2023 to generate images with a patched 6.1.54 kernel from the 6.1.y branch. As most things people want the latest & greatest. Whether it makes a lot of difference when using Mesa hardware (or a 7c81 self built clone) I can't really say.

[just thinking aloud]
But I think for the prebuilt images having spi turned on as default, the latest code base with the hm2_spix driver and mesaflash 3.5.10 would really make the image more user friendly on the RPi5.

It might make more sense either to stay wit the 6.6.y branch (that's stable I believe) or just jumping straight to the 6.13.y branch.
[/just thinking aloud]

Seems good, git wanted the https: bit but meh.

Much appreciated and I've got a better understanding......wonder why using 6.12.8 kernel sources and rod's image builder produces such different results.

Damn this has been confusing. Thanks for sticking in there and not calling me a knob head.

Post your INI file, better whole configuration.

Is your macros in INI file defined by manual?
linuxcnc.org/docs/stable/html/gui/gmoccapy.html#gmoccapy:macros

I did some improvements of the UI of gmoccapy and would like to hear your opinions to make sure that I am not the only one to perceive this as improvement.

1. Progressbar for progress of the actual running program. Useful or waste of space? Add more information like estimated time or current time? Or better let that in the tab (2.)?


2. Add tab for G-code properties. Useful? Which information would you like to see from these?



3. Change icon for "back to main page" (1). The currently used one is known as undo button, so does not fit well here. I also created some other icons (see in the file area), but I think the chosen one fits best.
4. Change the button order in file chooser page (2). I think the directory-navigate buttons should be grouped together. Otherwise it is a bit confusing with that many different arrows.

These are the exact commands I do:
git clone github.com/raspberrypi/linux.git -b rpi-6.12.y
cd linux
KERNEL=kernel_2712 make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- bcm2712_defconfig
KERNEL=kernel_2712 make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- menuconfig

After that you choose fully preemptible.
Now I wonder what you do different I guess you didn't use the defconfig, then you should set EXPERT=y like I mentioned before: General Setup => Configure standard kernel features (expert users) and press Y, and Fully Preemptible is visible. But I advise to apply the changes to the defconfig at github.com/by/RT-Kernel except the rtc and ntp options, and use the defconfig.

To enable the realtime indicator I used the patch that I posted on page 2.
wget forum.linuxcnc.org/media/kunena/attachme...ernel-realtime.patch
cd linux
git apply ../sys-kernel-realtime.patch

And to prevent compile errors (after the above patch) go at menuconfig to: General Setup =>  Kexec and crash features => press Y so CRASH_DUMP gets selected so VMCORE_INFO gets selected.

PCW wrote:

It may be that firmware that better matches your application can be made
(MPGs are better with MPG encoders rather than motion encoders because
MPG encoders support 1X mode which works better with MPGs having detents)

 

Interesting, I have some MPG style encoders on order, I suppose I can look into this when they arrive.

After looking at the TVS's I put on my little daughter board I came to the conclusion that they were not going to help (not Schottky and Vmin specified as -0.3V) so I replaced with actual digital isolators. Presently the first two P1 encoders are routed to my scale encoders and the next two for MPG's.  So before I hit the send key can I assume that if a version with MPG friendly logic is available it will map the MPG encoders to P1 pins 7-13 or would they move to pins beyond the as is 4 encoders (P1:1-15), it would be easy for me to move my MPG inputs down to say IO:46-49 so they don't interfere with the original 4 encoder inputs if that make sense?
 

 

>Whether it is your present depends on a lot of factors. Usually money

OK. In my case, Pulse/Dir has been working reasonably well for my needs so far, and most importantly I was able to get it working with very limited (aka known) knowledge to start with.

However, since I chose the most simple/cheapest way using parport and basic Bob, I have no room to implement things that would be really useful, such as 4th axis, tool gauge, feedback to LinuxCNC, etc... Any solution that would remove these limitations would require money, so I might as well go for some sort of industry standard, or at least a solution that is not strictly dependent on a single vendor.

This discussion conforts me in the idea that EtherCAT seems a logical choice in this respect, so thank you all for sharing your knowledge and experience

rodw wrote:

Sorry, I have not had a chance to look at this over the weekend.
 

Yeah I figured that cos building an image with the 6.12.y branch fails when creating the final image. 6.1.y with the 6.1.69 kernel commit seems to build ok, image is created with Linuxcnc binaries and when patch has spi on at first boot. This was just seen by mounting the image and having a quick browse through the filesystem. Too effing late to test.

Another thing of interest there are still patches.
Directory listing of the patches that are for 6.12.8 none for 6.12.9 as you can see (6.12.8) has patches for sysfs entry and one to for enable arm rt.

So this looks like a very confusing kettle of fish.

-rw-rw-r-- 1 rmurphy rmurphy 1495 Jan 9 22:27 0001-arm-Disable-jump-label-on-PREEMPT_RT.patch
-rw-rw-r-- 1 rmurphy rmurphy 2447 Jan 9 22:27 0001-ARM-vfp-Provide-vfp_state_hold-for-VFP-locking.patch
-rw-rw-r-- 1 rmurphy rmurphy 3888 Jan 9 22:27 0001-drm-i915-Use-preempt_disable-enable_rt-where-recomme.patch
-rw-rw-r-- 1 rmurphy rmurphy 1382 Jan 9 22:27 0001-hrtimer-Use-__raise_softirq_irqoff-to-raise-the-soft.patch
-rw-rw-r-- 1 rmurphy rmurphy 3902 Jan 9 22:27 0001-powerpc-Add-preempt-lazy-support.patch
-rw-rw-r-- 1 rmurphy rmurphy 6700 Jan 9 22:27 0001-sched-Add-TIF_NEED_RESCHED_LAZY-infrastructure.patch
-rw-rw-r-- 1 rmurphy rmurphy 1384 Jan 9 22:27 0002-ARM-vfp-Use-vfp_state_hold-in-vfp_sync_hwstate.patch
-rw-rw-r-- 1 rmurphy rmurphy 3671 Jan 9 22:27 0002-drm-i915-Don-t-disable-interrupts-on-PREEMPT_RT-duri.patch
-rw-rw-r-- 1 rmurphy rmurphy 1511 Jan 9 22:27 0002-locking-rt-Remove-one-__cond_lock-in-RT-s-spin_trylo.patch
-rw-rw-r-- 1 rmurphy rmurphy 1286 Jan 9 22:27 0002-powerpc-Large-user-copy-aware-of-full-rt-lazy-preemp.patch
-rw-rw-r-- 1 rmurphy rmurphy 11004 Jan 9 22:27 0002-sched-Add-Lazy-preemption-model.patch
-rw-rw-r-- 1 rmurphy rmurphy 970 Jan 9 22:27 0002-timers-Use-__raise_softirq_irqoff-to-raise-the-softi.patch
-rw-rw-r-- 1 rmurphy rmurphy 3282 Jan 9 22:27 0002-tracing-Record-task-flag-NEED_RESCHED_LAZY.patch
-rw-rw-r-- 1 rmurphy rmurphy 1404 Jan 9 22:27 0003-ARM-vfp-Use-vfp_state_hold-in-vfp_support_entry.patch
-rw-rw-r-- 1 rmurphy rmurphy 1741 Jan 9 22:27 0003-drm-i915-Don-t-check-for-atomic-context-on-PREEMPT_R.patch
-rw-rw-r-- 1 rmurphy rmurphy 2853 Jan 9 22:27 0003-locking-rt-Add-sparse-annotation-for-RCU.patch
-rw-rw-r-- 1 rmurphy rmurphy 2660 Jan 9 22:27 0003-riscv-add-PREEMPT_LAZY-support.patch
-rw-rw-r-- 1 rmurphy rmurphy 3721 Jan 9 22:27 0003-sched-Enable-PREEMPT_DYNAMIC-for-PREEMPT_RT.patch
-rw-rw-r-- 1 rmurphy rmurphy 7638 Jan 9 22:27 0003-softirq-Use-a-dedicated-thread-for-timer-wakeups-on-.patch
-rw-rw-r-- 1 rmurphy rmurphy 3696 Jan 9 22:27 0004-ARM-vfp-Move-sending-signals-outside-of-vfp_state_ho.patch
-rw-rw-r-- 1 rmurphy rmurphy 2170 Jan 9 22:27 0004-drm-i915-Disable-tracing-points-on-PREEMPT_RT.patch
-rw-rw-r-- 1 rmurphy rmurphy 1319 Jan 9 22:27 0004-locking-rt-Annotate-unlock-followed-by-lock-for-spar.patch
-rw-rw-r-- 1 rmurphy rmurphy 2089 Jan 9 22:27 0004-sched-x86-Enable-Lazy-preemption.patch
-rw-rw-r-- 1 rmurphy rmurphy 3199 Jan 9 22:27 0005-drm-i915-gt-Use-spin_lock_irq-instead-of-local_irq_d.patch
-rw-rw-r-- 1 rmurphy rmurphy 8921 Jan 9 22:27 0005-sched-Add-laziest-preempt-model.patch
-rw-rw-r-- 1 rmurphy rmurphy 1305 Jan 9 22:27 0006-drm-i915-Drop-the-irqs_disabled-check.patch
-rw-rw-r-- 1 rmurphy rmurphy 1151 Jan 9 22:27 0007-drm-i915-guc-Consider-also-RCU-depth-in-busy-loop.patch
-rw-rw-r-- 1 rmurphy rmurphy 762 Jan 9 22:27 0008-Revert-drm-i915-Depend-on-PREEMPT_RT.patch
-rw-rw-r-- 1 rmurphy rmurphy 10272 Jan 9 22:27 0053-serial-8250-Switch-to-nbcon-console.patch
-rw-rw-r-- 1 rmurphy rmurphy 942 Jan 9 22:27 0054-serial-8250-Revert-drop-lockdep-annotation-from-seri.patch
-rw-rw-r-- 1 rmurphy rmurphy 379 Jan 9 22:27 Add_localversion_for_-RT_release.patch
-rw-rw-r-- 1 rmurphy rmurphy 1013 Jan 9 22:27 ARM__Allow_to_enable_RT.patch
-rw-rw-r-- 1 rmurphy rmurphy 1370 Jan 9 22:27 arm-Disable-FAST_GUP-on-PREEMPT_RT-if-HIGHPTE-is-als.patch
-rw-rw-r-- 1 rmurphy rmurphy 3310 Jan 9 22:27 ARM__enable_irq_in_translation_section_permission_fault_handlers.patch
-rw-rw-r-- 1 rmurphy rmurphy 7625 Jan 9 22:27 netfilter-nft_counter-Use-u64_stats_t-for-statistic.patch
-rw-rw-r-- 1 rmurphy rmurphy 1061 Jan 9 22:27 POWERPC__Allow_to_enable_RT.patch
-rw-rw-r-- 1 rmurphy rmurphy 1837 Jan 9 22:27 powerpc_kvm__Disable_in-kernel_MPIC_emulation_for_PREEMPT_RT.patch
-rw-rw-r-- 1 rmurphy rmurphy 3446 Jan 9 22:27 powerpc_pseries_iommu__Use_a_locallock_instead_local_irq_save.patch
-rw-rw-r-- 1 rmurphy rmurphy 903 Jan 9 22:27 powerpc-pseries-Select-the-generic-memory-allocator.patch
-rw-rw-r-- 1 rmurphy rmurphy 1120 Jan 9 22:27 powerpc_stackprotector__work_around_stack-guard_init_from_atomic.patch
-rw-rw-r-- 1 rmurphy rmurphy 1249 Jan 9 22:27 powerpc__traps__Use_PREEMPT_RT.patch
-rw-rw-r-- 1 rmurphy rmurphy 1762 Jan 9 22:27 riscv-add-PREEMPT_AUTO-support.patch
-rw-rw-r-- 1 rmurphy rmurphy 930 Jan 9 22:27 sched-Fixup-the-IS_ENABLED-check-for-PREEMPT_LAZY.patch
-rw-rw-r-- 1 rmurphy rmurphy 4049 Jan 9 22:27 series
-rw-rw-r-- 1 rmurphy rmurphy 1401 Jan 9 22:27 sysfs__Add__sys_kernel_realtime_entry.patch
-rw-rw-r-- 1 rmurphy rmurphy 2965 Jan 9 22:27 tracing-Remove-TRACE_FLAG_IRQS_NOSUPPORT.patch

I don't what your doing different but using the rpi-linux source from their github repo, I cloned the whole repo, I'm getting this, unpatched sources.
Just out of interest are you working from the same kernel source as myself.