Threading Index Varies With Speed
- 10K
-
Topic Author
- Offline
- Premium Member
-
Less
More
- Posts: 142
- Thank you received: 32
31 Dec 2024 20:35 #317732
by 10K
Replied by 10K on topic Threading Index Varies With Speed
Yes, 200 RPM
Please Log in or Create an account to join the conversation.
- PCW
-
- Offline
- Moderator
-
Less
More
- Posts: 18491
- Thank you received: 5060
31 Dec 2024 21:26 #317735
by PCW
Replied by PCW on topic Threading Index Varies With Speed
So I wonder why it is working now?
Please Log in or Create an account to join the conversation.
- cmorley
- Offline
- Moderator
-
Less
More
- Posts: 7882
- Thank you received: 2131
01 Jan 2025 03:03 #317754
by cmorley
Looks to me it just syncs velocity (units per minute) at first,
then yes uses spindle revolutions times units per rev feedrate to calculate the axis target position.
Am I right in thinking tp->spindle_offset is used to account for the acceleration distance and that would be different for different speed spindles?
Replied by cmorley on topic Threading Index Varies With Speed
/**
* Run position mode synchronization.
* Updates requested velocity for a trajectory segment to track the spindle's position.
*/
STATIC void tpSyncPositionMode(TP_STRUCT * const tp, TC_STRUCT * const tc,
TC_STRUCT * const nexttc ) {
double spindle_pos = tpGetSignedSpindlePosition(&emcmotStatus->spindle_status[tp->spindle.spindle_num]);
tp_debug_print("Spindle at %f\n",spindle_pos);
double spindle_vel, target_vel;
double oldrevs = tp->spindle.revs;
if ((tc->motion_type == TC_RIGIDTAP) && (tc->coords.rigidtap.state == RETRACTION ||
tc->coords.rigidtap.state == FINAL_REVERSAL)) {
tp->spindle.revs = tc->coords.rigidtap.spindlerevs_at_reversal -
spindle_pos;
} else {
tp->spindle.revs = spindle_pos;
}
double pos_desired = (tp->spindle.revs - tp->spindle.offset) * tc->uu_per_rev;
double pos_error = pos_desired - tc->progress;
if(nexttc) {
pos_error -= nexttc->progress;
}
if(tc->sync_accel) {
// detect when velocities match, and move the target accordingly.
// acceleration will abruptly stop and we will be on our new target.
// FIX: this is driven by TP cycle time, not the segment cycle time
double dt = fmax(tp->cycleTime, TP_TIME_EPSILON);
spindle_vel = tp->spindle.revs / ( dt * tc->sync_accel++);
target_vel = spindle_vel * tc->uu_per_rev;
if(tc->currentvel >= target_vel) {
tc_debug_print("Hit accel target in pos sync\n");
// move target so as to drive pos_error to 0 next cycle
tp->spindle.offset = tp->spindle.revs - tc->progress / tc->uu_per_rev;
tc->sync_accel = 0;
tc->target_vel = target_vel;
} else {
tc_debug_print("accelerating in pos_sync\n");
// beginning of move and we are behind: accel as fast as we can
tc->target_vel = tc->maxvel;
}
} else {
// we have synced the beginning of the move as best we can -
// track position (minimize pos_error).
tc_debug_print("tracking in pos_sync\n");
double errorvel;
spindle_vel = (tp->spindle.revs - oldrevs) / tp->cycleTime;
target_vel = spindle_vel * tc->uu_per_rev;
errorvel = pmSqrt(fabs(pos_error) * tcGetTangentialMaxAccel(tc));
if(pos_error<0) {
errorvel *= -1.0;
}
tc->target_vel = target_vel + errorvel;
}
//Finally, clip requested velocity at zero
if (tc->target_vel < 0.0) {
tc->target_vel = 0.0;
}
if (nexttc && nexttc->synchronized) {
//If the next move is synchronized too, then match it's
//requested velocity to the current move
nexttc->target_vel = tc->target_vel;
}
}
Looks to me it just syncs velocity (units per minute) at first,
then yes uses spindle revolutions times units per rev feedrate to calculate the axis target position.
Am I right in thinking tp->spindle_offset is used to account for the acceleration distance and that would be different for different speed spindles?
Please Log in or Create an account to join the conversation.
- PCW
-
- Offline
- Moderator
-
Less
More
- Posts: 18491
- Thank you received: 5060
01 Jan 2025 04:56 - 01 Jan 2025 05:07 #317759
by PCW
Replied by PCW on topic Threading Index Varies With Speed
Unless I misunderstand, It does look like that which is a bit crazy.
It should chase the desired position basically with a PID
+FF1 loop and without any position offset. Of course bounded by the
joint maxaccel/maxvel constraints.
The current way it's done may be a compromise to minimize sync time.
Ideally. I think you want to move in such a way that you end up synchronizing
the position and velocity at the same time.
It should chase the desired position basically with a PID
+FF1 loop and without any position offset. Of course bounded by the
joint maxaccel/maxvel constraints.
The current way it's done may be a compromise to minimize sync time.
Ideally. I think you want to move in such a way that you end up synchronizing
the position and velocity at the same time.
Last edit: 01 Jan 2025 05:07 by PCW.
Please Log in or Create an account to join the conversation.
- radom
- Offline
- Senior Member
-
Less
More
- Posts: 60
- Thank you received: 7
01 Jan 2025 10:17 - 01 Jan 2025 10:47 #317765
by radom
Replied by radom on topic Threading Index Varies With Speed
last time I tried to fix existing thread I set rpm to 0 and turned lathe chuck by hand to line up the threading tool and it looked good but when I run the program it just mangled the thread but I though I messed up something
so today I did the test with 100, 200rpm 266 and 300 and none of them line up with each other
this is so funny to me, it's just like stupid fanuc
my lathe is analog servo motors
photo with 100 nad 200rpm
so today I did the test with 100, 200rpm 266 and 300 and none of them line up with each other
this is so funny to me, it's just like stupid fanuc
my lathe is analog servo motors
photo with 100 nad 200rpm
Attachments:
Last edit: 01 Jan 2025 10:47 by radom.
The following user(s) said Thank You: 10K
Please Log in or Create an account to join the conversation.
- 10K
-
Topic Author
- Offline
- Premium Member
-
Less
More
- Posts: 142
- Thank you received: 32
01 Jan 2025 15:27 #317780
by 10K
Replied by 10K on topic Threading Index Varies With Speed
I ran a couple of tests this morning to see if I could figure out why the velocity started working OK. These two scope captures are both at 200 RPM, running the same threading program. It shows me that 10 teeth is not adequate for some operations, and that I should modify the spindle with a new gear with more teeth. I'm thinking I'll do 180 teeth/rev. It'll take me a while to make the modifications.
I don't expect this to fix the original problem of threads not aligning at different speeds, but it should fix the slightly varying thread pitch..
HAL using: net spindle-position encoder.0.position => spindle.0.revs
HAL using: net spindle-position encoder.0.position-interpolated => spindle.0.revs
I don't expect this to fix the original problem of threads not aligning at different speeds, but it should fix the slightly varying thread pitch..
HAL using: net spindle-position encoder.0.position => spindle.0.revs
HAL using: net spindle-position encoder.0.position-interpolated => spindle.0.revs
Attachments:
Please Log in or Create an account to join the conversation.
- PCW
-
- Offline
- Moderator
-
Less
More
- Posts: 18491
- Thank you received: 5060
01 Jan 2025 16:23 #317783
by PCW
Replied by PCW on topic Threading Index Varies With Speed
It does look like using the non-interpolated position
(perhaps because of the low resolution)
triggers some kind of bug with the tracking.
Its a bit disappointing that LinuxCNC does not cut the same
thread at different speeds, that really does seem like a bug.
(and a bit unexpected since mechanical threading doesn't have this issue)
(perhaps because of the low resolution)
triggers some kind of bug with the tracking.
Its a bit disappointing that LinuxCNC does not cut the same
thread at different speeds, that really does seem like a bug.
(and a bit unexpected since mechanical threading doesn't have this issue)
Please Log in or Create an account to join the conversation.
- radom
- Offline
- Senior Member
-
Less
More
- Posts: 60
- Thank you received: 7
03 Jan 2025 11:59 #317919
by radom
Replied by radom on topic Threading Index Varies With Speed
will that get somewhere marked as a bug/something to improve in the future or will be forgotten in a week's time?
Please Log in or Create an account to join the conversation.
- spumco
- Offline
- Platinum Member
-
Less
More
- Posts: 1942
- Thank you received: 780
03 Jan 2025 14:50 #317931
by spumco
My inexpert opinion is that a thread start point that varies with spindle speed is a bug - not expected behavior - at least according to the user manual:
G76:G33:
So according to the the user manual author(s)' expectation, the start point should be a calculated position with compensation for spindle speed and axis accel/maxvel values.
I did find that the section of trajectory planner file (tp.c) Chris posted earlier was edited a few times in 2009. I've no idea whether the change(s) have any affect on the situation at hand.
I see that there is an open Issue on GH - 8 years old? - that may have something to do with this, as well as some more recent (possible) resolutions:
github.com/LinuxCNC/linuxcnc/issues/167
github.com/LinuxCNC/linuxcnc/pull/479
github.com/LinuxCNC/linuxcnc/pull/581/commits
I can't tell if #581 fixed, broke, or had nothing to do with spindle synch/threading start point calcs.
I think more testing is in order.
First, I'd like to see if G33 behaves the same as G76 does.
Second, I'd like to see if the thread start point varies by a predictable amount depending on
I'm sure some of the folks reading this can review files like tp.c and understand the behavior, but I can't. What I can do is poke around and see if something obvious crops us.
I've got a fairly high-res encoder on my project lathe, as well as fairly 'dynamic' Z-axis accel. I'll try to run some basic G76 and G33 tests this weekend and report back whatever I find. Maybe with a high enough encoder res and accel values, this is a non-issue... and below some set of values the underlying problem makes a (negatively) meaningful difference in threading results.
Replied by spumco on topic Threading Index Varies With Speed
I'm interested, and despite my utter lack of programming knowledge I've been poking around on github looking for anything obvious.will that get somewhere marked as a bug/something to improve in the future or will be forgotten in a week's time?
My inexpert opinion is that a thread start point that varies with spindle speed is a bug - not expected behavior - at least according to the user manual:
G76:
The G76 canned cycle is based on the G33 Spindle Synchronized Motion. For more information see the G33 [url=https://linuxcnc.org/docs/devel/html/gcode/g-code.html#gcode:g33-tech-info]Technical Info[/url].
Technical InfoAt the beginning of each G33 pass, LinuxCNC uses the spindle speed and the machine acceleration limits to calculate how long it will take Z to accelerate after the index pulse, and determines how many degrees the spindle will rotate during that time. It then adds that angle to the index position and computes the Z position using the corrected spindle angle. That means that Z will reach the correct position just as it finishes accelerating to the proper speed, and can immediately begin cutting a good thread.
So according to the the user manual author(s)' expectation, the start point should be a calculated position with compensation for spindle speed and axis accel/maxvel values.
I did find that the section of trajectory planner file (tp.c) Chris posted earlier was edited a few times in 2009. I've no idea whether the change(s) have any affect on the situation at hand.
I see that there is an open Issue on GH - 8 years old? - that may have something to do with this, as well as some more recent (possible) resolutions:
github.com/LinuxCNC/linuxcnc/issues/167
github.com/LinuxCNC/linuxcnc/pull/479
github.com/LinuxCNC/linuxcnc/pull/581/commits
I can't tell if #581 fixed, broke, or had nothing to do with spindle synch/threading start point calcs.
I think more testing is in order.
First, I'd like to see if G33 behaves the same as G76 does.
Second, I'd like to see if the thread start point varies by a predictable amount depending on
- spindle speed
- encoder resolution
- axis max accel
- thread pitch
I'm sure some of the folks reading this can review files like tp.c and understand the behavior, but I can't. What I can do is poke around and see if something obvious crops us.
I've got a fairly high-res encoder on my project lathe, as well as fairly 'dynamic' Z-axis accel. I'll try to run some basic G76 and G33 tests this weekend and report back whatever I find. Maybe with a high enough encoder res and accel values, this is a non-issue... and below some set of values the underlying problem makes a (negatively) meaningful difference in threading results.
Please Log in or Create an account to join the conversation.
- spumco
- Offline
- Platinum Member
-
Less
More
- Posts: 1942
- Thank you received: 780
03 Jan 2025 15:09 #317932
by spumco
Replied by spumco on topic Threading Index Varies With Speed
I'm getting the feeling that Rob Ellenberg's spindle synch updates/re-writes were never incorporated in to LCNC mainstream.
www.mail-archive.com/emc-developers@list...ge.net/msg16956.html
www.mail-archive.com/emc-developers@list...ge.net/msg16956.html
Please Log in or Create an account to join the conversation.
Time to create page: 0.140 seconds