Re: [Emc-users] Spindle speed changes with threading.

[Les Newell]

Hi John,

The encoder is 4096 counts/rev. Using Mesa Ethernet hardware with servos 
so no BASE_PERIOD. SERVO_PERIOD is the default 1ms.


I've never had a problem cutting threads in normal use. Even when taking 
multiple tries to dial in a thread it always tracks perfectly.


Les

On 05/02/2021 17:18, John Dammeyer wrote:

Thanks Les.  That's good to know.  What's the resolution of your spindle 
encoder? How are you detecting this with LinuxCNC?  A MESA card or PP?  What's 
the BASE_PERIOD and the SERVO_PERIOD set in the INI file?

Thanks
John


-Original Message-
From: Les Newell [mailto:les.new...@fastmail.co.uk]
Sent: February-05-21 8:07 AM
To: emc-users@lists.sourceforge.net
Subject: Re: [Emc-users] Spindle speed changes with threading.

I just tried it on my lathe. I scratch cut a coarse pitch thread at low
spindle speed then repeated the cut at about twice the spindle speed. I
ended up with two distinct threads. The moral of the story is to make
sure your spindle speed is stable before starting threading.

Les




___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users



___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users





___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Spindle speed changes with threading.

[Jon Elson]

On 02/05/2021 01:35 PM, Gene Heskett wrote:

On Friday 05 February 2021 13:53:44 Jon Elson wrote:


On 02/05/2021 10:07 AM, Gene Heskett wrote:

You have my curiosity bump itching Jon, When I get my stuff back
together on the GO704, and get my new 'scope unpacked, I'll take a
look at the step drive output and answer that itch.

You actually should be able to check this out with
Halscope.  Look at the velocity or step rate
for the Z axis, and trigger on spindle.0.index-enable or
whatever it is called on your LinuxCNC version.If what I
said was right, velocity should go higher than the required
Z feedrate for
a moment right after the spindle encoder gets the index
pulse, and then settle down to the required feedrate for
that thread pitch.

Love that rigid tapping!  I just did 160 holes, with a spot
drilling step, then a drill through step, and finally
tapping some 6-32 and 2-56 holes.  It is kind of scary
watching a 6-32 tap plunge in at
1000 RPM and 32 IPM feedrate.  Taps the hole in barely a second!


So do I Jon, but I've been aiming to ask you what you do about the
overshoot at turnaround time at 1000 rpms on that bridgeport?

It is about 1-2 turns running at 1000 RPM.  This is a 
standard US Motors 1 Hp Bridgeport spindle motor on a 1J 
head (step pulley).  It is powered by a 1 Hp Magnetek VFD.  
I leave the belt on the highest spindle speed and run the 
motor at around 21 Hz for 1000 RPM at the spindle.  So, I 
just compensate for the overshoot, knowing how many turns it 
goes past and the thread pitch.


Jon


___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Spindle speed changes with threading.

[Jon Elson]

On 02/05/2021 01:11 PM, johnd wrote:

What's the resolution of your spindle encoder and base period servo period?
There is no base thread on this servo system.  The servo 
thread runs at 1 KHz.


The spindle encoder uses the bull gear in the mill's head, 
so it has 324 counts/rev.


Jon


___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Spindle speed changes with threading.

[John Dammeyer]

Boy my Samsung phone doesn't format messages very well for this group.

OK.  So I'll ask again.  If you'd done tapping or threading with LinuxCNC:
1. What resolution encoder are you using?
2. What is the BASIC_PERIOD?
3. What is the SERVO_PERIOD?

Thanks
John Dammeyer




___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Spindle speed changes with threading.

[Gene Heskett]

On Friday 05 February 2021 13:53:44 Jon Elson wrote:

> On 02/05/2021 10:07 AM, Gene Heskett wrote:
> > You have my curiosity bump itching Jon, When I get my stuff back
> > together on the GO704, and get my new 'scope unpacked, I'll take a
> > look at the step drive output and answer that itch.
>
> You actually should be able to check this out with
> Halscope.  Look at the velocity or step rate
> for the Z axis, and trigger on spindle.0.index-enable or
> whatever it is called on your LinuxCNC version.If what I
> said was right, velocity should go higher than the required
> Z feedrate for
> a moment right after the spindle encoder gets the index
> pulse, and then settle down to the required feedrate for
> that thread pitch.
>
> Love that rigid tapping!  I just did 160 holes, with a spot
> drilling step, then a drill through step, and finally
> tapping some 6-32 and 2-56 holes.  It is kind of scary
> watching a 6-32 tap plunge in at
> 1000 RPM and 32 IPM feedrate.  Taps the hole in barely a second!
>
So do I Jon, but I've been aiming to ask you what you do about the 
overshoot at turnaround time at 1000 rpms on that bridgeport?

> Jon
>
>
> ___
> Emc-users mailing list
> Emc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-users


Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page 


___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Spindle speed changes with threading.

[johnd]

What's the resolution of your spindle encoder and base period servo period?Sent 
from my Samsung S10
 Original message From: Jon Elson  
Date: 2021-02-05  10:56 a.m.  (GMT-08:00) To: "Enhanced Machine Controller 
(EMC)"  Subject: Re: [Emc-users] Spindle speed 
changes with threading. On 02/05/2021 10:07 AM, Gene Heskett wrote:>> You have 
my curiosity bump itching Jon, When I get my stuff back together> on the GO704, 
and get my new 'scope unpacked, I'll take a look at the> step drive output and 
answer that itch.You actually should be able to check this out with Halscope.  
Look at the velocity or step ratefor the Z axis, and trigger on 
spindle.0.index-enable or whatever it is called on your LinuxCNC version.    If 
what I said was right, velocity should go higher than the required Z feedrate 
fora moment right after the spindle encoder gets the index pulse, and then 
settle down to the required feedrate for that thread pitch.Love that rigid 
tapping!  I just did 160 holes, with a spot drilling step, then a drill through 
step, and finally tapping some 6-32 and 2-56 holes.  It is kind of scary 
watching a 6-32 tap plunge in at1000 RPM and 32 IPM feedrate.  Taps the hole in 
barely a second!Jon___Emc-users 
mailing 
listEmc-users@lists.sourceforge.nethttps://lists.sourceforge.net/lists/listinfo/emc-users
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Spindle speed changes with threading.

[Jon Elson]

On 02/05/2021 11:03 AM, John Dammeyer wrote:

Hi Gene,
But it's also been reported that with LinuxCNC it's possible to stop the 
spindle while still in Threading Mode and then turn the spindle by hand and the 
carriage will follow.  This is of course on a lathe.  Not something you'd do on 
a mill I think.


I did this YEARS ago when testing out the first versions 
that supported rigid tapping and lathe threading.  Of 
course, it might not create the most perfect threads, but it 
did seem to reliably follow the thread that was cut before.


If you get multiple threads when making multiple passes, it 
may indicate the spindle index has noise on it.  If it ever 
gets a pulse at a different spindle angle, you will have 
this issue, and it has nothing to do with speed.


Now, at least on older versions of LinuxCNC (and EMC2) it 
was customary to run the trajectory planner at some 
sub-multiple of the servo thread rate.  Since the T.P. does 
the spindle synch, that would cause the Z position to lag 
the spindle.  So, you want to make sure the T.P. is running 
at the

full servo thread frequency.

Jon




___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Spindle speed changes with threading.

[Jon Elson]

On 02/05/2021 10:07 AM, Gene Heskett wrote:


You have my curiosity bump itching Jon, When I get my stuff back together
on the GO704, and get my new 'scope unpacked, I'll take a look at the
step drive output and answer that itch.
You actually should be able to check this out with 
Halscope.  Look at the velocity or step rate
for the Z axis, and trigger on spindle.0.index-enable or 
whatever it is called on your LinuxCNC version.If what I 
said was right, velocity should go higher than the required 
Z feedrate for
a moment right after the spindle encoder gets the index 
pulse, and then settle down to the required feedrate for 
that thread pitch.


Love that rigid tapping!  I just did 160 holes, with a spot 
drilling step, then a drill through step, and finally 
tapping some 6-32 and 2-56 holes.  It is kind of scary 
watching a 6-32 tap plunge in at

1000 RPM and 32 IPM feedrate.  Taps the hole in barely a second!

Jon


___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Spindle speed changes with threading.

[Gene Heskett]

On Friday 05 February 2021 12:03:48 John Dammeyer wrote:

> Hi Gene,
> But it's also been reported that with LinuxCNC it's possible to stop
> the spindle while still in Threading Mode and then turn the spindle by
> hand and the carriage will follow.  This is of course on a lathe.  Not
> something you'd do on a mill I think.

I have done in on the mill too, by killinig the spindles psu. it then 
follows the hand turn in either direction.

> The question then becomes what is the minimum number of encoder edges
> required to do this without mucking up a thread.  A 60 Tooth encoder
> gives 240 edges which is still 1.5 degrees.  On a 1" shaft being
> turned to say 8 TPI with an 8 TPI leadscrew the circumference is 3.14"
> or 0.0087222..." per degree or 0.01308333..." per 1.5 degrees.  So if
> the spindle stops on an edge and then is further rotated by hand
> manually for 1.5 degrees the carriage will lag by 0.013" or so before
> the system realizes it needs to move.
>
> My understanding of carbide tooling is that's enough to break the tip.

Possibly, probably so, but I have not done the above test while actually 
cutting. Carbide costs too much.

> But if the encoder is 10x that with 2400 lines then at 600 RPM (for
> example) we get an encoder edge every 42 uS or so and we've move 0.15
> degrees or and 0.001308...".  At this point probably not an issue
> for carbide and as long as the carriage can track that it's not a
> problem.  And as long as the system can respond to that encoder change
> fast enough.
>
> See the issue?

Another point to consider is, in the g33.1 case, doesn't apply in the G76 
case since the tool is backed away before the reversa begings, is the 
turnarond accompanied by a prior backlash comp move? I don't recall 
anyone saying in the past. In which case my turnaround programming might 
cover the backlash move time. As I said before with the new scope I 
should be able to trace that. In that event motion would need a spindle 
stopped input so it would have the knowledge to do its own reversal 
programming. To be really effective, this has to be done in sequence. I 
cannot just send the reverse on thru from motion without dropping a 20 
amp breaker in the service. BTDT, bunches of times. I think I can cobble 
up a 20 ms time gap to allow the backlash time to get that move 
completed before unleashing the actual backup value to the pwmgen. But 
it will have to be sequenced or I'll trip the service breaker.

Stay well and safe, John

[...]

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page 


___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Spindle speed changes with threading.

[John Dammeyer]

Thanks Les.  That's good to know.  What's the resolution of your spindle 
encoder? How are you detecting this with LinuxCNC?  A MESA card or PP?  What's 
the BASE_PERIOD and the SERVO_PERIOD set in the INI file?

Thanks
John

> -Original Message-
> From: Les Newell [mailto:les.new...@fastmail.co.uk]
> Sent: February-05-21 8:07 AM
> To: emc-users@lists.sourceforge.net
> Subject: Re: [Emc-users] Spindle speed changes with threading.
> 
> I just tried it on my lathe. I scratch cut a coarse pitch thread at low
> spindle speed then repeated the cut at about twice the spindle speed. I
> ended up with two distinct threads. The moral of the story is to make
> sure your spindle speed is stable before starting threading.
> 
> Les
> 
> 
> 
> 
> ___
> Emc-users mailing list
> Emc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-users



___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Spindle speed changes with threading.

[John Dammeyer]

> From: Jon Elson [mailto:el...@pico-systems.com]
> On 02/05/2021 03:15 AM, Gene Heskett wrote:
> > On Friday 05 February 2021 02:57:38 John Dammeyer wrote:
> >
> >> Granted this subject is a bit old I've now had some time to dive back
> >> into the TI F2837xD which has dual processors and other features that
> >> will make it a good test bed for trying out stuff.
> >>
> >> It has a hardware Quadrature Encoder Interface (QEI) so theoretically
> >> I should be able to grab encoder counts in any resolution and
> >> calculate spindle position relative to Z axis position and create
> >> moves to track.
> >>
> >> I'll report back when I have some more information.
> >> John
> >>
> > As has been told to me, its the time delay between starting the z on the
> > passing index, until z has reached the synchronous speed and is then
> > locked at whatever phase exists when sync speed has been achieved
> No, I'm pretty sure this is not correct.  The Z is locked to
> the spindle position when the index pulse was detected.
> This requires the Z to accelerate PAST the required speed to
> follow the thread for a moment, and that's why you want to
> cut air for a bit before the tap enters the workpiece.  It
> is also why you need to leave substantial headroom on the Z
> speed to match the tapping velocity.
> 
> Jon

Just accelerating up to speed does work.  One doesn't have to go past the speed 
to catch up to a position.  As Andy stated to cut multi-start threads you then 
just move the BEGIN position further away by the pitch/starts.   So a two start 
thread on a 0.1" pitch is moved 0.05" and then the threading cycle is 
restarted.  Since acceleration up to the spindle speed is constant as long as 
the spindle speed is the same the tool enters the new thread 180 degrees from 
the first.

However, if the goal of LinuxCNC is to track spindle position from the index 
pulse then indeed it will have to accelerate past the threading speed to catch 
up to the threading position.This too will also work with multi-start 
threading.  The difference is the second thread can now be cut at a different 
RPM because the task of the Trajectory planner is to have the tool enter the 
work at the same position relative to the index pulse regardless of the spindle 
speed.

That approach is especially handy if for some reason the work was taken out of 
a chuck and then had to be re-inserted to chase a damaged thread.  Now one 
could turn the spindle by hand in threading mode and 'tweak' the start position 
until the tool bit entered the existing thread without issue.

Or feed hold the threading midway with the X axis outside the thread and then 
move X in while loosening the chuck and aligning the existing thread with the 
edges of the cutting tool.  In either case, the ability to turn the chuck by 
hand for threading is useful for repair.  For normal threading who cares...

John Dammeyer




___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Spindle speed changes with threading.

[John Dammeyer]

Hi Gene,
But it's also been reported that with LinuxCNC it's possible to stop the 
spindle while still in Threading Mode and then turn the spindle by hand and the 
carriage will follow.  This is of course on a lathe.  Not something you'd do on 
a mill I think.  

The question then becomes what is the minimum number of encoder edges required 
to do this without mucking up a thread.  A 60 Tooth encoder gives 240 edges 
which is still 1.5 degrees.  On a 1" shaft being turned to say 8 TPI with an 8 
TPI leadscrew the circumference is 3.14" or 0.0087222..." per degree or 
0.01308333..." per 1.5 degrees.  So if the spindle stops on an edge and then is 
further rotated by hand manually for 1.5 degrees the carriage will lag by 
0.013" or so before the system realizes it needs to move. 

My understanding of carbide tooling is that's enough to break the tip.

But if the encoder is 10x that with 2400 lines then at 600 RPM (for example) we 
get an encoder edge every 42 uS or so and we've move 0.15 degrees or and 
0.001308...".  At this point probably not an issue for carbide and as long 
as the carriage can track that it's not a problem.  And as long as the system 
can respond to that encoder change fast enough.

See the issue?
John

> -Original Message-
> From: Gene Heskett [mailto:ghesk...@shentel.net]
> Sent: February-05-21 1:16 AM
> To: emc-users@lists.sourceforge.net
> Subject: Re: [Emc-users] Spindle speed changes with threading.
> 
> On Friday 05 February 2021 02:57:38 John Dammeyer wrote:
> 
> > Granted this subject is a bit old I've now had some time to dive back
> > into the TI F2837xD which has dual processors and other features that
> > will make it a good test bed for trying out stuff.
> >
> > It has a hardware Quadrature Encoder Interface (QEI) so theoretically
> > I should be able to grab encoder counts in any resolution and
> > calculate spindle position relative to Z axis position and create
> > moves to track.
> >
> > I'll report back when I have some more information.
> > John
> >
> As has been told to me, its the time delay between starting the z on the
> passing index, until z has reached the synchronous speed and is then
> locked at whatever phase exists when sync speed has been achieved, This
> is done anew for every stroke of a G76 or a G33.1.  Changing the spindle
> speed after such a cut has started, changes this delay, therefore the z
> position during the instant stroke as this synching is done fresh for
> each stroke of a G76 or a pecked G33.1.
> 
> The effect is that of changing the lateral position of the thread, with
> of course a bad thread being the result. The raised speed slides the
> thread to the left since it increases the delay because it has to reach
> a higher speed to get synced which takes longer. So the only way to
> reduce this effect is to lower the MAX_VEL and increase the MAX_ACCEL,
> and in some cases slow the spindle. This was the case with the original
> 1600 oz/in z motor on my G0704, which could only do 29 ipm. A 940 oz/in
> motor can do 90 some, which helps some.   As long as z can keep up, this
> delay won't change by more than an edge spacing from the encoder. Change
> the spindle speed and you change the locked z to spindle phase.
> 
> I think some of my sloppy rigid threading on the G0704, is not at the top
> of the stroke, but at the bottom turnaround and back out, due to the
> spindle reversal being too quick for z to follow.  Since that turnaround
> is a programmed turnaround in my hal file, I should try slowing the
> decel/accel as the z can't keep up. But I keep forgetting to run that
> experiment.:(
> 
> As its currently set, it can do a 3000 rpm turnaround in about 350
> milliseconds. Lots quicker at the 300-500 revs I normally tap at. But if
> I slow that turnaround down, that will increase the overshoot at the
> bottom,  Dangerous to the tap in a blind hole.
> 
> And that could cause a change in the phase lock while backing out, making
> the tap cut sloppy on the up, backout stroke.
> 
> Stay well and safe John.
> 
> Cheers, Gene Heskett
> --
> "There are four boxes to be used in defense of liberty:
>  soap, ballot, jury, and ammo. Please use in that order."
> -Ed Howdershelt (Author)
> If we desire respect for the law, we must first make the law respectable.
>  - Louis D. Brandeis
> Genes Web page <http://geneslinuxbox.net:6309/gene>
> 
> 
> ___
> Emc-users mailing list
> Emc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-users



___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Spindle speed changes with threading.

[Les Newell]

I just tried it on my lathe. I scratch cut a coarse pitch thread at low 
spindle speed then repeated the cut at about twice the spindle speed. I 
ended up with two distinct threads. The moral of the story is to make 
sure your spindle speed is stable before starting threading.


Les




___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Spindle speed changes with threading.

[Gene Heskett]

On Friday 05 February 2021 10:27:30 Jon Elson wrote:

> On 02/05/2021 03:15 AM, Gene Heskett wrote:
> > On Friday 05 February 2021 02:57:38 John Dammeyer wrote:
> >> Granted this subject is a bit old I've now had some time to dive
> >> back into the TI F2837xD which has dual processors and other
> >> features that will make it a good test bed for trying out stuff.
> >>
> >> It has a hardware Quadrature Encoder Interface (QEI) so
> >> theoretically I should be able to grab encoder counts in any
> >> resolution and calculate spindle position relative to Z axis
> >> position and create moves to track.
> >>
> >> I'll report back when I have some more information.
> >> John
> >
> > As has been told to me, its the time delay between starting the z on
> > the passing index, until z has reached the synchronous speed and is
> > then locked at whatever phase exists when sync speed has been
> > achieved
>
> No, I'm pretty sure this is not correct.  The Z is locked to
> the spindle position when the index pulse was detected.
> This requires the Z to accelerate PAST the required speed to
> follow the thread for a moment, and that's why you want to
> cut air for a bit before the tap enters the workpiece.  It
> is also why you need to leave substantial headroom on the Z
> speed to match the tapping velocity.
>
> Jon

You have my curiosity bump itching Jon, When I get my stuff back together 
on the GO704, and get my new 'scope unpacked, I'll take a look at the 
step drive output and answer that itch. I just bought a $3200 10.5" 
display Siglint 4 channel scope. Its at a DHS warehouse/terminal in 
Cleveland or Cinci ATM. Promised by Teusday next.

I'm in the middle of getting my machines all running from the same model 
of dell computer, carrying a 4 core i5 at 1600 MHZ, I bought 4 of them 
off lease for $150/copy, and have some kin in the house helping clean up 
after my wifes passing.  So it may be a week or more.

Stay safe and well.

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page 


___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Spindle speed changes with threading.

[Jon Elson]

On 02/05/2021 03:15 AM, Gene Heskett wrote:

On Friday 05 February 2021 02:57:38 John Dammeyer wrote:


Granted this subject is a bit old I've now had some time to dive back
into the TI F2837xD which has dual processors and other features that
will make it a good test bed for trying out stuff.

It has a hardware Quadrature Encoder Interface (QEI) so theoretically
I should be able to grab encoder counts in any resolution and
calculate spindle position relative to Z axis position and create
moves to track.

I'll report back when I have some more information.
John


As has been told to me, its the time delay between starting the z on the
passing index, until z has reached the synchronous speed and is then
locked at whatever phase exists when sync speed has been achieved
No, I'm pretty sure this is not correct.  The Z is locked to 
the spindle position when the index pulse was detected.  
This requires the Z to accelerate PAST the required speed to 
follow the thread for a moment, and that's why you want to 
cut air for a bit before the tap enters the workpiece.  It 
is also why you need to leave substantial headroom on the Z 
speed to match the tapping velocity.


Jon

Jon


___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Spindle speed changes with threading.

[Gene Heskett]

On Friday 05 February 2021 02:57:38 John Dammeyer wrote:

> Granted this subject is a bit old I've now had some time to dive back
> into the TI F2837xD which has dual processors and other features that
> will make it a good test bed for trying out stuff.
>
> It has a hardware Quadrature Encoder Interface (QEI) so theoretically
> I should be able to grab encoder counts in any resolution and
> calculate spindle position relative to Z axis position and create
> moves to track.
>
> I'll report back when I have some more information.
> John
>
As has been told to me, its the time delay between starting the z on the 
passing index, until z has reached the synchronous speed and is then 
locked at whatever phase exists when sync speed has been achieved, This 
is done anew for every stroke of a G76 or a G33.1.  Changing the spindle 
speed after such a cut has started, changes this delay, therefore the z 
position during the instant stroke as this synching is done fresh for 
each stroke of a G76 or a pecked G33.1.

The effect is that of changing the lateral position of the thread, with 
of course a bad thread being the result. The raised speed slides the 
thread to the left since it increases the delay because it has to reach 
a higher speed to get synced which takes longer. So the only way to 
reduce this effect is to lower the MAX_VEL and increase the MAX_ACCEL, 
and in some cases slow the spindle. This was the case with the original 
1600 oz/in z motor on my G0704, which could only do 29 ipm. A 940 oz/in 
motor can do 90 some, which helps some.   As long as z can keep up, this 
delay won't change by more than an edge spacing from the encoder. Change 
the spindle speed and you change the locked z to spindle phase.

I think some of my sloppy rigid threading on the G0704, is not at the top 
of the stroke, but at the bottom turnaround and back out, due to the 
spindle reversal being too quick for z to follow.  Since that turnaround 
is a programmed turnaround in my hal file, I should try slowing the 
decel/accel as the z can't keep up. But I keep forgetting to run that 
experiment.:(

As its currently set, it can do a 3000 rpm turnaround in about 350 
milliseconds. Lots quicker at the 300-500 revs I normally tap at. But if 
I slow that turnaround down, that will increase the overshoot at the 
bottom,  Dangerous to the tap in a blind hole.

And that could cause a change in the phase lock while backing out, making 
the tap cut sloppy on the up, backout stroke.

Stay well and safe John.

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page 


___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Spindle speed changes with threading.

[John Dammeyer]

Granted this subject is a bit old I've now had some time to dive back into the 
TI F2837xD which has dual processors and other features that will make it a 
good test bed for trying out stuff.  

It has a hardware Quadrature Encoder Interface (QEI) so theoretically I should 
be able to grab encoder counts in any resolution and calculate spindle position 
relative to Z axis position and create moves to track.  

I'll report back when I have some more information.
John


> -Original Message-
> From: Robert Ellenberg [mailto:rwe...@gmail.com]
> Sent: January-20-21 10:12 AM
> To: Enhanced Machine Controller (EMC)
> Subject: Re: [Emc-users] Spindle speed changes with threading.
> 
> Hi All,
> 
> As others have said, during position-synched moves, the axes follow the
> spindle position, so you don't need fine control of spindle speed. However,
> you should have both a stable spindle RPM and a high-ish resolution encoder
> to get the best results. John, for your example, as each encoder pulse
> arrives, the TP will be constantly accelerating / decelerating to try to
> track that position signal. Luckily, it can't get too far off because of
> the axis acceleration limits, but the amplitude of the jitter will
> definitely be higher with a low resolution encoder.
> 
> Here's how spindle synchronization broadly works from within the TP (i.e.
> what occurs in motion after START_FEED_SPEED_SYNCH)
> 
>1. The TP waits (with axes stopped) for a spindle index mark.
>2. Once the spindle has just passed the mark, the machine axes
>accelerate until they reach (spindle speed * requested units/rev).
>3. Once the axes reach the expected velocity, then synchronization is
>declared, and the TP maintains position synchronization from that point
>onwards. At higher spindle RPM, synchronization takes longer, so the
>spindle rotates farther before the axes are synchronized. Multiple
>threading passes at different spindle RPM will not quite follow the same
>path.
>4. After synchronization, the TP computes a position error based on the
>measured spindle position. The axis velocity is nominally spindle speed *
>uu / rev, but that velocity is corrected up or down as needed to drive the
>position error toward zero.
> 
> Note that multi-start threading is not currently possible (because the TP
> always synchs at 0 deg, i.e. at the index mark), but we could modify the TP
> to start synchronization at some angle after the index mark.
> 
> Finally, the obvious fix for the inconsistency in the acceleration phase is
> to just declare synchronization at the index mark right away. With the axes
> starting from rest, there would be a huge initial velocity error for the TP
> to correct. It will do so eventually, but there are large position over- /
> under-shoots until it stabilizes. Luckily, we know what the axis
> acceleration looks like (based on axis max acceleration and nominal spindle
> speed), so you can anticipate this and start the axes moving before the
> spindle reaches the index mark. That way, the axes are moving at the
> nominal speed just as the spindle reaches zero. This removes most of the
> position error at the start, and the TP corrects for any residual error
> very quickly. This is roughly the approach we used in PathPilot, and I
> think LinuxCNC 2.8 or 2.9 would benefit from it as well.
> 
> Best,
> Rob
> 
> On Wed, Jan 20, 2021 at 12:47 PM John Dammeyer 
> wrote:
> 
> >
> >
> > > From: andy pugh [mailto:bodge...@gmail.com]
> > >
> > > On Wed, 20 Jan 2021 at 16:09, Kirk Wallace 
> > wrote:
> > >
> > > > I left the trail here:
> > > > >
> > https://github.com/LinuxCNC/linuxcnc/blob/master/src/emc/rs274ngc/interp_convert.cc#L4881-L5028
> > >
> > > There seems to have been a lot of time spent investigating theory that
> > > could have been settled in 5 minutes with an experiment.
> > >
> > > --
> > > atp
> >
> > Dropping an apple from a tree and observing that it falls and smashes on
> > the ground doesn't splatter into the words that spell out laws of motion
> > made up of bits of peel and apple.
> >
> > I'm assuming that the authors of this code were clever enough to take into
> > account the motor acceleration relative to spindle speed on each pass.  But
> > that doesn't explain how they do that.
> >
> > And if there are 60 teeth on the spindle encoder with a single sensor then
> > 120 edges are the most you get.  That's 3 degrees per edge assuming the
> > slots are symmetrical and I don't think there's a rule that they must be.
> > Might be 1 and 5 degrees.  So assume then an in

Re: [Emc-users] Spindle speed changes with threading.

[Robert Ellenberg]

Hi John,

Good catch! Andy also pointed out that multi-start threading is of course
possible if you do a Z offset like you describe. I was thinking of "native"
support for multi-start in G33 / G33.1, like with a word specifying the
start location in degrees.

-Rob

___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Spindle speed changes with threading.

[John Dammeyer]

Thanks Rob,  
Comments below.

> -Original Message-
> From: Robert Ellenberg [mailto:rwe...@gmail.com]
> Sent: January-20-21 10:12 AM
> To: Enhanced Machine Controller (EMC)
> Subject: Re: [Emc-users] Spindle speed changes with threading.
> 
> Hi All,
> 
> As others have said, during position-synched moves, the axes follow the
> spindle position, so you don't need fine control of spindle speed. However,
> you should have both a stable spindle RPM and a high-ish resolution encoder
> to get the best results. John, for your example, as each encoder pulse
> arrives, the TP will be constantly accelerating / decelerating to try to
> track that position signal. Luckily, it can't get too far off because of
> the axis acceleration limits, but the amplitude of the jitter will
> definitely be higher with a low resolution encoder.
> 
> Here's how spindle synchronization broadly works from within the TP (i.e.
> what occurs in motion after START_FEED_SPEED_SYNCH)
> 
>1. The TP waits (with axes stopped) for a spindle index mark.
>2. Once the spindle has just passed the mark, the machine axes
>accelerate until they reach (spindle speed * requested units/rev).
>3. Once the axes reach the expected velocity, then synchronization is
>declared, and the TP maintains position synchronization from that point
>onwards. At higher spindle RPM, synchronization takes longer, so the
>spindle rotates farther before the axes are synchronized. Multiple
>threading passes at different spindle RPM will not quite follow the same
>path.
>4. After synchronization, the TP computes a position error based on the
>measured spindle position. The axis velocity is nominally spindle speed *
>uu / rev, but that velocity is corrected up or down as needed to drive the
>position error toward zero.
> 
> Note that multi-start threading is not currently possible (because the TP
> always synchs at 0 deg, i.e. at the index mark), but we could modify the TP
> to start synchronization at some angle after the index mark.

I'm surprised that multi-start threads are not possible.   I would think, 
assuming the spindle speed is _not_ allowed to be different, that changing the 
start_z position by say 50% of thread pitch that synchronizing on the index 
would then reliably create a two start thread.  It's how I do it on my ELS.

> 
> Finally, the obvious fix for the inconsistency in the acceleration phase is
> to just declare synchronization at the index mark right away. With the axes
> starting from rest, there would be a huge initial velocity error for the TP
> to correct. It will do so eventually, but there are large position over- /
> under-shoots until it stabilizes. Luckily, we know what the axis
> acceleration looks like (based on axis max acceleration and nominal spindle
> speed), so you can anticipate this and start the axes moving before the
> spindle reaches the index mark. That way, the axes are moving at the
> nominal speed just as the spindle reaches zero. This removes most of the
> position error at the start, and the TP corrects for any residual error
> very quickly. This is roughly the approach we used in PathPilot, and I
> think LinuxCNC 2.8 or 2.9 would benefit from it as well.
> 
> Best,
> Rob

I like the idea. Since the Z is stopped until synchronized and we know using 
standard physics where the Z will be after acceleration up to speed,  that 
regardless of the number of index pulses the time from index to that same 
angular position should be relatively simple using time instead of index 
pulses.  Much better granularity and doesn't force a specific encoder size.  
And the speed is calculated every N encoder pulses so even variations in one 
turn (when the spindle is turning slowly) will not impact entry into the 
existing thread path.

John


> 
> On Wed, Jan 20, 2021 at 12:47 PM John Dammeyer 
> wrote:
> 
> >
> >
> > > From: andy pugh [mailto:bodge...@gmail.com]
> > >
> > > On Wed, 20 Jan 2021 at 16:09, Kirk Wallace 
> > wrote:
> > >
> > > > I left the trail here:
> > > > >
> > https://github.com/LinuxCNC/linuxcnc/blob/master/src/emc/rs274ngc/interp_convert.cc#L4881-L5028
> > >
> > > There seems to have been a lot of time spent investigating theory that
> > > could have been settled in 5 minutes with an experiment.
> > >
> > > --
> > > atp
> >
> > Dropping an apple from a tree and observing that it falls and smashes on
> > the ground doesn't splatter into the words that spell out laws of motion
> > made up of bits of peel and apple.
> >
> > I'm assuming that the authors of this code were clever enough to take into
> > account the moto

Re: [Emc-users] Spindle speed changes with threading.

[Leonardo Marsaglia]

>
> Ahh, good point! It would be nice to be able to explicitly specify a
> spindle angle too, but that's a good workaround.


I always thought about having a way to offet the index pulse. But since
most people use hardware for encoder counting, I suspect the solution
should be right there in the hardware.

El mié, 20 ene 2021 a las 15:58, Robert Ellenberg ()
escribió:

> Ahh, good point! It would be nice to be able to explicitly specify a
> spindle angle too, but that's a good workaround.
>
> On Wed, Jan 20, 2021, 1:50 PM Andy Pugh  wrote:
>
> >
> >
> > > On 20 Jan 2021, at 18:14, Robert Ellenberg  wrote:
> > >
> > >
> > > Note that multi-start threading is not currently possible
> >
> >
> > You can do it by offsetting the start point.
> > (If there is room)
> >
> >
> >
> > ___
> > Emc-users mailing list
> > Emc-users@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/emc-users
> >
>
> ___
> Emc-users mailing list
> Emc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-users
>

___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Spindle speed changes with threading.

[Robert Ellenberg]

Ahh, good point! It would be nice to be able to explicitly specify a
spindle angle too, but that's a good workaround.

On Wed, Jan 20, 2021, 1:50 PM Andy Pugh  wrote:

>
>
> > On 20 Jan 2021, at 18:14, Robert Ellenberg  wrote:
> >
> >
> > Note that multi-start threading is not currently possible
>
>
> You can do it by offsetting the start point.
> (If there is room)
>
>
>
> ___
> Emc-users mailing list
> Emc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-users
>

___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Spindle speed changes with threading.

[Andy Pugh]

> On 20 Jan 2021, at 18:14, Robert Ellenberg  wrote:
> 
> 
> Note that multi-start threading is not currently possible


You can do it by offsetting the start point. 
(If there is room)



___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Spindle speed changes with threading.

[Robert Ellenberg]

Hi All,

As others have said, during position-synched moves, the axes follow the
spindle position, so you don't need fine control of spindle speed. However,
you should have both a stable spindle RPM and a high-ish resolution encoder
to get the best results. John, for your example, as each encoder pulse
arrives, the TP will be constantly accelerating / decelerating to try to
track that position signal. Luckily, it can't get too far off because of
the axis acceleration limits, but the amplitude of the jitter will
definitely be higher with a low resolution encoder.

Here's how spindle synchronization broadly works from within the TP (i.e.
what occurs in motion after START_FEED_SPEED_SYNCH)

   1. The TP waits (with axes stopped) for a spindle index mark.
   2. Once the spindle has just passed the mark, the machine axes
   accelerate until they reach (spindle speed * requested units/rev).
   3. Once the axes reach the expected velocity, then synchronization is
   declared, and the TP maintains position synchronization from that point
   onwards. At higher spindle RPM, synchronization takes longer, so the
   spindle rotates farther before the axes are synchronized. Multiple
   threading passes at different spindle RPM will not quite follow the same
   path.
   4. After synchronization, the TP computes a position error based on the
   measured spindle position. The axis velocity is nominally spindle speed *
   uu / rev, but that velocity is corrected up or down as needed to drive the
   position error toward zero.

Note that multi-start threading is not currently possible (because the TP
always synchs at 0 deg, i.e. at the index mark), but we could modify the TP
to start synchronization at some angle after the index mark.

Finally, the obvious fix for the inconsistency in the acceleration phase is
to just declare synchronization at the index mark right away. With the axes
starting from rest, there would be a huge initial velocity error for the TP
to correct. It will do so eventually, but there are large position over- /
under-shoots until it stabilizes. Luckily, we know what the axis
acceleration looks like (based on axis max acceleration and nominal spindle
speed), so you can anticipate this and start the axes moving before the
spindle reaches the index mark. That way, the axes are moving at the
nominal speed just as the spindle reaches zero. This removes most of the
position error at the start, and the TP corrects for any residual error
very quickly. This is roughly the approach we used in PathPilot, and I
think LinuxCNC 2.8 or 2.9 would benefit from it as well.

Best,
Rob

On Wed, Jan 20, 2021 at 12:47 PM John Dammeyer 
wrote:

>
>
> > From: andy pugh [mailto:bodge...@gmail.com]
> >
> > On Wed, 20 Jan 2021 at 16:09, Kirk Wallace 
> wrote:
> >
> > > I left the trail here:
> > > >
> https://github.com/LinuxCNC/linuxcnc/blob/master/src/emc/rs274ngc/interp_convert.cc#L4881-L5028
> >
> > There seems to have been a lot of time spent investigating theory that
> > could have been settled in 5 minutes with an experiment.
> >
> > --
> > atp
>
> Dropping an apple from a tree and observing that it falls and smashes on
> the ground doesn't splatter into the words that spell out laws of motion
> made up of bits of peel and apple.
>
> I'm assuming that the authors of this code were clever enough to take into
> account the motor acceleration relative to spindle speed on each pass.  But
> that doesn't explain how they do that.
>
> And if there are 60 teeth on the spindle encoder with a single sensor then
> 120 edges are the most you get.  That's 3 degrees per edge assuming the
> slots are symmetrical and I don't think there's a rule that they must be.
> Might be 1 and 5 degrees.  So assume then an index single rising edge is
> used every 6 degrees.
>
> A half inch shaft has a circumference of 0.3925" and each 6 degree index
> is 0.00654".  The implication is depending on spindle speed and motor
> acceleration you might be off by almost 0.006".  That's a lot isn't it?
>
> John
>
>
>
>
> ___
> Emc-users mailing list
> Emc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-users
>

___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Spindle speed changes with threading.

[John Dammeyer]

> From: andy pugh [mailto:bodge...@gmail.com]
> 
> On Wed, 20 Jan 2021 at 16:09, Kirk Wallace  
> wrote:
> 
> > I left the trail here:
> > > https://github.com/LinuxCNC/linuxcnc/blob/master/src/emc/rs274ngc/interp_convert.cc#L4881-L5028
> 
> There seems to have been a lot of time spent investigating theory that
> could have been settled in 5 minutes with an experiment.
> 
> --
> atp

Dropping an apple from a tree and observing that it falls and smashes on the 
ground doesn't splatter into the words that spell out laws of motion made up of 
bits of peel and apple.

I'm assuming that the authors of this code were clever enough to take into 
account the motor acceleration relative to spindle speed on each pass.  But 
that doesn't explain how they do that.  

And if there are 60 teeth on the spindle encoder with a single sensor then 120 
edges are the most you get.  That's 3 degrees per edge assuming the slots are 
symmetrical and I don't think there's a rule that they must be.  Might be 1 and 
5 degrees.  So assume then an index single rising edge is used every 6 degrees. 
 

A half inch shaft has a circumference of 0.3925" and each 6 degree index is 
0.00654".  The implication is depending on spindle speed and motor acceleration 
you might be off by almost 0.006".  That's a lot isn't it?

John




___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Spindle speed changes with threading.

[John Dammeyer]

Hi Kirk,
Every big windstorm we have has me wondering which tree will fall across our 
powerline or house.  But I like the trees too much to remove them.

The problem I find when looking for  " START_SPEED_FEED_SYNCH " is they are all 
either printf functions or null as in they don't appear to do anything: 

void START_SPEED_FEED_SYNCH(int spindle, double feed_per_revolution, bool 
velocity_mode) {}

After that function (wherever it is and whatever it does) returns the actual 
threading pass to the target_z position is done:
STRAIGHT_FEED(block->line_number, boring? safe_x + depth: safe_x - 
depth, 
  start_y, target_z - zoff, AABBCC); //over

The carriage is brought to the correct Z + offset location where the offset is 
the tan of the X distance and angle to follow the slope of the thread angle.  
Like setting the compound to 29.5 degrees.

Then we wait for some sort of sync.  It appears the Z may well be stopped at 
this point and the tool is at the depth for cutting the next pass.  I guess it 
depends on how slow the spindle is moving.

But that parameter "feed_per_revolution" probably is probably used along with 
the Z axis "MAX_ACCELERATION" in the INI and HAL files to count out a specific 
index position so the START_SPEED_FEED_SYNCH function returns not at the index 
position but where it would be given Z axis acceleration at the current angular 
velocity of the spindle.

Have I got that right?  And if so where is the real code for 
START_SPEED_FEED_SYNCH?
John Dammeyer
 

> -Original Message-
> From: Kirk Wallace [mailto:kwall...@wallacecompany.com]
> Sent: January-20-21 8:07 AM
> To: emc-users@lists.sourceforge.net
> Subject: Re: [Emc-users] Spindle speed changes with threading.
> 
> (bottom posted this one)
> 
> On 1/19/21 9:42 PM, John Dammeyer wrote:
> >> I dont think, the z position is "geared" to the counts beyond
> >> index so locked unambiguously to spindle angle beyond index,
> >> after initial sync is acheived.
> >>
> >>
> >> Peter Wallace
> >> Mesa Electronics
> > So far that makes sense.  From "LinuxCNC User manual"
> >
> > "The tool will pause briefly for synchronization before each threading 
> > pass, so a relief groove will be required at the entry unless the
> beginning of the thread is past the end of the material or an entry taper is 
> used."
> >
> > Following that is:
> > "Unless using an exit taper, the exit move is not synchronized to the 
> > spindle speed and will be a rapid move. With a slow spindle,the
> exit move might take only a small fraction of a revolution. If the spindle 
> speed is increased after several passes are complete,
> subsequent exit moves will require a larger portion of a revolution, 
> resulting in a very heavy cut during the exit move. This can be
> avoided by providing a relief groove at the exit, or by not changing the 
> spindle speed while threading."
> >
> > So there are side effects to changing the spindle speed but nothing that 
> > infers it can't or shouldn't be done.
> >
> > The implication is that at the start of the G76 based on spindle speed and 
> > Z axis acceleration along with target Z axis speed a specific
> spindle encoder value is used after that to determine when the axis is 
> synchronized.
> >
> > Or N encoder counts before the index is used as the starting point for the 
> > Z to begin so it's up to speed, ready to engage, at the
> spindle index mark.
> >
> > Synchronizing it to the index mark for up to speed condition if you want to 
> > create multi-start threads makes sense.   Move the start
> point by half the pitch to the right.  Since the position of tool entry at 
> speed is the index pulse regardless of spindle speed the thread
> should start 180 degrees from the first.
> >
> > So where is this calculated?  In the Trajectory Planner?  I'd like to look 
> > at the code but no idea where to even start looking.
> >
> > John Dammeyer
> >
> 
> snip ...
> 
> I left the trail here:
> 
> > https://github.com/LinuxCNC/linuxcnc/blob/master/src/emc/rs274ngc/interp_convert.cc#L4881-L5028
> 
> I think this is my next stop:
> 
> > https://github.com/LinuxCNC/linuxcnc/tree/master/src/emc/motion
> 
> (but after a day of 50 mph winds, there are a few chores to attend to)
> 
> Kirk Wallace
> 
> 
> ___
> Emc-users mailing list
> Emc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-users



___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Spindle speed changes with threading.

[andy pugh]

On Wed, 20 Jan 2021 at 16:09, Kirk Wallace  wrote:

> I left the trail here:
> > https://github.com/LinuxCNC/linuxcnc/blob/master/src/emc/rs274ngc/interp_convert.cc#L4881-L5028

There seems to have been a lot of time spent investigating theory that
could have been settled in 5 minutes with an experiment.

-- 
atp
"A motorcycle is a bicycle with a pandemonium attachment and is
designed for the especial use of mechanical geniuses, daredevils and
lunatics."
— George Fitch, Atlanta Constitution Newspaper, 1912


___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Spindle speed changes with threading.

[Kirk Wallace]

(bottom posted this one)

On 1/19/21 9:42 PM, John Dammeyer wrote:

I dont think, the z position is "geared" to the counts beyond
index so locked unambiguously to spindle angle beyond index,
after initial sync is acheived.


Peter Wallace
Mesa Electronics

So far that makes sense.  From "LinuxCNC User manual"

"The tool will pause briefly for synchronization before each threading pass, so a 
relief groove will be required at the entry unless the beginning of the thread is past 
the end of the material or an entry taper is used."

Following that is:
"Unless using an exit taper, the exit move is not synchronized to the spindle speed 
and will be a rapid move. With a slow spindle,the exit move might take only a small 
fraction of a revolution. If the spindle speed is increased after several passes are 
complete, subsequent exit moves will require a larger portion of a revolution, resulting 
in a very heavy cut during the exit move. This can be avoided by providing a relief 
groove at the exit, or by not changing the spindle speed while threading."

So there are side effects to changing the spindle speed but nothing that infers 
it can't or shouldn't be done.

The implication is that at the start of the G76 based on spindle speed and Z 
axis acceleration along with target Z axis speed a specific spindle encoder 
value is used after that to determine when the axis is synchronized.

Or N encoder counts before the index is used as the starting point for the Z to 
begin so it's up to speed, ready to engage, at the spindle index mark.

Synchronizing it to the index mark for up to speed condition if you want to 
create multi-start threads makes sense.   Move the start point by half the 
pitch to the right.  Since the position of tool entry at speed is the index 
pulse regardless of spindle speed the thread should start 180 degrees from the 
first.

So where is this calculated?  In the Trajectory Planner?  I'd like to look at 
the code but no idea where to even start looking.

John Dammeyer



snip ...

I left the trail here:


https://github.com/LinuxCNC/linuxcnc/blob/master/src/emc/rs274ngc/interp_convert.cc#L4881-L5028


I think this is my next stop:


https://github.com/LinuxCNC/linuxcnc/tree/master/src/emc/motion


(but after a day of 50 mph winds, there are a few chores to attend to)

Kirk Wallace


___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Spindle speed changes with threading.

[John Dammeyer]

> I dont think, the z position is "geared" to the counts beyond
> index so locked unambiguously to spindle angle beyond index,
> after initial sync is acheived.
> 
> 
> Peter Wallace
> Mesa Electronics

So far that makes sense.  From "LinuxCNC User manual"

"The tool will pause briefly for synchronization before each threading pass, so 
a relief groove will be required at the entry unless the beginning of the 
thread is past the end of the material or an entry taper is used."

Following that is:
"Unless using an exit taper, the exit move is not synchronized to the spindle 
speed and will be a rapid move. With a slow spindle,the exit move might take 
only a small fraction of a revolution. If the spindle speed is increased after 
several passes are complete, subsequent exit moves will require a larger 
portion of a revolution, resulting in a very heavy cut during the exit move. 
This can be avoided by providing a relief groove at the exit, or by not 
changing the spindle speed while threading."

So there are side effects to changing the spindle speed but nothing that infers 
it can't or shouldn't be done.

The implication is that at the start of the G76 based on spindle speed and Z 
axis acceleration along with target Z axis speed a specific spindle encoder 
value is used after that to determine when the axis is synchronized.  

Or N encoder counts before the index is used as the starting point for the Z to 
begin so it's up to speed, ready to engage, at the spindle index mark.

Synchronizing it to the index mark for up to speed condition if you want to 
create multi-start threads makes sense.   Move the start point by half the 
pitch to the right.  Since the position of tool entry at speed is the index 
pulse regardless of spindle speed the thread should start 180 degrees from the 
first.

So where is this calculated?  In the Trajectory Planner?  I'd like to look at 
the code but no idea where to even start looking.

John Dammeyer




___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Spindle speed changes with threading.

[Gene Heskett]

On Tuesday 19 January 2021 15:50:49 Todd Zuercher wrote:

> I under stand the analogy, but I wonder if Linuxcnc is erroneously
> behaving as if the "leadscrew" were multiple start, with the number of
> starts equal to the encoder's counts/rev.  Resulting in the syncing of
> the axis to the spindle is inconsistent if the syncing move isn't
> always the same?  (Not saying this is how it is, just proposing a
> possible reason if the problem is real.)
>
I think in cases where the spindle encoder is quite low resolution, that 
it may well contribute. albeit probably not to that extent. Because on 
my g0704, the spindle encoder is actually a 1024 ppr on the rear of the 
motor, while the index is derived from an ATS-667 watching a screw glued 
to the side of the drawbar nut, which makes my spindle encoder have an 
effective count when the head is in low gear of something a bit north of 
14,000. Just over 7000 in high gear.  All fixed in hal.

I think a bigger reason for my thread timing wibbles in the G33.1 cycle 
is far more related to the sample rate imposed by the servo only thread. 
We need a 10 kilohertz thread just for reading the spindle encoder, for 
exactly this reason.

Quantization noise IOW. Between that, and the fact that the post of this 
G0704 is a  degree or more out of square with the base. Its leaning 
sideways just enough to detect it. Tramming the head square to the 
table, and you can see the error in the head to slider joint. Ad you can 
dial a square sitting on the table, and use up the range of a .0001" 
dial in less than 2" of vertical motion. 
I loosened the bolts a year back and pulled it sorta square, but then I 
can't tighten the bolts, they are seriously bound.  So sometime when 
I've nothing better to do, I'll take it off, and run a reamer thru 3 of 
the holes the next size bigger, and then try to plumb it again when I 
put the bolts back in. Maybe this summer if I don't miss roll call 
first. But to do that really right, I'll have to invest in a cylindrical 
square. And to do it really right, I'll need some sort of a worm drive 
rigged for tramming the head. Face it, the G0704 is a Chinese piece of 
BBLB crap. I don't really understand why I keep screwing with it. My 
6040 gantry is squarer that this piece of junk.  And at the moment, its 
halfway thru making the first of 2 ER20 chuck wrenches out of 1/2" alu 
plate.

Which will, sometime in the next day or so, generate some questions about 
G5.2, the nurbs thing. Figure I might as well make them purty. Its a bit 
funny, its been in LCNC since 2009, and its still labeled very 
experimental.  Has anyone actually used it?
 
> I don't do any threading or have any machines with a spindle encoder. 
> But I have observed this debate on whether this problem exists in
> Linuxcnc for years now here on this list.

This is true, for pushing 2 decades now.
>
Take care and stay well everybody.

> Todd Zuercher
> P. Graham Dunn Inc.
> 630 Henry Street 
> Dalton, Ohio 44618
> Phone:  (330)828-2105ext. 2031


Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page 


___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Spindle speed changes with threading.

[Peter C. Wallace]

On Tue, 19 Jan 2021, Todd Zuercher wrote:


Date: Tue, 19 Jan 2021 20:50:49 +
From: Todd Zuercher 
Reply-To: "Enhanced Machine Controller (EMC)"

To: "Enhanced Machine Controller (EMC)" 
Subject: Re: [Emc-users] Spindle speed changes with threading.

I under stand the analogy, but I wonder if Linuxcnc is erroneously behaving as 
if the "leadscrew" were multiple start, with the number of starts equal to the 
encoder's counts/rev.  Resulting in the syncing of the axis to the spindle is 
inconsistent if the syncing move isn't always the same?  (Not saying this is 
how it is, just proposing a possible reason if the problem is real.)


I don't do any threading or have any machines with a spindle encoder.  But I 
have observed this debate on whether this problem exists in Linuxcnc for years 
now here on this list.


Todd Zuercher
P. Graham Dunn Inc.
630 Henry Street 
Dalton, Ohio 44618
Phone:  (330)828-2105ext. 2031


I dont think, the z position is "geared" to the counts beyond
index so locked unambiguously to spindle angle beyond index,
after initial sync is acheived.


Peter Wallace
Mesa Electronics
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Spindle speed changes with threading.

[Todd Zuercher]

I under stand the analogy, but I wonder if Linuxcnc is erroneously behaving as 
if the "leadscrew" were multiple start, with the number of starts equal to the 
encoder's counts/rev.  Resulting in the syncing of the axis to the spindle is 
inconsistent if the syncing move isn't always the same?  (Not saying this is 
how it is, just proposing a possible reason if the problem is real.)

I don't do any threading or have any machines with a spindle encoder.  But I 
have observed this debate on whether this problem exists in Linuxcnc for years 
now here on this list.

Todd Zuercher
P. Graham Dunn Inc.
630 Henry Street 
Dalton, Ohio 44618
Phone:  (330)828-2105ext. 2031

-Original Message-
From: Peter C. Wallace  
Sent: Tuesday, January 19, 2021 3:10 PM
To: Enhanced Machine Controller (EMC) 
Subject: Re: [Emc-users] Spindle speed changes with threading.

On Tue, 19 Jan 2021, Gene Heskett wrote:

> It wasn't the last time I tested it Jon, and most of the recent 
> conversations here are ignoreing the fact that every new stroke, 
> starting from its resting position, regardless of whether its a G76 or 
> you are "pecking" a G33.1 for rigid tapping, is a NEW sync action, and 
> its here that diddling the the spindle speed affects both the accel 
> time to get Z up to sync speed, so in addition to the spindle turning 
> further at a higher speed, it also takes Z longer to get up to that 
> higher speed and become phase locked. This combined change in the 
> delay from 0 to locked is changing the phasing between the spindle and 
> the tool at about 2x the change in spindle speed. And screwing up your thread.
>

As long as the sync can happen before the tool hits the metal that will be no 
error in the created thread (no phase error) regardless of when the speed 
change occurs. The only change will be where the thread starts. Once synced, 
this is basically identical to a mechanical lathe (when the half nut is 
engaged).


Peter Wallace
Mesa Electronics



___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users


___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Spindle speed changes with threading.

[Peter C. Wallace]

On Tue, 19 Jan 2021, Gene Heskett wrote:


It wasn't the last time I tested it Jon, and most of the recent
conversations here are ignoreing the fact that every new stroke,
starting from its resting position, regardless of whether its a G76 or
you are "pecking" a G33.1 for rigid tapping, is a NEW sync action, and
its here that diddling the the spindle speed affects both the accel time
to get Z up to sync speed, so in addition to the spindle turning further
at a higher speed, it also takes Z longer to get up to that higher speed
and become phase locked. This combined change in the delay from 0 to
locked is changing the phasing between the spindle and the tool at about
2x the change in spindle speed. And screwing up your thread.



As long as the sync can happen before the tool hits the metal that will be no 
error in the created thread (no phase error) regardless of when the speed change 
occurs. The only change will be where the thread starts. Once synced, this is 
basically identical to a mechanical lathe (when the half nut is engaged).



Peter Wallace
Mesa Electronics



___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Spindle speed changes with threading.

[Gene Heskett]

On Tuesday 19 January 2021 12:48:32 Jon Elson wrote:

> On 01/18/2021 05:47 PM, John Dammeyer wrote:
> >>> So what does LinuxCNC do?  Is the thread mucked up if spindle
> >>> speed is changed during a feed hold and then start?
> >>
> >> Feed hold has nothing to do with it John, you can't change the
> >> spindle speed in mid thread. Full stop. Period. I think it could do
> >> what is needed.  But its like Yogi Berra once said about theory and
> >> practice. Which in this case means machine balistics are hard to
> >> do.
> >
> > Gene,
> > Are you saying that for threading on a lathe LinuxCNC _must_ have
> > control over the spindle speed?  Or can I have a manual knob and
> > adjust the speed as it's threading.  Or as it's returning back to
> > the start?
>
> No, not at all.  On desktop machines, the spindle always
> slows down when the cutting starts.
> LinuxCNC adapts the Z feed to the speed of the spindle, as
> sensed by the encoder.  You can literally shut the motor off
> and turn it by hand, even back up and then move forward again.
>
> > Or are you saying that if LinuxCNC is cutting a thread keep your
> > fingers off the speed control?
>
> When in a threading operation, at least most manual controls
> and overrides are disabled, other than E-stop.  Feedrate
> override is certainly disabled, and abort (esc key) and
> pause are disabled until the cutter is out of the
> workpiece.  I have no idea if spindle override is disabled,
> I have not tried it.
> Seems like maybe that would be OK.
>
> Jon
>
It wasn't the last time I tested it Jon, and most of the recent 
conversations here are ignoreing the fact that every new stroke, 
starting from its resting position, regardless of whether its a G76 or 
you are "pecking" a G33.1 for rigid tapping, is a NEW sync action, and 
its here that diddling the the spindle speed affects both the accel time 
to get Z up to sync speed, so in addition to the spindle turning further 
at a higher speed, it also takes Z longer to get up to that higher speed 
and become phase locked. This combined change in the delay from 0 to 
locked is changing the phasing between the spindle and the tool at about 
2x the change in spindle speed. And screwing up your thread.

The ONLY way I can see to get away from that would be to set the 
allowable error in the PID way high at the index pulse that starts the 
stroke and let the PID establish a 1 to 1 relationship at the index 
pulse, letting the PID do all the work of jerking Z up to speed. But 
that means everybody has to use a PID to drive Z, configureing the 
allowable error back to its default at say 10 turns after the index 
pulse that triggered the current stroke and train themselves to allow 
more space between the resting point, and the tool entering the work as 
the PID, dealing with that large an initial error, may well ring like 
the cracked liberty bell for several turns of the spindle before its 
tracking good enough to cut a useable thread.  If, 10 turns into the 
stroke it triggers a following error as the default is restored, you 
really need to tune the PID better.  Or slow the spindle to give it time 
to stabilize. This might even be done better if each stroke starts from 
a dead spindle, because the PID would spared much of the huge initial 
error while accellerating both at the same time.

Diddling the PID'a error inputs is something hal can do well. You just 
have to look at the problem, and sometimes think a bit outside the box 
to fix it.

That was the major reason I changed out that 1600oz/in on the G0704 
driving Z, 27 IPM was simply too slow for any reasonable threading speed 
as it couldn't get up to speed to cut a 11 tpi USS thread.  A shorter, 
much lower inductance 940oz/in motor with an AC powered driver got it up 
to over 100 IPM, and all my following errors went away.

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page 


___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Spindle speed changes with threading.

[Jon Elson]

On 01/18/2021 05:47 PM, John Dammeyer wrote:

So what does LinuxCNC do?  Is the thread mucked up if spindle speed is
changed during a feed hold and then start?


Feed hold has nothing to do with it John, you can't change the spindle
speed in mid thread. Full stop. Period. I think it could do what is
needed.  But its like Yogi Berra once said about theory and practice.
Which in this case means machine balistics are hard to do.

Gene,
Are you saying that for threading on a lathe LinuxCNC _must_ have control over 
the spindle speed?  Or can I have a manual knob and adjust the speed as it's 
threading.  Or as it's returning back to the start?
No, not at all.  On desktop machines, the spindle always 
slows down when the cutting starts.
LinuxCNC adapts the Z feed to the speed of the spindle, as 
sensed by the encoder.  You can literally shut the motor off 
and turn it by hand, even back up and then move forward again.

Or are you saying that if LinuxCNC is cutting a thread keep your fingers off 
the speed control?


When in a threading operation, at least most manual controls 
and overrides are disabled, other than E-stop.  Feedrate 
override is certainly disabled, and abort (esc key) and 
pause are disabled until the cutter is out of the 
workpiece.  I have no idea if spindle override is disabled, 
I have not tried it.

Seems like maybe that would be OK.

Jon


___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Spindle speed changes with threading.

[Peter C. Wallace]

On Mon, 18 Jan 2021, Gene Heskett wrote:


Date: Mon, 18 Jan 2021 23:36:37 -0500
From: Gene Heskett 
Reply-To: "Enhanced Machine Controller (EMC)"

To: emc-users@lists.sourceforge.net
Subject: Re: [Emc-users] Spindle speed changes with threading.

On Monday 18 January 2021 22:21:00 Peter C. Wallace wrote:


On Mon, 18 Jan 2021, Gene Heskett wrote:

But because once locked, its not a big deal if the cutting load
slows the spindle 25%, its still locked at that phase angle and it
will stay that way until the end of THAT cut stroke.  But if YOU
change the spindle speed, then YOU have changed the synch delay at
the start of the next stroke and that changes the cutter position as
it tracks the next stroke, cutting a wider groove with that next
stroke. If you speed it up, the extra cut is the back edge of the
tool because it synched later in the spindles rotation.


I dont think thats true, the initial delays do not affect the thread
past any initial issues when the thread starts.
This is because once synchronized, the Z is effectively in a
_position_ locked loop with spindle rotation relative to the
accumulated angle past the index. Changing the speed may change the
start of the threads due to the lock-in time but not that main
threading pass. You can verify this by turning the spindle by hand and
doing multiple threading passses.


This is true of both G76 and G33.1, with G33.1 maintaining sync until the
tap has been totally withdrawn, while G76 releases the synch during the
Z retrace, so it can move at G0 speed, then both checks spindle-at-speed
and if true, starts the next pass on the index if you've written a peck
loop, exactly the same as for a single pass if your spindle has the
hueavos to do it in one pass.

Hidden in this is the fact that either resyncs the spindle to z phaseing
at the starting/resting place for either a G76 or a g33.1 for every
stroke it makes. And a change in spindle speed will change that phasing,
screwing up the thread.


I dont think so, both G33 and G76  are _position_ locked so the initial
start of thread may vary but the thread phasing is independent of spindle
speed.


Peter Wallace
Mesa Electronics


___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Spindle speed changes with threading.

[Gene Heskett]

On Monday 18 January 2021 22:21:00 Peter C. Wallace wrote:

> On Mon, 18 Jan 2021, Gene Heskett wrote:
> > But because once locked, its not a big deal if the cutting load
> > slows the spindle 25%, its still locked at that phase angle and it
> > will stay that way until the end of THAT cut stroke.  But if YOU
> > change the spindle speed, then YOU have changed the synch delay at
> > the start of the next stroke and that changes the cutter position as
> > it tracks the next stroke, cutting a wider groove with that next
> > stroke. If you speed it up, the extra cut is the back edge of the
> > tool because it synched later in the spindles rotation.
>
> I dont think thats true, the initial delays do not affect the thread
> past any initial issues when the thread starts.
> This is because once synchronized, the Z is effectively in a
> _position_ locked loop with spindle rotation relative to the
> accumulated angle past the index. Changing the speed may change the
> start of the threads due to the lock-in time but not that main
> threading pass. You can verify this by turning the spindle by hand and
> doing multiple threading passses.
>
This is true of both G76 and G33.1, with G33.1 maintaining sync until the 
tap has been totally withdrawn, while G76 releases the synch during the 
Z retrace, so it can move at G0 speed, then both checks spindle-at-speed 
and if true, starts the next pass on the index if you've written a peck 
loop, exactly the same as for a single pass if your spindle has the 
hueavos to do it in one pass.

Hidden in this is the fact that either resyncs the spindle to z phaseing 
at the starting/resting place for either a G76 or a g33.1 for every 
stroke it makes. And a change in spindle speed will change that phasing, 
screwing up the thread.

So the spindle does not stay synced with Z during the entirety of a G76, 
each of the pass cuts is a fresh sync.  And If you have to write a peck 
loop for tappping because you don't have a 20 horse spindle it is also 
freshly resynced at the top of each g33.1. I usually stretch that top 
stop long enough to blow most of the swarf off the spinning tap, and to 
give it a drink of rapid tap or buttercut. It Helps to keep the tap from 
packing full.

> Peter Wallace
> Mesa Electronics
>
>
>
> ___
> Emc-users mailing list
> Emc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-users


Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page 


___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Spindle speed changes with threading.

[Peter C. Wallace]

On Mon, 18 Jan 2021, Gene Heskett wrote:


But because once locked, its not a big deal if the cutting load slows the
spindle 25%, its still locked at that phase angle and it will stay that
way until the end of THAT cut stroke.  But if YOU change the spindle
speed, then YOU have changed the synch delay at the start of the next
stroke and that changes the cutter position as it tracks the next
stroke, cutting a wider groove with that next stroke. If you speed it
up, the extra cut is the back edge of the tool because it synched later
in the spindles rotation.


I dont think thats true, the initial delays do not affect the thread
past any initial issues when the thread starts.
This is because once synchronized, the Z is effectively in a _position_
locked loop with spindle rotation relative to the accumulated angle
past the index. Changing the speed may change the start of the threads
due to the lock-in time but not that main threading pass. You can verify this
by turning the spindle by hand and doing multiple threading passses.



Peter Wallace
Mesa Electronics



___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Spindle speed changes with threading.

[Kirk Wallace]

On 1/18/21 3:53 PM, Andy Pugh wrote:



On 18 Jan 2021, at 23:08, John Dammeyer  wrote:

So what does LinuxCNC do?  Is the thread mucked up if spindle speed is changed 
during a feed hold and then start?

I believe that it does. The docs specifically warn against Chang speed during a 
threading cycle.



___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users




I seem to recall that lathe threading with G76 will disable the feed 
hold signal during the coordinated motion on the drive line, which can 
include the straight thread or an optional beginning or end taper within 
the stock straight thread length. The electronic gearing between the 
spindle encoder and the Z position should keep the thread path accurate 
through spindle speed variations. G33 documentation indicates that the 
routine calculates the best path to get the tool to the ideal index 
keyed path as soon as possible after the index mark signal. This is 
mostly from memory, so please refer to the LinuxCNC documentation to get 
the official information. I very much suggest _reading_ the 
documentation and not skimming because some of the features are not 
intuitive.


There are other ways to tread, such as using spindle index only with 
dead-reckoning.



___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Spindle speed changes with threading.

[Gene Heskett]

On Monday 18 January 2021 18:47:25 John Dammeyer wrote:

> > > So what does LinuxCNC do?  Is the thread mucked up if spindle
> > > speed is changed during a feed hold and then start?
> >
> > Feed hold has nothing to do with it John, you can't change the
> > spindle speed in mid thread. Full stop. Period. I think it could do
> > what is needed.  But its like Yogi Berra once said about theory and
> > practice. Which in this case means machine balistics are hard to do.
>
> Gene,
> Are you saying that for threading on a lathe LinuxCNC _must_ have
> control over the spindle speed?  Or can I have a manual knob and
> adjust the speed as it's threading.  Or as it's returning back to the
> start?

No, you do not need linuxcnc control over spindle speed, I have no 
software linkage to control the spindle speed on any of my machines, but 
the spindle speed is very tightly regulated by a PID on 2 of my 
machines, and by the slip angle between the vfd and the spindle motor on 
the other 2, but IF you change the speed mid thread, you will change the 
phasing between the spindle and the tool because it takes a finite time 
to bring the z axis into synch with the spindle speed as it starts the 
next stroke. The Z is at a complete stop when the index arrives, and it 
takes some 10's of degrees for the z speed to arrive at the correct 
speed, and actually become locked to the spindle.

Change the spindle speed, and you change this delay to a greater effect 
than you would think because at a higher spindle speed, z has to reach a 
greater velocity, which takes more time. The position error once locked 
is more than 100% of the speed change, and can be almost square if 
doubleing the speed.

But because once locked, its not a big deal if the cutting load slows the 
spindle 25%, its still locked at that phase angle and it will stay that 
way until the end of THAT cut stroke.  But if YOU change the spindle 
speed, then YOU have changed the synch delay at the start of the next 
stroke and that changes the cutter position as it tracks the next 
stroke, cutting a wider groove with that next stroke. If you speed it 
up, the extra cut is the back edge of the tool because it synched later 
in the spindles rotation.

  Its the time it takes to accel to the locked state that eats your 
lunch.

> Or are you saying that if LinuxCNC is cutting a thread keep your
> fingers off the speed control?

Yes, cut air at a reduced speed to check your pullout point at the left 
end of the thread, and when checking, remember that the cutter is 
advancing to the left per stroke. not only in depth of cut, its normally 
taking 99% of the cut off the front (left) edge of the tool, that is 
what you are controlling with the Q setting in a G76. Normally 29.5 
degrees, the other .5 degree is to keep the top of the thread from 
smearing if your tool is dull. 30 degrees is perfect if the machine is, 
but you won't get quite as "clean" a cut because the back edge of the 
tool is skidding. At 29.5 for the advance angle, the right, back edge of 
the tools tooth is keeping things clean & smooth.

Cheers John, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page 


___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Spindle speed changes with threading.

[Peter C. Wallace]

On Mon, 18 Jan 2021, John Dammeyer wrote:


Date: Mon, 18 Jan 2021 15:58:12 -0800
From: John Dammeyer 
Reply-To: "Enhanced Machine Controller (EMC)"

To: "'Enhanced Machine Controller (EMC)'" 
Subject: Re: [Emc-users] Spindle speed changes with threading.

---


Just trying to get my head around this.  The spindle position is really only 
known by the index pulse.  Knowing both Z axis acceleration and target speed 
the Z is started N spindle encoder counts before an index pulse so it's up to 
speed the instant the spindle ticks over another index.  How many turns of the 
spindle that takes then doesn't matter.


John




AFAIK the Z position for threading is fully "geared"to the spindle position
during the entire threading pass so index is only used for initial sync. The Z 
position will alway be correct after the initial Z acceleration to reach

synchronization, regardless of the speed or change in speed of the spindle.

_But_ Changes at the beginning of the thread can occur with varying spindle 
speeds because of X and Z acceleration and velocity limits. These can change the 
start of thread position or even make threads with varing pitch if Z is not up 
to speed when cutting begins




Peter Wallace
Mesa Electronics



___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Spindle speed changes with threading.

[John Dammeyer]

Thanks Jon.

More questions below then.

> > Quick question about threading with LinuxCNC.  If you do a feed hold 
> > between passes for cutting a thread and during that feed hold
> change the spindle speed what will happen?
> >
> No problem.  At the beginning of EACH pass, the spindle
> encoder is zeroed and synched to the index pulse.  Then, the
> Z axis is slaved to the spindle count.  You can even stop or
> back up the spindle during the threading pass, and the Z
> will stay synched to the thread, within the backlash of the
> Z axis.
> 
> 
> > >From a start it takes a certain amount of time to accelerate up to the 
> > >required speed.  If the spindle is turning twice as fast as the
> previous pass it then turns twice as far.  That doesn't line up the cutter 
> with the previous thread.
> >
> Well, as speed increases, it needs more air cut travel to
> get synched, depending on the acceleration and performance
> of the Z axis.
> 
> Jon

Yeah I get that if it can't accelerate fast enough it does need to have the 
BEGIN position far enough away. 

I thought (someone said) that the threading only used the index once at the 
beginning of the threading operation.  I take it then that's per pass.  

I'm not sure what is meant by slaved to the spindle count.  If the Z axis was 
400 steps per rev and the spindle 60 pulses (240 quadrature edges).  Does the 
system calculate how many steps it requires to get up to the threading speed?  
Then use that to get to a specific spindle count value?

Maybe an example:
1.  For simplicity lead screw pitch of 10 TPI (0.1" pitch)
2. for 0.001" resolution the stepper motor has to have at least 100 steps per 
rev which is pretty easy with a motor running full step of 200 steps per turn.
3. Assume acceleration of 1000 steps/sec/sec. In 0.1 seconds it's doing 100 
steps/second. In 0.2 seconds 200 steps/second or 1 rev per second which is 60 
RPM.
4. Spindle is turning 60 RPM for threading so we've reached threading speed in 
0.2 seconds.
5. Spindle is turning 1 rev per second or 2/10ths of a rev in that 0.2 seconds. 
 (48 encoder counts of the 240 per rev) assuming the Z axis started on the 
index pulse with a cleared encoder counter.

Now let's double the spindle speed.   The lead screw also has to turn twice as 
fast so it will get there in 0.4 seconds.  But the spindle will have reached 48 
encoder counts in half the original time or 0.1 second.  It will have travelled 
much further before the Z axis is up to speed.

Or does LinuxCNC calculate that now it will take 96 spindle encoder counts to 
for the Z axis to get up to speed.  To enter the thread at the same point it 
then detects the index.  Counts 240-96 pulses and then starts the Z axis?

If it does that for any speed then the Z axis would always be synchronized on 
the next spindle index.

Just trying to get my head around this.  The spindle position is really only 
known by the index pulse.  Knowing both Z axis acceleration and target speed 
the Z is started N spindle encoder counts before an index pulse so it's up to 
speed the instant the spindle ticks over another index.  How many turns of the 
spindle that takes then doesn't matter.

John





___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Spindle speed changes with threading.

[Andy Pugh]

> On 18 Jan 2021, at 23:08, John Dammeyer  wrote:
> 
> So what does LinuxCNC do?  Is the thread mucked up if spindle speed is 
> changed during a feed hold and then start?

I believe that it does. The docs specifically warn against Chang speed during a 
threading cycle. 



___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Spindle speed changes with threading.

[John Dammeyer]

> > So what does LinuxCNC do?  Is the thread mucked up if spindle speed is
> > changed during a feed hold and then start?
> >
> Feed hold has nothing to do with it John, you can't change the spindle
> speed in mid thread. Full stop. Period. I think it could do what is
> needed.  But its like Yogi Berra once said about theory and practice.
> Which in this case means machine balistics are hard to do.

Gene,
Are you saying that for threading on a lathe LinuxCNC _must_ have control over 
the spindle speed?  Or can I have a manual knob and adjust the speed as it's 
threading.  Or as it's returning back to the start? 

Or are you saying that if LinuxCNC is cutting a thread keep your fingers off 
the speed control?

John





___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Spindle speed changes with threading.

[Jon Elson]

On 01/18/2021 05:05 PM, John Dammeyer wrote:

Quick question about threading with LinuxCNC.  If you do a feed hold between 
passes for cutting a thread and during that feed hold change the spindle speed 
what will happen?
  
No problem.  At the beginning of EACH pass, the spindle 
encoder is zeroed and synched to the index pulse.  Then, the 
Z axis is slaved to the spindle count.  You can even stop or 
back up the spindle during the threading pass, and the Z 
will stay synched to the thread, within the backlash of the 
Z axis.




>From a start it takes a certain amount of time to accelerate up to the 
required speed.  If the spindle is turning twice as fast as the previous pass it 
then turns twice as far.  That doesn't line up the cutter with the previous thread.
  
Well, as speed increases, it needs more air cut travel to 
get synched, depending on the acceleration and performance 
of the Z axis.


Jon


___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Spindle speed changes with threading.

[Gene Heskett]

On Monday 18 January 2021 18:05:56 John Dammeyer wrote:

> Quick question about threading with LinuxCNC.  If you do a feed hold
> between passes for cutting a thread and during that feed hold change
> the spindle speed what will happen?
>
> From a start it takes a certain amount of time to accelerate up to the
> required speed.  If the spindle is turning twice as fast as the
> previous pass it then turns twice as far.  That doesn't line up the
> cutter with the previous thread.
>
> The observation comment assumes a standard acceleration rate for the Z
> axis.
>
> However, the system could also be configured to accelerate up to
> arrive at a specific spindle position once it reaches threading speed.
>
> For example.  The system knows using the fastest Z axis
> acceleration+speed and spindle speed means it can arrive at threading
> speed in 30 degrees of spindle rotation.  At slower spindle speeds it
> would not accelerate so fast that it might be there at 5 degrees of
> spindle rotation.  Instead it would ramp up much slower so that when
> it reaches the much slower Z axis speed it also has reached the 30
> degree spindle position.
>
> At that point it doesn't matter anymore as long as the Z axis tracks
> the spindle speed the tool bit will follow the previous thread.
>
> So what does LinuxCNC do?  Is the thread mucked up if spindle speed is
> changed during a feed hold and then start?
>
Feed hold has nothing to do with it John, you can't change the spindle 
speed in mid thread. Full stop. Period. I think it could do what is 
needed.  But its like Yogi Berra once said about theory and practice. 
Which in this case means machine balistics are hard to do. 
> Thanks
> John Dammeyer
>
> "ELS! Nothing else works as well for your Lathe"
> Automation Artisans Inc.
> www dot autoartisans dot com
>
>
> ___
> Emc-users mailing list
> Emc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-users


Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page 


___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

[Emc-users] Spindle speed changes with threading.

[John Dammeyer]

Quick question about threading with LinuxCNC.  If you do a feed hold between 
passes for cutting a thread and during that feed hold change the spindle speed 
what will happen?
 
>From a start it takes a certain amount of time to accelerate up to the 
>required speed.  If the spindle is turning twice as fast as the previous pass 
>it then turns twice as far.  That doesn't line up the cutter with the previous 
>thread.
 
The observation comment assumes a standard acceleration rate for the Z axis.
 
However, the system could also be configured to accelerate up to arrive at a 
specific spindle position once it reaches threading speed.  
 
For example.  The system knows using the fastest Z axis acceleration+speed and 
spindle speed means it can arrive at threading speed in 30 degrees of spindle 
rotation.  At slower spindle speeds it would not accelerate so fast that it 
might be there at 5 degrees of spindle rotation.  Instead it would ramp up much 
slower so that when it reaches the much slower Z axis speed it also has reached 
the 30 degree spindle position.
 
At that point it doesn't matter anymore as long as the Z axis tracks the 
spindle speed the tool bit will follow the previous thread.  
 
So what does LinuxCNC do?  Is the thread mucked up if spindle speed is changed 
during a feed hold and then start?
 
Thanks
John Dammeyer
 
"ELS! Nothing else works as well for your Lathe"
Automation Artisans Inc.
www dot autoartisans dot com 
 

___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users