sir , i am sure of hoe good teacher you are that i follow your work
i see that you are doing very well in your path and sure you will solve the problem , i am trying to think systematically when i say that the loss of the data may be because deffirent time frams between the sender and reciever or the sequencing -sorry about the terms are not accurate , i am a beginner- hope this might help , it is enough to me now to run a customed component to do the job , i am struggling to make it , its performance like mach3 feature is great now , i hope you help me to do such component , i have just made one and compield it but it crashed because of syntax error , i used a c code with primary approach
angle = atan2(y-vel, x-vel)
y-vel = y-vel + y-acc * dt // dt = fperiod
x-vel = x-vel + x-acc * dt // dt = fperiod
for open loop machine - stepper motors

I guess my question now would be: Why are there relatively huge steps in the commanded position?

Die 2 files liefen in meiner Simulation fehlerfrei. Sogar bei Radius Toleranz auf null gesetzt.

[RS274NGC]
#CENTER_ARC_RADIUS_TOLERANCE_MM = 0.00127
CENTER_ARC_RADIUS_TOLERANCE_MM = 0


Bezüglich den % am Anfang/Ende ist noch diese Info verfügbar:

Using % to wrap a G-code file will not do the same thing as using a program end. The machine will be in what ever state the program left it in using %, the spindle and coolant may still be on and things like G90/91 are left as the last program set them. If you don’t use a proper preamble the next program could start in a dangerous condition.
 

Some people run the pi4b with a slower servo thread eg 2 ms or 1.5 Ms with mesa cards
run:
latency-histogram  --nobase --nobase 1000 --show
and share the screenshot here. the 4b is marginally OK but 126us is fine for a Mesa card at 1 ms servo thread.

No. The tool change position has to be commanded in the Gcode. The tool change on this mill is manual.

Thank You!
-Steve

This might be still related to the fact the Yaskawa does not support LRW

github.com/sittner/linuxcnc-ethercat/issues/121

forum.linuxcnc.org/ethercat/48110-etherc...-responding?start=20 (there seems to be a patch / experimental code further in the thread)

Not sure if this was ever resolved in any linuxcnc-ethercat version.

I have these snippets right now. The first is the original behaviour and the next one is after a full day of tweaking the PID values and acceleration. In both the axis moves very slowly.   

You could send them one of the sample programs that is installed with LCNC.  Like chips.ngc.

Keep in mind that your tool changer is going to be specific to your machine and LCNC configuration, especially if the tool change sequence requires anything beyond "M6 Tn G43" in it.

Example - does your machine require the post to raise the head to a safe point before the tool change M-code is commanded, or is that part of the internal change sequence?

Same for any custom or machine-specific M-codes.

Ich wuerde sagen du schaust dir Parameter P04.04 an. Laut Chinglischer Anleitung steht da sowas wie: "3 ： When any frequency arrives, it will be powered, otherwise it will lose power (related to the setting of P02-10)"

Frei Plattdeutsch bedeutet das soviel wie:

Wenn P04.04 = 3 (Frequenzvorgabe erreicht) dann schaltet das Relay.

Verdrahtung:

Du nutzt NO (normally open):
• VFD CM → 24V Versorgung (+) anlegen
• VFD NO → Mesa Input (z.B. IN05)
• Mesa GND bleibt wie gehabt

Waehle einen freien Input an der Mesa und verdrahte.

In deiner HAL kannst du das dann verbinden:

net spindle-at-speed hm2_7i96.0.7i96.0.0.input-05 => spindle.0.at-speed

Der Input ist nur ein Beispiel. Schau was du frei hast bzw. wie genau der Input bei der 7i96 heisst. 

Can you plot (with halscope) the C axis commanded and feedback positions?

That would help diagnose the issue.

No not that old. But maybe I lack some general understanding.
1. my raspi4 gets an base thread may jitter of 126 ms (126000 ns), which is supposed to be not usable for linuxCNC ( so why is there an image for that?)
2. or is the mesacard exactly there to address that problem with it's FPGA?

Sorry for the somewhat below rookie-level questions

ballscrews ar primary because the original threads in brass nuts have quite some deadway. But yes, it is all metal and the swallow tail rails are even adjustable. Plus it is the same model the other guy was using for years.
Only difference so far: He used a setup, where the motor was separated from the machine with a belt transmission and the z-axe was only moving the milling bit.

Also: I thought I might use one of my older PC standing around, but the latency test told me other wise (150ms and above).
Next try raspi4...