Advanced Search

tommylight wrote:

forum.linuxcnc.org/10-advanced-configura...ning-detailed-how-to
 

This reminds me I need to mount the XY limit switches. Some tech at the company that donated the mills physically removed them. Kind of understandable since you could not jog the machine off the limits as they outright interrupt the drive enable circuit. 

modname.update-hz is 0 by default i have not changed so this not the reason for error

It's also important to have the drive enables working so a following
error will disable the drives.

I have two relay outputs I need to get wired up. The default wiring does not give direct control of the drive enable relay which in turn energizes the main contactor. There is a reset relay that latches the enable relay and an error/e-stop relay that interrupts the enable relay.

I will pull the belts off all three servos. Need to figure out the ratio in any case.

All my Pi's are 4GB.

Along with my Rpi5 I also have a RPi400, basically the same as a RPi4 with an slightly upped clock speed. I can say I've never come across this issue (even when rod was polishing his iamge utility).
I don't know if this will actually help, but you could try comparing the config.txt files on the Linuxcnc image & the Rasp OS image and see if there is anything that sticks out. This is just a guess.

It might pay to monitor the 3v3 line when booting, both versions, and see if there is anything untoward. Again just another guess.

But yeah it does seem like a confusing issue.

First of all your opening post was great. I'm actaully giving it a go now, just wish I had a nvme drive hooked up to the PCIe bus.
There's a couple of points regarding Linux kernels.

Sometimes the latest kernel may not be the optimum for your hardware.
The kernel you are using is a "release candidate" whilst usable for all intents is still going through some work.
The 6.1.y branch works fine on the RPi4, I think the kernel in the Linuxcnc image maybe 6.1.54
The RPi platforms with regards to Linuxcnc are a little different to the x86 platforms. Your Rpi4 & Rpi5 hardware is what it is. Whereas you may need a specific kernel dpending which x86 motherboard you buy.
The Rpi branch that appears to be active is the 6.6.y branch, so one could assume this is the branch that is receiving the most "bug fixies".
Simple things like isolating cores 2,3 will see latency drop. There doesn't seem to be as many options/tricks for latency on the RPi platforms as the x86 platforms.
I would chose to use a kernel that is a couple of version behind the the latest and greatest if it more tried in the real world and has better latency.
In my discussions with royka we talked about the fact that a kernel that is a little older is sometimes the better option.
Due to the issues with wayland I would recommend the use of the image form the Download page, Xorg is used. Plus it's easier to deploy

Mind tho I'm not saying this is the only way to do it.
What I would suggest is trying some of the earlier kernels to see how performance differs.

One thing regarding the 6.6.y branch.
The latest version is 6.6.70 which I couldn't find any real time patches for.
The previous commit is 6.6.65 for which there are rt patches, but for some reason the overlay's aren't in the source. Which is a pain when building an image using Rod's image builder.

It seems, ATM, the deeper you dive it can seem a little confusing.

Sorry for the multiple posts but this editor is PITA.

forum.linuxcnc.org/10-advanced-configura...ning-detailed-how-to

In a Debian environment tasksel allows you to install a number of desktops. There is a (X) reason why we use XFCE in the linuxcnc images. It uses X windows not wayland

Thank you very much for your help.
I have set the parameter of HOME_USE_INDEX = NO to "No” before, but if I am not careful or accidental, clicking on [home axis] will still set my G53 coordinate to 0. This will lead to the possibility of subsequent collisions.

I hope CNC will do nothing when I accidentally click on [home axis]

I can guarantee it's not bricked. I loaded the raspberry Pi OS onto it after that with no problem and was able to access it via SSH to download data from the Pi library. I tried 2.93 as well and got a similar result only this time there were some penguins at the top of the screen instead of skulls  

Just updated the bootloader and tried again. Got a similar result but now the ACT LED is flashing consistently instead of barely visible. 

I'm surprised nobody else is experiencing this. Am I the only 8G user to try these? Do I need to have some additional board attached for it to boot properly?

[Edit, after hearing it might be bricked, I tried the same card on a 4gig Pi4B that I've been using perfectly fine for years with the same result] 

It's often best to de-couple the linear axis when doing initial tests
so no harm is done with a runaway. (there's about a 50% chance of getting
the feedback reversed = runaway at first startup.

It's also important to have the drive enables working so a following
error will disable the drives.