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)

will that get somewhere marked as a bug/something to improve in the future or will be forgotten in a week's time?

radom wrote:

will that get somewhere marked as a bug/something to improve in the future or will be forgotten in a week's time?

I'm interested, and despite my utter lack of programming knowledge I've been poking around on github looking for anything obvious.

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

• spindle speed
• encoder resolution
• axis max accel
• thread pitch

If the offset is predictable, that suggests to me that position math is being done... but some programming is wrong.  If the offset is not predictable,  then my guess is that position is not being calculated per the G33 user manual section.

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.
 

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

 

As far as I understand it, ideally there should be no offset.
The offset is there because the algorithm only matches velocity
and does not do the calculations needed to match velocity
_and_ correct position.

After pulling my hair out trying to figure out why G33.1 wasn't working on my lathe while attempting to test the problem raised in this thread, @cmorely pointed out I'm having the same issue.

forum.linuxcnc.org/38-general-linuxcnc-q...pping-problem#319786

So I can confirm spindle synchronization start points vary with spindle speed in G33.1 as well as G76 - and it's way worse on my lathe than the OP reported on his.

In my case a difference of 140rpm (60 vs 200) resulted in appx 0.750" difference between the Z-start point when synchronization kicked in on a 1/20 pitch (0.050").

According the the formula Andy posted earlier, my Z-axis requires the following distance to get up to speed

 

I don't understand why there is such a significant difference between what I'm seeing and what the OP's lathe is doing.

Unless somone has other thoughts, I think this is a bug.