- GCode and Part Programs
- G&M Codes
- Digital outputs (M64-M65) affected by lattency over MESA ethernet hardware?
Digital outputs (M64-M65) affected by lattency over MESA ethernet hardware?
- DEVILHUNTER
- Offline
- Junior Member
Less
More
- Posts: 29
- Thank you received: 8
05 Feb 2023 10:48 #263745
by DEVILHUNTER
Digital outputs (M64-M65) affected by lattency over MESA ethernet hardware? was created by DEVILHUNTER
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.
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.
Please Log in or Create an account to join the conversation.
05 Feb 2023 11:25 #263746
by chris@cnc
Replied by chris@cnc on topic Digital outputs (M64-M65) affected by lattency over MESA ethernet hardware?
I would do it with a custum M-code and include the sleep time direct.
#! /bin/bash
#---- M100 4th axis brake off -----------
halcmd setp "your 4th axis brake pin" true
sleep 1
exit 0
Please Log in or Create an account to join the conversation.
06 Feb 2023 12:50 #263817
by andypugh
Replied by andypugh on topic Digital outputs (M64-M65) affected by lattency over MESA ethernet hardware?
Do you ever need to move the 4th axis while cutting?
If not, then brake release - index - brake apply is a built-in function of LinuxCNC.
See LOCKING_INDEXER
linuxcnc.org/docs/stable/html/config/ini...t__lt_num_gt_section
and also LOCKING_INDEXER_JOINT and unlock_joints_mask
If not, then brake release - index - brake apply is a built-in function of LinuxCNC.
See LOCKING_INDEXER
linuxcnc.org/docs/stable/html/config/ini...t__lt_num_gt_section
and also LOCKING_INDEXER_JOINT and unlock_joints_mask
Please Log in or Create an account to join the conversation.
- DEVILHUNTER
- Offline
- Junior Member
Less
More
- Posts: 29
- Thank you received: 8
06 Feb 2023 16:53 #263849
by DEVILHUNTER
Replied by DEVILHUNTER on topic Digital outputs (M64-M65) affected by lattency over MESA ethernet hardware?
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.
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.
Please Log in or Create an account to join the conversation.
- tommylight
- Online
- Moderator
Less
More
- Posts: 19343
- Thank you received: 6477
06 Feb 2023 16:59 #263850
by tommylight
Replied by tommylight on topic Digital outputs (M64-M65) affected by lattency over MESA ethernet hardware?
What process?
A bit of hal should do pretty much whatever is needed, within reason.
A bit of hal should do pretty much whatever is needed, within reason.
Please Log in or Create an account to join the conversation.
- robertspark
- Offline
- Platinum Member
Less
More
- Posts: 915
- Thank you received: 216
06 Feb 2023 19:46 #263862
by robertspark
Replied by robertspark on topic Digital outputs (M64-M65) affected by lattency over MESA ethernet hardware?
do you have a motion move directly after the m code?
linuxcnc.org/docs/devel/html/gcode/m-code.html#mcode:m62-m65
linuxcnc.org/docs/devel/html/gcode/m-code.html#mcode:m62-m65
Please Log in or Create an account to join the conversation.
- DEVILHUNTER
- Offline
- Junior Member
Less
More
- Posts: 29
- Thank you received: 8
11 Feb 2023 07:56 #264275
by DEVILHUNTER
Replied by DEVILHUNTER on topic Digital outputs (M64-M65) affected by lattency over MESA ethernet hardware?
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.
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.
Please Log in or Create an account to join the conversation.
- robertspark
- Offline
- Platinum Member
Less
More
- Posts: 915
- Thank you received: 216
11 Feb 2023 08:52 #264279
by robertspark
Replied by robertspark on topic Digital outputs (M64-M65) affected by lattency over MESA ethernet hardware?
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
such as
M64
G0 C1
G4 0.25
and
M65
G0 C0
G4 0.50
or something to that effect
Please Log in or Create an account to join the conversation.
11 Feb 2023 14:46 #264291
by Lcvette
Replied by Lcvette on topic Digital outputs (M64-M65) affected by lattency over MESA ethernet hardware?
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.
Please Log in or Create an account to join the conversation.
11 Feb 2023 16:42 #264294
by PCW
Replied by PCW on topic Digital outputs (M64-M65) affected by lattency over MESA ethernet hardware?
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.
depends on what's happening in userland, not good for a brake release that needs to be synchronized with motion.
The following user(s) said Thank You: Lcvette
Please Log in or Create an account to join the conversation.
- GCode and Part Programs
- G&M Codes
- Digital outputs (M64-M65) affected by lattency over MESA ethernet hardware?
Time to create page: 0.110 seconds