Advanced Search

Vendor kernel is real time preempt-rt ?
Because am interested for base thread because i need raster engraving
what jitter has base thread with vendor kernel ?

I just tested this at the beginning of rt_peripheral_init and it compiles and works on my RPi5 and RPi400 if you include the attached dtcboards.h:

int rt_peripheral_init(void)
{
    FILE *fp;
    int i, j;
    char buf[256];
    ssize_t buflen;
    char *cptr;
    const int DTC_MAX = 8;
    const char *dtcs[DTC_MAX + 1];
    
    // assume were only running on >RPi3
    
    if ((fp = fopen("/proc/device-tree/compatible" , "rb"))){

        // Read the 'compatible' string-list from the device-tree
        buflen = fread(buf, 1, sizeof(buf), fp);
        if(buflen < 0) {
            rtapi_print_msg(RTAPI_MSG_ERR,"Failed to read platform identity.\n");
            return -1;
        }

        // Decompose the device-tree buffer into a string-list with the pointers to
        // each string in dtcs. Don't go beyond the buffer's size.
        memset(dtcs, 0, sizeof(dtcs));
        for(i = 0, cptr = buf; i < DTC_MAX && cptr; i++) {
            dtcs = cptr;
            j = strlen(cptr);
            if((cptr - buf) + j + 1 < buflen)
                cptr += j + 1;
            else
                cptr = NULL;
        }

        for(i = 0; dtcs != NULL; i++) {
            if(        !strcmp(dtcs, DTC_RPI_MODEL_4B)
                ||    !strcmp(dtcs, DTC_RPI_MODEL_4CM)
                ||    !strcmp(dtcs, DTC_RPI_MODEL_400)
                ||    !strcmp(dtcs, DTC_RPI_MODEL_3BP)
                ||    !strcmp(dtcs, DTC_RPI_MODEL_3AP)
                ||    !strcmp(dtcs, DTC_RPI_MODEL_3B)) {
                rtapi_print_msg(RTAPI_MSG_ERR, "Raspberry Pi 3 or 4, using BCM2835 driver\n");
                bcm = true;
                break;    // Found our supported board
            }else if(!strcmp(dtcs, DTC_RPI_MODEL_5B) || !strcmp(dtcs, DTC_RPI_MODEL_5CM)) {
                rtapi_print_msg(RTAPI_MSG_ERR, "Raspberry Pi 5, using rp1 driver\n");
                rp1 = true;
                break;    // Found our supported board
            }else{
                rtapi_print_msg(RTAPI_MSG_ERR, "Error, RPi not detected\n");
                return -1;
            }
        }
        fclose(fp);
    }else{
        rtapi_print_msg(RTAPI_MSG_ERR,"Cannot open '/proc/device-tree/compatible' for read.\n");
    }    
    
    if (bcm == true){
...

Possibly a language/locale issue (this has been noticed before on pncconf)

2.9.4 pncconf gives me this after selecting 5i25+7I77x2 with one 7I77
and accept component changes:

 

It helps if I spell HOME_SEARCH_VEL correctly.
So, pressing home, the axis travels to the minus limit, where is stops with an error.

I think the relevant hal lines are.:-

net x-home-sw <= hm2_7i92.0.encoder.03.input-a
(I have 5volt limit switches, so I have then connected to unused encoder pins)
net x-index-enable joint.0.index-enable <=> hm2_7i92.0.encoder.00.index-enable
net x-home-sw => joint.0.home-sw-in
net x-home-sw => joint.0.neg-lim-sw-in
net x-home-sw => joint.0.pos-lim-sw-in
Quite confused about why its hitting the limit switch as an end of travel, but not using that as the home trip, and returning to the encoder index.
Appreciate any thoughts.
Thanks

I found the reason for this. He's using my tool probe routine and I forged two lines in it.

Der Fehler liegt an der Werkzeugvermessungsroutine, habe da noch was gefunden. Habe auf GitHub eine neue Version (5.0.1) erstellt. Danach sollte das Problem behoben sein.

@Arciera,

Thanks for all the work!
Pff. If you don't know what you are doing. It's kind off keeping the patience for a long long time.

updated source
I removed the dogleg dependencies for now. it's not used at this moment. Later on will activate it again.

To know more about eq44 and how it works, i started at your item 7, and used not the dogleg, but a initial guess value.
Then to item 8.

It seems now to plot a clothoid 4 compound in 3d.
I used eq.14 as a startpoint to get succes.

Using xy angle 45 degrees at start.
Using z angle 45 degrees at end.


Basicly i understand how the dogleg algo works.
It run's a given function until the function result is within treshold, <1e-6.
It uses one or more variables with a initial guess value. It also updates a inverse jacobian "J" in the iteration, wich
i think we need, but not for sure.

However, if you compute function eq44_G123, the function error is alway's near absolute zero.
As a result of that, the dogleg solver does nothing at this moment.

1. Basicly eq44 is not ok. It should return a error value, then dogleg can optimize.
2. I don't understand yet, how to get the clothoid compound to fit the given end point.

And for info. I did not use any fresnel header file, fresnels are not used, maybe also wrong.

This is no longer the recommended method to flash the board. pyOCD has proven to be more reliable.

Use the first part of the video to convert a ST-Link to a CMSIS-DAP probe with the following firmware.

github.com/scottalford75/Remora-NVEM/blo...NVEM-STM32-1.0.0.bin

And then use pyOCD to flash the board as described in this thread.