Advanced Search

More info
How is the wire break sensor included in LinuxCNC?
Is that a normal hi/low signal that LinuxCNC sees?
If yes, wiring that signal to amplifier fault in hal would disable the machine, not e-stop, so you can change the wire and continue working.
You can also wire it to feed hold or motion inhibit, but both will just stop motion and wait while the drives will remain enabled, actually this might be better if the machine has something that can move when motors are disabled.

Hello, 

During the initial setup and test adjustments I performed before the final assembly, the probe function was working correctly. Since I completed the final adjustments, particularly the connection and calibration of the encoders, the probe no longer works. Instead of moving down, it moves up until it reaches the home position.

My Z-axis has a large travel range, which is why I set a HOME_OFFSET of 100mm to position the torch closer to the table. Manual jogging is in the correct direction, and homing also works properly.

All the travel parameters were the same as those in the attached file when it was working, only INPUT_SCALE and OUTPUT_SCALE have changed.

Do you have any idea what could be causing this issue?

 

Hello,

The forum I often browsed and for most problems I found help. Now, unfortunately, the issue has outgrown me. I have a plotter for cutting styrofoam with hot wire.
I need a wire break control in it. The wire is controlled by PWM. The problem is that I would like the control to take place only in a specific case, i.e. when the machine executes a program with (M3) on, the wire breakage would cause the machine to pause or e-stop. My control system works only when current flows through the wire then there is a high state on the sensor output. Can anyone help me solve this problem?

Translated with DeepL.com (free version)

If I turn on the machine with a button, why doesn't the control word value change? Please explain to me not where the signals are transmitted, but how to send a specific value to the control word.

You can try to add this to my routine.
I don't know if this make a different, because I only get the messages of zero feed rates if I set "fast probe fr" or "traverse fr" to "0".

 

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.