Advanced Search

Before this, I tried a component and attempted to read the current X & Y position and the prior x,y position. This allowed me to calculate the radius which I wanted but it never worked accurately. So I went to the state tags approach and Andy one of the devs convinced me to add the heading while I was at it.

This is something that is missing in Linuxcnc. This is actually quite complex. I had a go at it some years ago but my use case faded away.
The pull request still persists. github.com/LinuxCNC/linuxcnc/pull/900
I got it working but it needed a bit of cleanup once the devs reviewed. It really needs to be completed.

This gets pretty deep into the Linuxcnc internals. The interpreter and motion are totally seperate entities in Linuxcnc. The interpreter tokenises the gcode so motion only sees the waypoints.

The interpreter knows or can calculate the centre of the G2/G3 arc and its radius. Motion does not. The change which enabled this was the release of state tags. State Tags passes the interpreter state to motion in real time. 
github.com/LinuxCNC/linuxcnc/blob/master...c/motion/state_tag.h
I extended the tags to include
    GM_FIELD_FLOAT_ARC_RADIUS,
    GM_FIELD_FLOAT_ARC_CENTER_X,
    GM_FIELD_FLOAT_ARC_CENTER_Y,
    GM_FIELD_FLOAT_STRAIGHT_HEADING,
The last field is the heading you need for your knife.
I published all of these state tags as interp.* pins including the heading so interp.heading is exactly what you need!

I was thinking recently now I am retired I should revisit this project. Maybe you can help and come along for the ride.
 

1.69 was released two weeks ago. Its what you get from their repos with a current version of Debian Trixie.
gitlab.com/groups/etherlab.org/-/packages

The code should be here.
gitlab.com/etherlab.org/ethercat/-/tree/1.5.2?ref_type=tags

From 2013. wow! that's old! From that, I would think it was built from source from Sourceforge. But well before my involvement.
Just checking Etherlab's gitlab releases, the first version on gitlab repo was 1.53 in 2024 so must be from Sourceforge

From what I can see, its not an Ethercat issue because the Debian 10 version of  linuxcnc-ethercat (with Ethercat 1,52) works with no problems  on Debian 13.3 with Ethercat 1.69.

Ethercat 1.6.8 is the previous stable release, have you tried that? 1.6.9 is a bit new I think, maybe they changed something?

Do you have the code for lcec version that works on your debian 10? Can you share the .so ? 

dear friends , i am new imegrant from MACH3 to LINUXCNC, and hope to get engaged to the Real-Time environomrnt and its cabapilties to lead a tangential knife to my application. that MACH3 has this feature with suffecient performance, 
i am intending to develop same logic HALComponent to direct A-AXIS and now i am doing the math and trying to apply it to real-time C languge progrmming , i hope if there any help to guide and cooperate to accomplish it
here is the first approach 


component tangent_knife;
// inputs
pin in float vel_x;
pin in float vel_y;
pin in float acc_x ;
pin in float acc_y ;

pin in float current_angle;
pin in float threshold;
pin in float lookahead_time ;

// outputs
pin out float command_angle ;
pin out bit intervention_required;


function _;
license "GPL";
;;

#include <rtapi_math.h>

FUNCTION(_) {
    double target_angle;
    double future_vel_x, future_vel_y;
    double angle_diff;

    // 1.Simple Lookahead
    //  V_future = V_current + (Acceleration * Time)
    future_vel_x = vel_x + (acc_x * lookahead_time);
    future_vel_y = vel_y + (acc_y * lookahead_time);

    // 2. alculate ange
    if (fabs(future_vel_x) > 1e-6 || fabs(future_vel_y) > 1e-6) {
        target_angle = atan2(future_vel_y, future_vel_x);
    } else {
        target_angle = current_angle;
    }

    // calculating (Shortest Path)
    angle_diff = target_angle - current_angle;
    
    // normalization  -PI و PI
    while (angle_diff > PM_PI) angle_diff -= 2.0 * PM_PI;
    while (angle_diff < -PM_PI) angle_diff += 2.0 * PM_PI;

    if (fabs(angle_diff) > threshold) {
        intervention_required = 1;
   } else {
        intervention_required = 0;
    }

    command_angle = target_angle;
}

Thought I'd ask here. User has upgraded from Debian 10 to latest Debian 13.3 and 2.10pre RIP config. Now Running grandixximos Ethercat driver but have not set syncToRefClock yet.

He reports:
With the same xml file, i/o and drive configuration, Debian 10 kernel 4.19 with ethercat 1.5.2 works fine, it has no latency at boot and hasn't given any problems. The current system has kernel 6.12 with ethercat 1.6.9 and has synchronization problems at boot, sometimes it doesn't see some drives on the bus, I'm forced to turn it off and on again. Would it be possible to use the current 6.12 kernel and linuxcnc 2.10, with ethercat 1.5.2?

I copied the lcec_conf and lcec.so files into the respective bin and rtailib folders from the Debian 10 version that I have and which works well on my machines, with linuxcnc 2.9.0 pre1 and etherrcat 1.5.2. At boot time, the drives are now seen within 1-2 seconds of booting and are always found on the bus.

This has 5 axis servos and a few Beckhoff modules attached to EK1100 

Next step is to add syncToRefClock

It seems odd to me that today's Ethercat hal driver is not performing but rolling back to an older version of it works. It seems to me his problem is the driver, not the version of Ethercat.

Any ideas or advice?

 

Unless you changed the firmware, I doubt that that's the issue.
 (all cards are tested and shipped with standard firmware)

You think it's worth it to give it another shot with flashing another firmware before returning it or do you advice against that?

The hal and ini file look sane so I would guess its some kind of hardware issue.
 So the card should be returned for evaluation
 

I tried on a Raspberry Pi 4 with image "image_2026-01-21-raspios-lcnc-2.9.8-trixie-arm64"
and on a Laptop with image "linuxcnc_2.9.8-amd64.hybrid"
and unfortunately i get the same results on both, with the simplest configs i can do, even in the test/tune tab in pnc wizard it acts the same way, Sorry guys i may be missing something really basic here, do you think it might be the firmware?

config name "GG" made on the laptop

Files attached

I am going to test this

net simulation-Zindex near.0.out => and2.0.in0
setp and2.0.in1 1
net index-logic-ok and2.0.out => tristate_bit.0.in

net spindle-index-en tristate_bit.0.out <=> spindle.0.index-enable

net spindle-index-en => tristate_bit.0.out-en

I hope this fix the Input-output connection signal form <=> spindle.0.index-enable

Dear andypuch

I am using a Ethercat encoder input, I only encoder cont (4096) per revolution, and turn counts

so I derivate the encoder counts to get the speed
and I derivate the turn counts to get the the Z index

Everything is working less the line
net spindle-index-en and2.2.out => spindle.0.index-enable

I test it with the screen qtdragon and the same result error (no good for lathes, lack on axis representation)
and with the gcomcapy screen and the same result error

I guessing that I am doing something wrong with the variable declaration, If I comment that line i can manipulate the spindle.0.index-enable on halshow mean variable is not linked

but if I uncomment the line on my .hal I get the error of that variable was already linked.

any suggest?
because I been testing allot thing but I still not viable to hit the ball

and as long I can see, this is my last missing point for run G33 or G76 on may ethercat Logan lathe 1943 upgrade (well I hope so, I can say that, after make it works).

Thanks again for your help.  Almost there but a few glitches. The 4th Axis program opens; X,Y and Z axis move however Y will not home. A axis homes but shuts the program down when attempting to move it.  Some type of (following error)..
I added a hash tag to the 3 axis enable line as I was getting an error saying the pin was already attached to another signal. When I applied the hash tag the program opened up.

Would greatly appreciate your comments.  I'm sure you would see the errors much sooner than I would.  It's been quite a learning curve, something I knew I would have to do sooner or later.

thanks in advance

The topic was not updated for a long time. I was trying to get the servo drives work with LinuxCNC and at one point I decided to start from scratch. Now my configuration is with only one servo drive. I managed to get the homing on index pulse working to a certain extent. The problem is when the servo is far from the index pulse, LinuxCNC gives "joint 0 following error". The servo keeps moving but LinuxCNC is disabled. For a successful homing, the motor should close to the index pulse. What is causing the following error? I attached the configuration files. By the way, the homing components used is the standard "homemod".

The "sudo dmesg" command shows warnings about datagram unmatched, time out and slave sync. The tried writing to 1C12:001 and 1C13:001 from the command line but it returns an unknown error "SDO transfer aborted with code 0x06010003". Using the attaced .xml file, when reading 1C12:001 and 1C13:001 from command line, it returns that the PDO mapping is flexible.

Can you make a new very simple config and test again?