Advanced Search

Where in Linux are these signals generated, and how can I configure them for a specific driver? At what point do I need to inform Linux that the driver should specifically use control word 0Fh? I need to insert 0Fh into 6040, but it doesn't seem to work.

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.