Advanced Search

I don't see anything special in the interrupts. To install the kernel, just download the headers and kernel from: drive.google.com/drive/folders/1L28lG0zD...2XQJx?usp=drive_link

then install with:
sudo apt install ./linux-headers-6.10.0-rc1-rt1_6.10.0-rc1-2_amd64.deb

sudo apt install ./linux-image-6.10.0-rc1-rt1_6.10.0-rc1-2_amd64.deb

Bad ram memory can also be a cause, if you have 2 modules in the pc you could try to remove the second one.
Or you run out of ram memory, I'd recommend at least 4gb
Replace old HDD
Blacklist pc-speaker (for beeps): help.ubuntu.com/community/HowToDisableSystemBell
Replace the GPU or try the internal GPU, in case of using the internal GPU you can add the kernel parameter "i915.enable_dc=0"

First of all I'd like to apologize I thought I could get this running without any issues but I'm at a stand still so I thank you in advance for any advice you can give me.I am converting a benchtop mill to a CNC and I have all the hardware side of things finished on it. Motor mounts and screws are installed, motors are mounted, motors are connected to stepper drivers stepper drivers are connected to 7c81 Mesa BOB (hopefully correctly but I can't test it because I can't get the RT kernel to work). I have installed and compiled the RT kernel maybe 5 times and I think I'm doing one step wrong because it won't actually initialize the kernel.
Components:
-Raspberry Pi 4B 8GB RAM-Debian 12 "bookworm" 64 bit OS
-I have installed the RT kernel from kernel.org linux-6.6.32
-patch from wiki.linuxfoundation.org patch-6.6.32.rt32.patch
As you can see in the pictures when I call uname -a it says that it is running 6.6.31-v8 PREEMPT kernel but when I call make config to choose the RT Kernel it says it is already chosen but if you look at the top of the config menu it states that it is using the arm 6.6.32 Kernel. So my guess is its actually using a different kernel than the one I "made" after altering the menuconfig command. I don't know what is the issue. Any help would be greatly appreciated.  

tommylight wrote:

Run the latency histogram with this
latency-histogram --nobase --sbinsize 1000 --show
Post a screenshot.

What pin do the drives use to let LinuxCNC know they are homed?
Probably connecting the all-homed pin to and3 out (i think such module exists in LinuxCNC) and drive pins to inputs should work.
Or maybe using the lut5 component if there are more than 3 drives...

yeah there are a few things you need to adjust, i dont remember it being as simple as just changing pane.top

dont remember exactly what I did, but you can refer to my 2 other files to play with, i did these specifically for small screens

www.forum.linuxcnc.org/21-axis/38188-sol...screen-w-usercommand

www.forum.linuxcnc.org/21-axis/49372-reg...od-based-on-plasmac2


edit, ok i went back to double check, because i remember it took me a long time to bruteforce the winning combo

i think .pane configures its min height for all the widgets, then hides them after, because just trying to change the height never worked

Yes, that will work (but it's easier to just power it from the FPGA card)

That mean 5v and ground pin of any step/dir to be connected?

Hi,

the full config is on GitHub.
you can check the link above.

Thank you for your support

Yes, your scale uses 34 bits rather than just 26 bits so that string looks closer.
you need 24 bits of (non Gray code) position, 2 pad bits, 1 error and 1 warning bit
and 6 CRC bits

The hostmot2 manual page describes the format string components in the SSI section
 

I have the same drive with ethercat comm card and it works - gets to an OP state. Can you share full config? I can check for differences.

Thanks!

I think their wording 26 bit binary format means its not gray coded.

RLS LA11: 

 


"biss_chan_0=null%1bcrc%6fwarning%1berror%1bencoder%26e" I saw this in a forum post where a person posted he was using similar renishaw glass scale. Where is the information about the format string? man page for hm2 doesn't go into this much details. Also the string I mentioned above doesn't work for me, but the person in the forum said it his scale is working.

Unfortunately, a longer runtime has also shown that the servo thread has poor latency.
 

I have displayed the interrupts, but I cannot interpret the displayed values.
Maybe performance monitoring interrupts and machine check polls?
 

I have no doubts about the kernels, it's more a question of knowing how to update/change them.


I would like to use the parallel port for the first tests. In case I don't like the software after all.

 

I'm looking for a reliable and safe solution to manage homing with absolute encoders. The machine has to be homed once and reminds the home position even after power off and mechanical movents in powered off state. So clearly, I dont have to home on every power cycle. 
My homing is done in the servo drive itself and passes the data to linuxcnc. 

What I looking for is something like that:
- I would like to disable the hole homing process from HAL, and on power on, shows me the machine is already homed, all axis turn green. 

What is the best method to manage absolute homing anyway?

Thanks. 
 

Cristian_g wrote:

“linuxcnc-uspace” will also run on a standard Linux kernel for use as a simulator, but it should not be used to control hardware."

This can be used to control machines when using the RT-Preempt kernel, it can not be used to control machines when using normal "generic" kernel.
RTAI version is more for use with parallel port.