Advanced Search

Yes the kernel needs to be specifically built to support preempt_rt even in kernel 6.12
It seems that on the Pi a default 6.12 RT kernel build is not recognised by linuxcnc unless the kernel has additional settings that are provided in the patch. This may end up being fixed by the kernel developers in later versions

This may not be relevant to you but building a custom image that includes Linuxcnc is not trivial and requires building a kernel from source so it needs to be a RT kernel.


 

I'm trying to do this with an Rpi 4 and I'm seeing the same thing. I can find the PID of latency-histogr. Then run chrt -p PID which reports that current scheduling policy as SCHED_OTHER. Then run chrt -f -p PID which does change the scheduling policy to SCHED_FIFO.

But all I did (hoped was necessary) was to update the kernel. sudo rpi-update next, thne reboot. Must one actually build the kernel with a patch? That seems odd if the kernel offers full RT support.

Oh, it's part of the Kernel files isn't it. Ugh.

Roy,

I've updated the kernel to 6.12.8 on an Rpi 4, and I'm seeing pretty much the same behavior. However, I'm not finding the file you patched anywhere on the system? sudo find / -print | grep ksysfs finds nothing.

Thanks,

Gene

What I am trying to do: in a 1" x 1" square workpiece, cut a .68" ID hole starting at (.16",.16").  The mill is .125" nminal diameter.  It is actually .122".

The gCode I tried, producing a hole that is too small:

g1 x.16 y.16 f25
g1 z0 f25
g2 i.-34

Update

Motherboard won’t even post to bios.

Cf card was empty.

I just ordered a 7i96s

If I have to build a new system I’m gonna get a better computer.

Lcvette,

Thanks for the help.

I'm unsure why the file names on the forms now have the 2025-01-09 attached. It must have been added when I uploaded them. They match what I have in the ini file except for the postgui file name error. I thought I had changed that one. I have made the suggested changes and still can't launch Probe Basic. getting the error "Can't execute DISPLAY program probe_basic  "





 

Anything above Core2Duo should do, 8GB of RAM (works OK with 4GB) and 32GB of disk space (HDD or SSD or NVME).
See here for some more info:
forum.linuxcnc.org/18-computer/38838-har...ency-tests-used-pc-s
And see here for some laptops that work, just do not bet on it as you might find the same model that does not work, i know i did
forum.linuxcnc.org/18-computer/54369-use...ernet-boards?start=0

Is there any requirement for building a Linuxcnc computer.

hd size
ram size

thanks john
 

I/O 34 and 38 are  still available  as GPIO
(1 differential input and one differential output on the 7I74)
There might be room for some simple feature on those pins
(say PWM for output  or encoder 'A' pin for input)

Hi,

I tried the other channels on the 7i74 today,
all of them work as they should.
Thanks again.
I noticed afterwards that in the thermal output I attached, IO 34 and 38 have no function, I assume that in different situations these would be RXData0 and TXData0.
So I should have noticed the fact that channel 0 is not available on the 7i74 in my case.
 

I don't think there is much advantage to returning the rotary encoder
data to LinuxCNC.  I think for the uses of the linear encoder position mode
is OK, basically the linear encoder would be of most use compensating for
ball screw errors and thermal expansion which can be handled by LinuxCNCs
relatively low bandwidth control.

The RS-485 adapter should work, wiring would be:

PktURDataPin  <= RO   
PktUTDataPin   => DI
PktUTNDrvEnPin => DE
GND => RE

Note the N in PktUTNDrvEnPin

(the firmware must be built with this pin in the pinout file to have the
proper drive enable polarity)

Did you look at the relayboard.mod example?
Its probably closer, not for addresses but for bit I/O:
(look an the input definition)


/* Modbus definition file for a 4-channel relay board found on eBay */

/*
The format of the channel descriptors is:

{TYPE, FUNC, ADDR, COUNT, pin_name}

TYPE is one of HAL_BIT, HAL_FLOAT, HAL_S32, HAL_U32
FUNC = 1, 2, 3, 4, 5, 6, 15, 16 - Modbus commands
COUNT = number of coils/registers to read
*/

#define MAX_MSG_LEN 16   // may be increased if necessary to max 251

static const hm2_modbus_chan_descriptor_t channels[] = {
/*  {TYPE,    FUNC, ADDR,   COUNT, pin_name} */
    {HAL_BIT, 1,  0x0000, 8,     "state"},
    {HAL_BIT, 2,  0x0000, 8,     "input"},
    {HAL_BIT, 5,  0x0000, 1,     "relay-0"},
    {HAL_BIT, 5,  0x0001, 1,     "relay-1"},
    {HAL_BIT, 5,  0x0002, 1,     "relay-2"},
    {HAL_BIT, 5,  0x0003, 1,     "relay-3"},
};


/* Optionally #define DEBUG to aid with troubleshooting.
   Use 3 to see a lot of information about the modbus
   internal workings. 1 is default (errors only)                    */

 

Hi.
I would like to come back to you about the best way to have a closed loop with a linear scale and a servodrive-motor combination (which has a closed loop already)

Please take a look at attached picture.
The motor has an encoder which is connected to the drive.
The Mesa-board sees the exact position of the table, and should keep giving commands to the drive, untill position is reached. (I expect)

The loop between motor-encoder and drive is the fastest, and not influenced by any speed of the Mesa.

What is your opinion of the considerations I have:
1. Is it smart to use the drive-outputs of the encoder to the Mesa-board? (And for what purpose)
2. Should I controll the drive in POSITION-mode or SPEED-mode?
 
Thanks, and with kind regards.

That's even better!