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 
> 
> 
> ___
> 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 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
> >