I might have one in my spare parts drawer, I'll check when I'm in the shop.
Pick it up in Berlin or send me your address at shu at admin dooot world

I have done it in the past manually, it's not trivial. Best way is to edit the g-code and reload, trim away everything after the preamble to the last plunge move.

It's not possible to just resume the file from the point it ended as that is most probably right in the workpiece without a safe direct line from the tool height probe position. So we need at least a safe ramp/plunge movement. And the preamble needs to run again, to use the correct tool height offsets, tool diameter compensation, bring the spindle up to speed...

I don't think there can be a generic resume-at-position for this that fits all. Some tools that have a certain orientation or don't enter the workspiece colinear to the spindle, e.g. t-slot cutters, profile cutters in general, taps. And then there's five axis machines.

Have you checked the digital inputs? 
there is origin and pos/negative limit set as default functions for the digital input. If the limits are setup for NC wiring and nothing is connected, it might become an issue

Where is it called from and what does the code around it do? send a URL into github
I don't think it can simply be  ignored.

The code above displays message only once.
This may mean either a serious problem or a one-off event with no impact on further work.
This, in turn, means that this message says nothing, warns against nothing and is unnecessary.
The right thing to do is to run latency-test or latency-plot for a few hours immediately after installation, which will clearly answer the question whether the hardware and software can be used safely.

"Unexpected realtime delay on task" means that linuxcnc did not get everything done in the allotted 1ms time of the servo thread. This is nothing to do with the LinuxCNC application.

In kernel traces I did a long time ago on an i5 machine with Bookworm, Linuxcnc typically took 200 us to execute the servo thread and sleeps for the remaining 800 us. That 800 us is the safety buffer for real time tasks. Sometimes there is a Linux task that consumes a lot of the  CPU time which impacts on the servo thread and LinuxCNC does not have enough time to get everything done in time. Then the system reports the realtime delay and generally disables linuxcnc (so long since I have experienced this myself I can't remember). There are many possible tasks that can cause this.

One new source I found this week is that if the wifi has poor signal strength, a NetworkManager task fires looking for any stronger wifi signals every 30 seconds or so and causes a latency spike every 34-36 seconds. Because CNC machines are not generally wandering the aisles of a corpporate workspace, its a no brainer (and safe)  to disable this service. Linux obligingly provides an obscure process to do that.... Don't ask me what it is, I've forgotten already.

Addendum:
I took a deeper look (again) into the datasheet of the motor driver. There is a green LED that flashes at a rate of about 2s. According to the datasheet, this means, that the motor power is still off. When the power is on, this LED should light up constantly without flashing.
Reading the statusword of the driver shows a value of 0xb094. According to the cia402 specification, Bits 3, 5 and 7 are 1. This means OP is enabled, quick stop is active and there seems to be a warning. Maybe this is helpful.
Greetings 

Once again.
Many times I had the problem with the "Unexpected realtime delay on task" message, which meant nothing and only annoyed the user because neither latency-test nor latency-plot showed anything wrong.
This has nothing to do with compiling LinuxCNC yourself, except that compiling it yourself allows you to disable this message.
As for the message itself, I suspect that either the procedure displaying it is bad, or it is called at the wrong moment (LinuxCNC starts and maybe something jams, but only then and only once).

Like pic attached..

Thank you, guys, for your help! I appreciate that. 

I tried Rod's advice and got an xml part with the needed registers. This seems like a bit of progress. I took the needed parts from the auto-config.xml file and copied them to my own ethercat-conf.xml (slave ID 3). However, I tried adapting my hal file for the A axis (for which the driver is for) similar to the servo drives I already integrated, but was not able to get any reaction of the stepper motor that was connected on the stepper driver. It's a closed loop motor, but to exclude possible errors, I switched the driver to open loop mode for now. I tried reading some registers back with the ethercat read_register command and the values seem to be valid so far. The driver is in OP mode. But I assume, I've done something wrong in my hal file. If I try to move the A axis, the motor doesn't turn in any way. After some (theoretical) distance after pressing the A+/A- button in LinuxCNC, I get a joint following error. I'm not sure, if the PC really is talking to the stepper driver. If I try to move the axis, I would assume the target position register is updated somehow. But if I read the register value using the ethercat read_register command, I always get the same number.
Could you please do me a favor and have a look at my files I attached? Is there a possibility to guess the problem? I'm quite confident, that I may get everything I need for my machine to work. The A axis is the only missing piece. I don't want to integrate another controller like the PoKeys57CNC I have laying around. Ethercat is a really nice solution.
Thank you very much.

Christian

Its nothing to do with building LinuxCNC. As time goes on, the hardware manufactuters add more power saving features which induce latency so it takes more work to get it under control. Trixie is no worse than Bookworm. The biggest issue is not using the dkms drivers with realtek NIC's. Try to always use Intel NIC's. I've covered this and other steps in a few videos over the last 12 months or so on my YouTube channel.