Hi, first post. This is IgH only (not LinuxCNC), 1 kHz servo/press application.

Hardware / software
- CPU: Intel N100 (4 cores)
- Distro: Debian 13 (Trixie)
- Kernel: 6.12.101+deb13-rt-amd64, PREEMPT_RT
- IgH: 1.6.9, native driver ec_igc
- NIC: Intel I226-V (8086:125c), dedicated EtherCAT port
- Slave idle in PREOP during the test (application stopped)
- Governor: performance (cores locked 700-800 MHz)

CPU isolation (cmdline)
isolcpus=managed_irq,domain,3 nohz_full=3 rcu_nocbs=3 irqaffinity=0-2
intel_idle.max_cstate=0 processor.max_cstate=0 idle=poll

RT thread is pinned to isolated CPU3 with SCHED_FIFO.

Measurement
Same method as examples/dc_user MEASURE_TIMING:
clock_nanosleep(CLOCK_MONOTONIC, 1 kHz) wakeup latency, then only
receive / process / queue / send. No PDO mapping, no CiA402.
SCHED_FIFO 90, taskset -c 3, 60 s / 60000 cycles.

Wakeup latency (µs)
min / p50 / p90 / p95 / p99 / p999 / max / avg
= 6.311 / 6.901 / 10.717 / 10.898 / 11.143 / 11.592 / 29.024 / 7.741

Question: for I226-V + ec_igc on 6.12-rt, is this in the expected
range for 1 ms, or do people still prefer I210/igb for the worst-case
tail?

Thanks.

Thanks Peter. Same md5 here for both files, Modbus block on TB4-14..17 with 1v3pkt, so neither the bitfile nor the wiring is the difference — and the transceiver, pad and connector are proven by the 7i84 running error-free in sserial on that same port.

Since it works for you with a plain setup, could you post the minimal config you tested on master — the mesambccc file and the HAL lines — and say whether tx-drv-en.invert_output appears in it? On my card the driver is never enabled during TX without it (checked on the analyzer), and I see no polarity handling for "Drv Enable low" in pins.c.

Which master build was it? Mine is 2.10.0~pre0.6386 (g3cd702c690).

One correction to my report: all symptoms, including the dead transmitter, were reproduced across several full power cycles, so it is not a stuck state.

I will re-flash 1v3pkt from the md5-verified file and redo a minimal test with a single hm2_modbus transaction and the analyzer directly on TB4-16/17, no raw register writes, and post the capture.

Hu Gemox,A plasma cutter generates a huge amount of electrical noise, so all signals should be galvanically isolated.For this reason, I would not recommend the Mesa 7i97. Instead, I would use a 7i83 for the analog outputs, since it provides galvanic isolation from the rest of the control system.To determine the complete hardware configuration, the machine’s existing electrical schematics would need to be reviewed.A THCAD2, or an equivalent interface, is necessary to measure the plasma arc voltage. This voltage measurement is used by the torch height control to maintain the correct distance between the torch and the plate.I would not recommend using a stepper motor for the Z axis, as it may not be able to achieve the required speed.How are you planning to generate the G-code?

Logthor wrote:

this would work, right? 

Yes, this is a very similar circuit to the one used in BOB and will work identically.
The difference is that the power supply for this circuit should be not used for anything else, that BOB does not provide.
Voltage is a potential difference and is measured between two points.
The same wire, it may be 12V to the second pole of the power supply, but hundreds of volts to machine chassis.

Did you download this through the pcnconfig or the browser?

I would think something like this would work, right? It has a PC817C, so I figure it is used to optically isolate the two circuits. What has me slightly concerned is that the listing (and many others) don't mention the fact that they are optically isolated (does this mean that it isn't?).

I see what you mean now about it not being properly isolated. I'll buy a cheap board off of amazon. In the mean time though, I just want to make sure I know how to set it up in general. I just want to know why I'm not getting anything out of it when I issue a s command.

I don't have my KBIC attached. I just wanted to see if I could read a voltage of 7 at 1400rpm from the terminals of the bob before I even attach it to the KBIC. The KBIC is not isolated, but the BoB is supposedly.

Just tried a 7I95T (Rev. A) with

(MD5 checksum)

f1c9dff646bc7496e0883b3d0afbc05d  7i95t_1v3pkt.bin

And all works as expected with a GS10 VFD

PktUART pinout for this configuration is:



 

This is with 2.9.10 and Master =2.10Pre (as of a week or so ago)

I also checked:

26b79f7bdef81b79ab3299925886b118 7i95t_1pktv2d.bin

and it worked as well, though it uses the other 7I95T RS-485 connection

You can use 7i80hdt_sv12d.bin (for 3 7I33s)
 Just enable 4 encoders and 4 PWMgens and the
rest of the pins will revert to GPIO (for the 7I37s)
 

Yes, I'm seeing exactly the same issues you're describing.

Adding M5 to on_abort.ngc does indeed work well in this case, although, as you say, it only masks the problem.

Nevertheless, it won't hurt to leave M5 in permanently.