Digital outputs (M64-M65) affected by lattency over MESA ethernet hardware?

Hello everybody,

So I have a machine runing on a 7i76e that has a 4th axis with brake. The brake is activated with digital outputs over the program (M64 and M65) with 0.25 seconds delay (have tested also 0.5 seconds). Not very often, but sometimes, I get an overcurrent alarm on the 4th axis servo. Pulse generation is perfect, even runing my servos over 500kHz.

I have notice that when I use a remote desktop (TeamViewer over WiFi), this issue happens every time within 5 minutes of the program. So my guess is that could be a lattency issue in the servo thread. Have not checked the numbers yet, I will force the problem with the lattency test running to confirm. I don't have any lattency spike alarm though. Do you think this could be the cause?

As solution I'm thinking on adding a wait on an imput M66 code after the digital output. I can read either the internal signal in LinuxCNC, but don't think will solve the problem, or connect the output pin on the hardware to an input pin and read it. Any other idea is welcome!

Regards.

I would do it with a custum M-code and include the sleep time direct.

Thanks Chris, it's worth a try to see if the behaviour is different.

Altough I use it as a indexer Andy, I cannot use the locking indexer because is a "two brake" system. The built-in function would work perfect with one of them, but the other one need to be connected and disconected in process and could cause the same issue.

do you have a motion move directly after the m code?

linuxcnc.org/docs/devel/html/gcode/m-code.html#mcode:m62-m65

The second "brake" is an antivibratory system for the parts. Needs to be activated in some operations and deactivated in others, so I have to select in Gcode when to activate and deactivate it. By hal I could implement some safety so the rotary axis don't turn when is engaged but If my problem is lattency related I don't expect different behaviour.

After the M codes I have a G4 dwell of 0.25 or 0.5 seconds. After that dwell there is a motion, but since I''m using M64/65 and not M62/M63, the motion movement should not affect.

Thanks to all. Regards.

can I suggest maybe adding a fictitious g motion code immediately after the m64/65

such as
M64
G0 C1
G4 0.25

and
M65
G0 C0
G4 0.50

or something to that effect

I saw this problem on a ATC tool changer remap with M64/5 IO drove us crasy trying to get the machine to stop the platter on target and it was a geneva mechanism to boot. finally swapped out PC's and problem was resolved the one being used was just a bit to laggy on non realtime IO.

I was wondering about that, AFAIK M64 and M65 are not real time so their timing
depends on what's happening in userland, not good for a brake release that needs to be synchronized with motion.