So the drive didn't have Profile Position?
The trajectory seems a bit crude but as long as it works
For higher speeds and if the motor stutters you can try something like this.
Especially the starting and stopping can be smoother.
But don't overdo it, if it works, it works
 

Witam czy ten komputer nada się dla linuxcnc
pl.aliexpress.com/item/1005010493503938....%7C_p_origin_prod%3A

Halfway down in this post rodw describes how to add a udev rule for /dev/EtherCAT0
forum.linuxcnc.org/ethercat/45336-etherc...-how-to-step-by-step

For the interface, there are many ways. I have the following in /etc/network/interfaces for my ethercat interface
It brings the enp2s0 interface up, without IP address

Check what's in syslog (sudo dmesg) if there are more problem

Hey, sowas in der art hab ich mir schon gedacht…
Dank dir, werde es nachher mal ausprobieren.
hast du dann nur DEFAULT_LINEAR_VELOCITY runtergesetzt oder auch noch andere werte und auf welchen wert hast du's runtergesetzt?
 

Did you try this?
Look for the heading : 2.8.2. Handler Patching - Subclassing Builtin Screens
linuxcnc.org/docs/stable/html/gui/qtvcp....cp:modifying-screens

Look for the direction on handler file placement.

Running linuxcnc from the terminal can give more info too.

you might try to read the firmware by glitching the voltage, I did that with an STM32F0 part in the past (but another application), I was even able to re-flash the image. I don't know if it also works with the G0, but you might try. Most importantly is to remove the capacitors.

sec-consult.com/blog/detail/secglitcher-...32-microcontrollers/

I will take a photo of the wired USB version later this week since my pendants are in the shop

Thank you so much.

Now I installed LinuxCNC to PC (HP Elite 800 G4 with Intel LAN) using 2.9.4 iso,
I did recompile EOE disable along to the procedure, I did not upgrade,

but I could not improve my bad situation in using Yaskawa Drive.

I found ...something strange.
Ethercat service starts automatically,and ethercat slaves works after reboot.( "ehtercat slaves " shows all servo drives )

But I have to do this command to execute LinuxCNC everytime after reboot.

chmod 666 /dev/EtherCAT0

but If I did this, LinuxCNC doesnot handle Yaskawa servo propery (A12).

And also, in Network Connection (in "TASKBAR on the top of Desktop") I could see a NIC Interface that I'm using for "EtherCAT".( see attachment jpeg image)

What am I missing ? What should I check ? 

You can add to the user tab and turn it on in the initial file, this is covered in the docs

kcjengr.github.io/probe_basic/update_notes.html

I can't use PP mode, but I found solution for CSP mode:  

@Andrax, first of all: thanks for sharing your examples — it’s clear you’re on the right track, especially by thinking in terms of watchdogs and by splitting the sequence into “start → run → done”. That’s already more than many integrations do.

Just for context: I come more from the Mechatrolink / Yaskawa world, but at the motion-control architecture level the concepts are the same (state machines, ACK semantics, watchdogs, reference sync, etc.), so I’m looking at this more from that angle than from any specific CiA-402 detail.

Looking at your two snippets together, it feels like each one gets an important part right:

In the cia402_homecomp (C) version you already have a proper state machine with timeouts (start_timeout / run_timeout), which is exactly the kind of safety supervision you want in an industrial setup to avoid waiting forever for a drive.

In the pseudo-PLC example you’re already trying to tie the logic to real drive signals (bits from 0x6041, speed, etc.), which is also exactly the right direction.

Where they still feel a bit “misaligned” to me is this:

The cia402_homecomp does have watchdogs, but it’s not really driven by the drive’s real status (it relies on cia-homed / cia-error coming from outside, and doesn’t directly check “started / motion / done” conditions itself).

The pseudo-PLC tries to use real status, but the start and motion proof parts are still fragile (e.g. setting bit 4 = 1 doesn’t guarantee a rising edge, and comparing target speed <> actual speed isn’t a very robust proof that motion really started).

From an industrial point of view, the sequence usually looks roughly like this (independent of whether it’s EtherCAT, Mechatrolink, Sercos, etc.):

Generate a start event (pulse or temporary level, depending on the drive), not just keep the bit stuck at 1 forever.

First watchdog: after start, wait for either a real “homing started” indication or a real proof of motion (position change / actual velocity > threshold). If that doesn’t happen within X seconds → fault.

Second watchdog (overall): while homing is running, wait for the real “done” indication from the drive. If it exceeds the overall timeout → fault.

On completion: clear the start and synchronize the reference (pos_cmd with pos_fb) to avoid jumps / following errors when going back to CSP.

So in a way, the idea in your first code (state machine + timeouts) is right, and the idea in your second one (looking at real 0x6041 bits / real behavior) is also right — what’s missing is bringing those two together: a state machine whose transitions are driven by real drive status and real motion, not only by logical external signals.

One small additional point from an industrial perspective: in your C example a homing fault ends up triggering a global E-STOP. In many systems we try to separate those two concepts: a homing/process fault usually leads to an axis fault or a controlled stop/disable of that axis, while E-STOP is reserved for real safety events. That separation often makes diagnostics and recovery much cleaner, while still keeping the safety chain intact.

This is not meant as criticism of what you’ve done — on the contrary, it’s pretty clear you’re already thinking in exactly the right direction (watchdogs, states, safety). It’s more about aligning it with what is usually done in industrial integrations:
start as an event → real confirmation that it started → real confirmation that it finished → reference synchronization.

If we can move cia402_homecomp more in that direction (even if via masks/config per drive), I think it would solve a big part of the homing and mode-switching issues people are running into.

No, G40 must come first.A change is only possible without tool compensation. 
G40
...
G52
 

Hakan wrote:

Set controlword to 6, 7, 15 (op-enabled)
 

It is it.
Now works.
(Not usable yet, but homing and moves).
XML config file: Script: And HAL only for testing: No speed and acceleration control, it is to do...

I changed the macro names, but I wasn’t able to get it to work.
I’m not sure if the names I saw in Qt Designer are the correct ones…

There is one at the end Should there be another?

I copied your file to the Screens folder, ran LCN, but no additional PINs appear in Show HAL. What am I doing wrong?