why jog before homing? I always disable it.

Can you do a

lspci -vv  | grep -A 10 2718 > pci.txt

and post pci,txt here?

 

I understand your concern now. I only use probing to find my Z height. X/Y is handled by a crosshair laser. Once centered on the starting position of the cut, a button attached to g-code computes the actual position by applying offsets for both X and Y to the current location of the laser. Offsets are stored in my INI file and can be changed if needed without touching the code.

Er, no. It’s not that simple; LinuxCNC isn’t plug-and-play. If you don’t have any prior knowledge, you should put the A6 aside for now and start with simple stepper motors. You’ll first need to learn how the system works and what each component does. With EtherCAT, you’re moving beyond the hobbyist level, and even professionals sometimes find it frustrating.

yes, mesaflash still says 5i25 not found

 

Did you try running mesaflash after running LinuxCNC?
 

The problem isn't the 50ms, it's that during that time the machine is *moving*. I.e. where you home depends on the bouncing of the sensor, which means it's unpredictable, which means every other position is also unreliable.
If you "hit" on the first contact, instead of waiting for the physics to settle down, you get a more predictable "moment" when the machine is in the known state.
You'd think it wouldn't matter, but I've seen my probe go measurably past the right spot before it "hits", and my probing routines actually probe in both directions (G38.2 then G38.4, and take the average) to try to eliminate this overshoot.
With a "first hit" debouncer, you could set the debounce time to 3 seconds and still get the right value.

I don't see a problem with de-bouncing a signal when homing since the purpose of homing is to put the machine in a known state and stop before doing anything else. If that takes an extra 50ms to insure the starting position of all axes, it is a non sequitur since the result is the machine is stopped. It might be a minor issues when hitting a limit switch while machining, but I'd rather error on fact rather than bounce.

Just my two cents worth.

This may not help but this 2017 post shows how to update a gmoccappy screen handler from gcode which sounds like your problem 1
forum.linuxcnc.org/plasma-laser/32691-settings-from-g-code-file
Here different values are set using an analog input which is decoded and used to modify screen elements. eg 900 and 999 change screen settings.