Advanced Search

well, it seals at least. with no pressure it spins pretty nice, but my first pressure test tells me once you add pressure it gets tighter to spin. now i have two air zones by design and i am glad i did not add more to get fancy. once i add a solenoid vale and control the air flow i will only have one zone under pressure at a time and i hope the helps with the spinning. i would be afraid to try and cut the glands any deeper the shaft already pulls itself through the body with gravity when put together. i have to do more testing to see where i am at unfortunately.

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.

@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.

Thanks for sharing. I did investigate reading the device tree when working on the RP1 driver but took the easy path so as to focus on the DesignWare SPI side of things. Looks like I'll need to rework the board detection. At least the Mesa code will be a great starting point.

I have a small AC rotary but it does not have a nutating joint just a plain old 90° setup.

Hi All,
I plan to upgrade my MH400 e with Linuxcnc. I bought a 6i25 + 7i77 and now I´m starting to configure the Cards In/ -outputs for my Mill. I have a fresh install of Linuxcnc (2.9.4) and run into the problem that whenever I try to configure the PWM Signals of the 7i77 the tap just isn´t there. I had a bit of success when i tried the PnCConf Wizard on the Live distribution, but there I couldn´t configure the encoders on the 7i77. I tried older Versions of Linuxcnc but that also didn´t help. I hope someone can point out my mistake, that I am obviously making because it seems to be working for so many others . 

Thanks for your help,
Simon

Is the 7I77 jumpered for differential inputs?

It may be a noise issue. One way to check if it's a common mode noise issue
(noise that exceeds the common mode range of the RS-422 receivers)
is to enable encoder error reporting:

setp hm2_5i25.0.encoder.00.quad-error-enable true

Once this has been done, inputs that violate the quadrature sequence
(often noise will do this) will set the quadrature error flag:

hm2_5i25.0.encoder.00.quad-error



 

aikiaviator wrote:

What is the process to move the X, Y and Z axis back to mid point, when the machine says cant because limits activated?
 

I think you have this a bit wrong. Home switches need to remain triggered until the end of travel. That way, Linuxcnc know which way for initial homing movement. Take the case  of the X axis, Say the home switch is 40mm from end of travel on the left and it stays triggered to the end of travel. If the home switch is triggered when homing starts, Linuxcnc knows it must travel to the right to find the home switch edge. HOME_OFFSET sets the final position. If this is a shared home/limit switch you need to move to the right so the switch is no longer triggered otherwise it will trigger a limit switch error once homing finishes.

If you have seperate home and limit switches, the final position can be in that 40mm where the home switch is held triggered.