G33.1 synchronized tapping problem
- spumco
- Offline
- Platinum Member
-
Less
More
- Posts: 1872
- Thank you received: 749
22 Jan 2025 05:18 - 22 Jan 2025 13:20 #319620
by spumco
G33.1 synchronized tapping problem was created by spumco
I'm trying to do some initial tests on my DIY lathe and having an issue with G33.1.
LCNC 2.10, Axis GUI
Specifically, I was trying to verify JoCo's concern that feed-hold and motion.feed-inhibit were disabled during spindle synchronized moves.
Attempted a simple rigid tap via MDI, and the Z-axis did the following unexpected things:
I have no tool offsets set, and no tool/tap installed.
Why the heck did it rapid down in Z at the start?
Is this something to do with using caxis.comp?
The following was in the terminal if it helps:
EDIT -
I wonder if my encoder sign is wrong...
forum.linuxcnc.org/24-hal-components/465...encoder-setup#248571
LCNC 2.10, Axis GUI
Specifically, I was trying to verify JoCo's concern that feed-hold and motion.feed-inhibit were disabled during spindle synchronized moves.
Attempted a simple rigid tap via MDI, and the Z-axis did the following unexpected things:
- Start position G54 Z0.1 (G53 Z-0.9)
- G90, G54
- S200 $0
- M3 $0
- G33.1 Z-0.5 K0.02 $0
- Z-axis waited for index signal
- Rapid Z- towards the chuck to Z-0.65 (not synchronized)
- Reversed spindle
- Moved Z+ at the programmed pitch to the starting point
I have no tool offsets set, and no tool/tap installed.
Why the heck did it rapid down in Z at the start?
Is this something to do with using caxis.comp?
The following was in the terminal if it helps:
Issuing EMC_TASK_PLAN_EXECUTE -- ( +509,+280, +375,M3\032$0,)
Issuing EMC_SPINDLE_ON -- ( +1304,+64, +0, +0, +0,200.000000,0.000000,0.000000, +1,)
mdi_execute_hook: MDI command 'M3 $0' done (remaining: 0)
Issuing EMC_TASK_PLAN_EXECUTE -- ( +509,+280, +376,G33.1\032Z-0.5\032K0.02\032$0,)
Issuing EMC_TRAJ_SET_SPINDLESYNC -- ( +232,+376, +0,0.020000,\000,)
Issuing EMC_TRAJ_RIGID_TAP -- ( +237,+456, +0,-0.000040,0.000000,-1.499000,0.000000,0.000000,96.651000,0.000000,-1.015200,0.000000,4.000000,4.000000,200.000000,1.000000,)
Issuing EMC_TRAJ_SET_SPINDLESYNC -- ( +232,+376, +0,0.000000,\000,)
mdi_execute_hook: MDI command 'G33.1 Z-0.5 K0.02 $0' done (remaining: 0)EDIT -
I wonder if my encoder sign is wrong...
forum.linuxcnc.org/24-hal-components/465...encoder-setup#248571
Last edit: 22 Jan 2025 13:20 by spumco. Reason: Research
Please Log in or Create an account to join the conversation.
- Henk
- Offline
- Platinum Member
-
Less
More
- Posts: 396
- Thank you received: 81
22 Jan 2025 18:03 #319651
by Henk
Replied by Henk on topic G33.1 synchronized tapping problem
I had a similar issue on one of my milling machines where I used a modified version of orient.comp.
At the time,not sure about latest version, orient.comp did not check the spindle encoder index each time it is enabled. I modified it so that it does, but at first I made a mistake that caused my modified comp to set the index enable pin for the spindle encoder all the time. This caused the same behaviour as described by you.
Check your index-enable pin while rigid tapping. It should go true and then false when the index is detected, the stay false until you initiate the next tapping cycle
Henk
At the time,not sure about latest version, orient.comp did not check the spindle encoder index each time it is enabled. I modified it so that it does, but at first I made a mistake that caused my modified comp to set the index enable pin for the spindle encoder all the time. This caused the same behaviour as described by you.
Check your index-enable pin while rigid tapping. It should go true and then false when the index is detected, the stay false until you initiate the next tapping cycle
Henk
The following user(s) said Thank You: spumco
Please Log in or Create an account to join the conversation.
- spumco
- Offline
- Platinum Member
-
Less
More
- Posts: 1872
- Thank you received: 749
22 Jan 2025 18:58 #319656
by spumco
Replied by spumco on topic G33.1 synchronized tapping problem
Thank you for the tip. I'll have a look this evening at index-enable.
If it makes any difference, I'm not using orient.comp for the main spindle... although I am using orient for the sub-spindle.
Main spindle is using caxis.comp but there aren't any references to index-enable in it other than a "//detect index-reset" statement.
If it is an index-enable issue, I wonder what would cause it to stay high?
Relevant HAL section for what it's worth:
# INDEX-ENABLE
net SPIN0-INDEX-ENABLE <=> hm2_[MESA](BOARD).0.encoder.04.index-enable
net SPIN0-INDEX-ENABLE <=> spindle.0.index-enable
net SPIN0-INDEX-ENABLE <=> joint.2.index-enable
net SPIN0-INDEX-ENABLE <=> pid.s0.index-enable
net SPIN0-INDEX-ENABLE <=> pid.c.index-enable
If it makes any difference, I'm not using orient.comp for the main spindle... although I am using orient for the sub-spindle.
Main spindle is using caxis.comp but there aren't any references to index-enable in it other than a "//detect index-reset" statement.
If it is an index-enable issue, I wonder what would cause it to stay high?
Relevant HAL section for what it's worth:
# INDEX-ENABLE
net SPIN0-INDEX-ENABLE <=> hm2_[MESA](BOARD).0.encoder.04.index-enable
net SPIN0-INDEX-ENABLE <=> spindle.0.index-enable
net SPIN0-INDEX-ENABLE <=> joint.2.index-enable
net SPIN0-INDEX-ENABLE <=> pid.s0.index-enable
net SPIN0-INDEX-ENABLE <=> pid.c.index-enable
Please Log in or Create an account to join the conversation.
- spumco
- Offline
- Platinum Member
-
Less
More
- Posts: 1872
- Thank you received: 749
23 Jan 2025 03:44 #319691
by spumco
Replied by spumco on topic G33.1 synchronized tapping problem
Update after some testing...
G33.1 behavior is the same as yesterday: When G33.1 is commanded via MDI, the Z-axis will rapid past the K value a bit, reverse the spindle, then feed in Z+ to the starting point and then stop.
Spindle-index-enable signal never gets set (turned on) during the G33.1 sequence. Not sure why LCNC is moving the Z-axis at all; it should just sit there waiting for the index-enable signal.
Encoder direction/sign appears to be correct. Counts up during M3/C+ and down during M4/C-.
I know the encoder index pin is working because if I set index-enable manually and rotate the spindle, index-enable goes false when the index signal is triggered.
When I home the C-axis, spindle-index-enable does get set, and turns off when the index pin is triggered.
Further odd behavior: if I manually set signal spindle-index-enable and try jogging the C-axis it starts rotating (at jog speed) nothing odd happens if I jog it less than one turn and then back to the index pin.
However, if I set index-enable and jog in one direction to the index pin, when the pin is triggered the C-axis instantly rotates (at max speed) another turn or so and stops at some random position. No following error trip, but halscope shows the ferror spikes as soon as the index pin is triggered.
I'm not good enough with halscope to catch the ferror spike in a screenshot, but it's there.
I feel like something isn't right with caxis.comp, but I'm not clever enough to really understand or troubleshoot it.
G33.1 behavior is the same as yesterday: When G33.1 is commanded via MDI, the Z-axis will rapid past the K value a bit, reverse the spindle, then feed in Z+ to the starting point and then stop.
Spindle-index-enable signal never gets set (turned on) during the G33.1 sequence. Not sure why LCNC is moving the Z-axis at all; it should just sit there waiting for the index-enable signal.
Encoder direction/sign appears to be correct. Counts up during M3/C+ and down during M4/C-.
I know the encoder index pin is working because if I set index-enable manually and rotate the spindle, index-enable goes false when the index signal is triggered.
When I home the C-axis, spindle-index-enable does get set, and turns off when the index pin is triggered.
Further odd behavior: if I manually set signal spindle-index-enable and try jogging the C-axis it starts rotating (at jog speed) nothing odd happens if I jog it less than one turn and then back to the index pin.
However, if I set index-enable and jog in one direction to the index pin, when the pin is triggered the C-axis instantly rotates (at max speed) another turn or so and stops at some random position. No following error trip, but halscope shows the ferror spikes as soon as the index pin is triggered.
I'm not good enough with halscope to catch the ferror spike in a screenshot, but it's there.
I feel like something isn't right with caxis.comp, but I'm not clever enough to really understand or troubleshoot it.
Please Log in or Create an account to join the conversation.
- spumco
- Offline
- Platinum Member
-
Less
More
- Posts: 1872
- Thank you received: 749
24 Jan 2025 20:46 #319785
by spumco
Replied by spumco on topic G33.1 synchronized tapping problem
Further update
G33.1 sort-of works after discovering an M03 command must preceed the G33.1 line. Simply turning on the spindle doesn't work.
Starting a Z0.5, when G33.1 is commanded (via MDI) the Z-axis rapids to Z0 and then starts the synchronized move to K-value. I didn't think that rapid move is correct behavior, but at least it was 'tapping' in and out.
However... G33.1 only works properly once per session. Subsequent attempts still have the Z-axis diving past Z0 to the K-value at rapid speed, reversing the spindle, and then a synchronized move back to the Z-start location. Spindle reverses again at that point, ending the sequence.
Restarting LCNC doesn't change the 'works once, then never again' behavior.
I've gone over all the spindle, encoder, c-axis, and PID settings & connections with a fine-toothed comb and can't see a problem.
I'm at a loss here.
G33.1 sort-of works after discovering an M03 command must preceed the G33.1 line. Simply turning on the spindle doesn't work.
Starting a Z0.5, when G33.1 is commanded (via MDI) the Z-axis rapids to Z0 and then starts the synchronized move to K-value. I didn't think that rapid move is correct behavior, but at least it was 'tapping' in and out.
However... G33.1 only works properly once per session. Subsequent attempts still have the Z-axis diving past Z0 to the K-value at rapid speed, reversing the spindle, and then a synchronized move back to the Z-start location. Spindle reverses again at that point, ending the sequence.
Restarting LCNC doesn't change the 'works once, then never again' behavior.
I've gone over all the spindle, encoder, c-axis, and PID settings & connections with a fine-toothed comb and can't see a problem.
- encoder velocity: S200 M03 $0 results in 200rpm, verified with a tach
- encoder position: 1 revolution of the spindle increases position by 1
- encoder position is connected to spindle.0.revs per the manual
- encoder sign: rotating the spindle forward (i.e. M03 direction) increases the encoder counts & position, and rotating it backwards decreases counts and position
- encoder scale: 1 turn of the spindle increases counts by 40000 (10kppr encoder)
- index: manually set signal index-enable HIGH and rotate the spindle. Signal goes LOW when the index pin is triggered, and it happens at the same place every time.
- encoder, spindle, and both velocity & axis PID index-enable pins are all connected and react together.
- spindle-at-speed works as expected, and is connected to spindle.0.at-speed
I'm at a loss here.
Please Log in or Create an account to join the conversation.
- spumco
- Offline
- Platinum Member
-
Less
More
- Posts: 1872
- Thank you received: 749
24 Jan 2025 21:09 #319786
by spumco
Replied by spumco on topic G33.1 synchronized tapping problem
Now it's getting weird.
New discovery - I can get G33.1 to repeat during the same session, but the distance Z rapids is dependent on the spindle speed.
(Starting from G54 Z0.5)
G33.1 Z-0.5 K0.05 $0
I think my earlier observation about Z-rapiding down and then synchronized movement up was correct... but the 'only works once per session' was incorrect. I didn't realize that spindle speed was driving the Z-axis 'start' point to different locations.
Why is the Z-axis moving at all - much less a rapid - before the index signal triggers the start of synch'd motion?
New discovery - I can get G33.1 to repeat during the same session, but the distance Z rapids is dependent on the spindle speed.
(Starting from G54 Z0.5)
G33.1 Z-0.5 K0.05 $0
- 60rpm: Z-rapids to ~Z0.1 before waiting for the index signal
- 100rpm: Z-rapids to ~Z-0.2 before waiting for index
- 200rpm: Z-rapids to ~Z-0.6 and immediately reverses spindle and moves Z-pos
I think my earlier observation about Z-rapiding down and then synchronized movement up was correct... but the 'only works once per session' was incorrect. I didn't realize that spindle speed was driving the Z-axis 'start' point to different locations.
Why is the Z-axis moving at all - much less a rapid - before the index signal triggers the start of synch'd motion?
Please Log in or Create an account to join the conversation.
- cmorley
- Offline
- Moderator
-
Less
More
- Posts: 7786
- Thank you received: 2077
24 Jan 2025 21:49 #319787
by cmorley
Replied by cmorley on topic G33.1 synchronized tapping problem
I would expect speed changes to change the sync start point.
There is another post about non syncing threads with speed changes.
In linuxcnc, you can't change the spindle speed and track the same thread, the sync point moves.
Linuxcnc moves the axis as fast as possible till it is moving at the approximate correct 'pitch' speed. It then works to get the exact pitch and maintain it. This distance to get up to speed is kept track of for use of calculating position and position error.
IIRC linuxcnc allows 10 rotations past target before deciding there is an error.
There is another post about non syncing threads with speed changes.
In linuxcnc, you can't change the spindle speed and track the same thread, the sync point moves.
Linuxcnc moves the axis as fast as possible till it is moving at the approximate correct 'pitch' speed. It then works to get the exact pitch and maintain it. This distance to get up to speed is kept track of for use of calculating position and position error.
IIRC linuxcnc allows 10 rotations past target before deciding there is an error.
The following user(s) said Thank You: spumco
Please Log in or Create an account to join the conversation.
- cmorley
- Offline
- Moderator
-
Less
More
- Posts: 7786
- Thank you received: 2077
25 Jan 2025 00:52 #319797
by cmorley
Replied by cmorley on topic G33.1 synchronized tapping problem
The other thread:
forum.linuxcnc.org/38-general-linuxcnc-q...s-with-speed?start=0
forum.linuxcnc.org/38-general-linuxcnc-q...s-with-speed?start=0
Please Log in or Create an account to join the conversation.
- spumco
- Offline
- Platinum Member
-
Less
More
- Posts: 1872
- Thank you received: 749
25 Jan 2025 01:30 #319798
by spumco
I understand that LCNC needs a short period/distance of max accel to go from zero speed to synch speed - the other thread has a code snippet which explicitly states this in a comment.
What I don't get is why LCNC is moving so far to get up to speed. My lathe has pretty aggressive acceleration - it can reach max speed in a very short distance.
But it's moving over an inch at rapid speed to get to the synch point at only 200rpm with a 0.05" thread pitch. Feedrate at that spindle rpm and pitch is really slow - like 4ipm or so.
I guess what I'm seeing is identical behavior from the other thread... but much worse start point variation.
Replied by spumco on topic G33.1 synchronized tapping problem
Thanks for giving this some thought Chris.I would expect speed changes to change the sync start point.
There is another post about non syncing threads with speed changes.
In linuxcnc, you can't change the spindle speed and track the same thread, the sync point moves.
Linuxcnc moves the axis as fast as possible till it is moving at the approximate correct 'pitch' speed. It then works to get the exact pitch and maintain it. This distance to get up to speed is kept track of for use of calculating position and position error.
IIRC linuxcnc allows 10 rotations past target before deciding there is an error.
I understand that LCNC needs a short period/distance of max accel to go from zero speed to synch speed - the other thread has a code snippet which explicitly states this in a comment.
What I don't get is why LCNC is moving so far to get up to speed. My lathe has pretty aggressive acceleration - it can reach max speed in a very short distance.
But it's moving over an inch at rapid speed to get to the synch point at only 200rpm with a 0.05" thread pitch. Feedrate at that spindle rpm and pitch is really slow - like 4ipm or so.
I guess what I'm seeing is identical behavior from the other thread... but much worse start point variation.
Please Log in or Create an account to join the conversation.
- cmorley
- Offline
- Moderator
-
Less
More
- Posts: 7786
- Thank you received: 2077
25 Jan 2025 20:34 #319845
by cmorley
Replied by cmorley on topic G33.1 synchronized tapping problem
Do you get the same if you use a program rather then MDI?
The following user(s) said Thank You: spumco
Please Log in or Create an account to join the conversation.
Time to create page: 0.086 seconds