Re: [Emc-developers] Hardware testing for improved spindle tracking jitter (issue 164)

[sam sokolik]

it is actually 10in/s^2 but correct on .5in/s velocity

On 11/26/2016 01:26 PM, Robert Ellenberg wrote:
> Sam, what are the max velocity and acceleration on the Z axis? It looks
> like 0.5 in / sec and 20 in/sec^2 from the plots. I want to match my sim
> configuration to yours.
>
> On Sat, Nov 26, 2016, 2:03 PM Robert Ellenberg  wrote:
>
>> Ahh, I'll take another look at the math, clearly it's not calculating the
>> max RPM correctly.
>>
>> On Sat, Nov 26, 2016 at 12:39 PM sam sokolik 
>> wrote:
>>
>> ok.. Here is some oddness..
>>
>> If I use the original pitch of P.059055 I get the error saying the
>> spindle should be running at 237rpm (the error I always get).
>>
>> pitch of .05 I don't get the error .06 I don't get the error .07 I
>> do get the error (but it threads at 19ish ipm) same error saying spindle
>> should be running at 237
>>
>> sam
>>
>> On 11/26/2016 11:19 AM, sam sokolik wrote:
>>> Here are 2 screenshots showing the threading at 15ipm and the shuttle at
>> 30.
>>> http://electronicsam.com/images/KandT/testing/robthreading/threading.png
>>> http://electronicsam.com/images/KandT/testing/robthreading/shuttle.png
>>>
>>> So I am not understanding why the threading would think that 237 is the
>>> maximum feed.
>>>
>>> Side note - this is running rt_preempt and uspace.  A base thread of
>>> 50us seems to work fine with the printer port.
>>>
>>> sam
>>>
>>>
>>> On 11/25/2016 09:24 PM, sam sokolik wrote:
 that is odd because the threading is done at about 16ipm - and the max
 velocity of the axis is 30ipm...  (you can see the z velocity goes
 higher than 16ipm in the plots)

 If there is anything else that would help to plot - let me know

 sam

 On 11/25/2016 08:25 PM, Robert Ellenberg wrote:
> Nice work! The message you're getting in axis is a new feature I
>> added. It
> warns you if the combination of spindle speed and thread pitch would
> require more than 90% of your maximum axis velocity. If so, it slows
>> the
> spindle down to a safe maximum speed before starting the thread (in
>> this
> case 230RPM). The 90% value is arbitrary, I just wanted to have some
>> safety
> factor in there.
>
> Comparing the two acceleration plots, it seems like the acceleration
>> during
> the start of the thread is higher in stock 2.7 than with my branch/ The
> high initial acceleration is good, though, since it settles in about
>> 120ms,
> whereas the new branch takes about 200ms. I'll run the same program in
> simulation tomorrow and see if I can reproduce the effect. It may be
>> worth
> trying the same comparison in G61 (in case blending is causing it).
>
> Best,
> Rob
>
> On Fri, Nov 25, 2016 at 8:37 PM sam sokolik 
>> wrote:
>> ok - I finally did some testing on the emco using this branch..
>>
>>
>>
>> https://github.com/robEllenberg/linuxcnc-mirror/commits/feature/nominal-vel-during-sync
>> This is a thread using this program
>> http://electronicsam.com/images/KandT/testing/robthreading/test.ngc
>>
>> This is the current 2.7 behavior
>>
>> http://electronicsam.com/images/KandT/testing/robthreading/current.png
>> This is with robs fixes
>>
>> http://electronicsam.com/images/KandT/testing/robthreading/robnew1.png
>> It looks like the acceleration spike are defiantly smaller.
>>
>> I did find an oddity on both branches - quite often it seemed to
>> overshoot initially and then slow back down.  I don't know if it is an
>> artifact of my config (100 line single channel encoder + index. never
>> seemed to effect the threading I have done.
>>
>>
>> http://electronicsam.com/images/KandT/testing/robthreading/current1.png
>> http://electronicsam.com/images/KandT/testing/robthreading/robnew.png
>>
>> Also - rob - it prints in axis every pass velocity at line 8 is 230rpm
>> or such.. (paraphrasing..)
>>
>> sam
>>
>>
>> On 09/25/2016 07:47 AM, Robert Ellenberg wrote:
>>> Hi All,
>>>
>>> Recently, I found a way to reduce the acceleration / velocity jitter
>> during
>>> threading and tapping motions (see this issue on github
>>>  and the
>>> feature/spindle-sync-jiiter-fix branch
>>> <
>> https://github.com/robEllenberg/linuxcnc-mirror/tree/feature/spindle-sync-jitter-fix
>>> ).
>>> The effect looks significant on the HALscope, but I'm not sure how
>> much
>> of
>>> a difference it would make on a real machine. Is anyone interested in
>> doing
>>> a before and after test on real hardware?
>>>
>>> Thanks!
>>> Rob
>>>
>> --
>>> ___
>>> Emc-developers mailing list
>>> 

Re: [Emc-developers] Hardware testing for improved spindle tracking jitter (issue 164)

[Robert Ellenberg]

Sam, what are the max velocity and acceleration on the Z axis? It looks
like 0.5 in / sec and 20 in/sec^2 from the plots. I want to match my sim
configuration to yours.

On Sat, Nov 26, 2016, 2:03 PM Robert Ellenberg  wrote:

> Ahh, I'll take another look at the math, clearly it's not calculating the
> max RPM correctly.
>
> On Sat, Nov 26, 2016 at 12:39 PM sam sokolik 
> wrote:
>
> ok.. Here is some oddness..
>
> If I use the original pitch of P.059055 I get the error saying the
> spindle should be running at 237rpm (the error I always get).
>
> pitch of .05 I don't get the error .06 I don't get the error .07 I
> do get the error (but it threads at 19ish ipm) same error saying spindle
> should be running at 237
>
> sam
>
> On 11/26/2016 11:19 AM, sam sokolik wrote:
> > Here are 2 screenshots showing the threading at 15ipm and the shuttle at
> 30.
> >
> > http://electronicsam.com/images/KandT/testing/robthreading/threading.png
> > http://electronicsam.com/images/KandT/testing/robthreading/shuttle.png
> >
> > So I am not understanding why the threading would think that 237 is the
> > maximum feed.
> >
> > Side note - this is running rt_preempt and uspace.  A base thread of
> > 50us seems to work fine with the printer port.
> >
> > sam
> >
> >
> > On 11/25/2016 09:24 PM, sam sokolik wrote:
> >> that is odd because the threading is done at about 16ipm - and the max
> >> velocity of the axis is 30ipm...  (you can see the z velocity goes
> >> higher than 16ipm in the plots)
> >>
> >> If there is anything else that would help to plot - let me know
> >>
> >> sam
> >>
> >> On 11/25/2016 08:25 PM, Robert Ellenberg wrote:
> >>> Nice work! The message you're getting in axis is a new feature I
> added. It
> >>> warns you if the combination of spindle speed and thread pitch would
> >>> require more than 90% of your maximum axis velocity. If so, it slows
> the
> >>> spindle down to a safe maximum speed before starting the thread (in
> this
> >>> case 230RPM). The 90% value is arbitrary, I just wanted to have some
> safety
> >>> factor in there.
> >>>
> >>> Comparing the two acceleration plots, it seems like the acceleration
> during
> >>> the start of the thread is higher in stock 2.7 than with my branch/ The
> >>> high initial acceleration is good, though, since it settles in about
> 120ms,
> >>> whereas the new branch takes about 200ms. I'll run the same program in
> >>> simulation tomorrow and see if I can reproduce the effect. It may be
> worth
> >>> trying the same comparison in G61 (in case blending is causing it).
> >>>
> >>> Best,
> >>> Rob
> >>>
> >>> On Fri, Nov 25, 2016 at 8:37 PM sam sokolik 
> wrote:
> >>>
>  ok - I finally did some testing on the emco using this branch..
> 
> 
> 
> https://github.com/robEllenberg/linuxcnc-mirror/commits/feature/nominal-vel-during-sync
> 
>  This is a thread using this program
>  http://electronicsam.com/images/KandT/testing/robthreading/test.ngc
> 
>  This is the current 2.7 behavior
> 
> http://electronicsam.com/images/KandT/testing/robthreading/current.png
> 
>  This is with robs fixes
> 
> http://electronicsam.com/images/KandT/testing/robthreading/robnew1.png
> 
>  It looks like the acceleration spike are defiantly smaller.
> 
>  I did find an oddity on both branches - quite often it seemed to
>  overshoot initially and then slow back down.  I don't know if it is an
>  artifact of my config (100 line single channel encoder + index. never
>  seemed to effect the threading I have done.
> 
> 
> http://electronicsam.com/images/KandT/testing/robthreading/current1.png
>  http://electronicsam.com/images/KandT/testing/robthreading/robnew.png
> 
>  Also - rob - it prints in axis every pass velocity at line 8 is 230rpm
>  or such.. (paraphrasing..)
> 
>  sam
> 
> 
>  On 09/25/2016 07:47 AM, Robert Ellenberg wrote:
> > Hi All,
> >
> > Recently, I found a way to reduce the acceleration / velocity jitter
>  during
> > threading and tapping motions (see this issue on github
> >  and the
> > feature/spindle-sync-jiiter-fix branch
> > <
> 
> https://github.com/robEllenberg/linuxcnc-mirror/tree/feature/spindle-sync-jitter-fix
> > ).
> > The effect looks significant on the HALscope, but I'm not sure how
> much
>  of
> > a difference it would make on a real machine. Is anyone interested in
>  doing
> > a before and after test on real hardware?
> >
> > Thanks!
> > Rob
> >
> 
> --
> > ___
> > Emc-developers mailing list
> > Emc-developers@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/emc-developers
> >
> 

Re: [Emc-developers] Hardware testing for improved spindle tracking jitter (issue 164)

[Robert Ellenberg]

Ahh, I'll take another look at the math, clearly it's not calculating the
max RPM correctly.

On Sat, Nov 26, 2016 at 12:39 PM sam sokolik  wrote:

> ok.. Here is some oddness..
>
> If I use the original pitch of P.059055 I get the error saying the
> spindle should be running at 237rpm (the error I always get).
>
> pitch of .05 I don't get the error .06 I don't get the error .07 I
> do get the error (but it threads at 19ish ipm) same error saying spindle
> should be running at 237
>
> sam
>
> On 11/26/2016 11:19 AM, sam sokolik wrote:
> > Here are 2 screenshots showing the threading at 15ipm and the shuttle at
> 30.
> >
> > http://electronicsam.com/images/KandT/testing/robthreading/threading.png
> > http://electronicsam.com/images/KandT/testing/robthreading/shuttle.png
> >
> > So I am not understanding why the threading would think that 237 is the
> > maximum feed.
> >
> > Side note - this is running rt_preempt and uspace.  A base thread of
> > 50us seems to work fine with the printer port.
> >
> > sam
> >
> >
> > On 11/25/2016 09:24 PM, sam sokolik wrote:
> >> that is odd because the threading is done at about 16ipm - and the max
> >> velocity of the axis is 30ipm...  (you can see the z velocity goes
> >> higher than 16ipm in the plots)
> >>
> >> If there is anything else that would help to plot - let me know
> >>
> >> sam
> >>
> >> On 11/25/2016 08:25 PM, Robert Ellenberg wrote:
> >>> Nice work! The message you're getting in axis is a new feature I
> added. It
> >>> warns you if the combination of spindle speed and thread pitch would
> >>> require more than 90% of your maximum axis velocity. If so, it slows
> the
> >>> spindle down to a safe maximum speed before starting the thread (in
> this
> >>> case 230RPM). The 90% value is arbitrary, I just wanted to have some
> safety
> >>> factor in there.
> >>>
> >>> Comparing the two acceleration plots, it seems like the acceleration
> during
> >>> the start of the thread is higher in stock 2.7 than with my branch/ The
> >>> high initial acceleration is good, though, since it settles in about
> 120ms,
> >>> whereas the new branch takes about 200ms. I'll run the same program in
> >>> simulation tomorrow and see if I can reproduce the effect. It may be
> worth
> >>> trying the same comparison in G61 (in case blending is causing it).
> >>>
> >>> Best,
> >>> Rob
> >>>
> >>> On Fri, Nov 25, 2016 at 8:37 PM sam sokolik 
> wrote:
> >>>
>  ok - I finally did some testing on the emco using this branch..
> 
> 
> 
> https://github.com/robEllenberg/linuxcnc-mirror/commits/feature/nominal-vel-during-sync
> 
>  This is a thread using this program
>  http://electronicsam.com/images/KandT/testing/robthreading/test.ngc
> 
>  This is the current 2.7 behavior
> 
> http://electronicsam.com/images/KandT/testing/robthreading/current.png
> 
>  This is with robs fixes
> 
> http://electronicsam.com/images/KandT/testing/robthreading/robnew1.png
> 
>  It looks like the acceleration spike are defiantly smaller.
> 
>  I did find an oddity on both branches - quite often it seemed to
>  overshoot initially and then slow back down.  I don't know if it is an
>  artifact of my config (100 line single channel encoder + index. never
>  seemed to effect the threading I have done.
> 
> 
> http://electronicsam.com/images/KandT/testing/robthreading/current1.png
>  http://electronicsam.com/images/KandT/testing/robthreading/robnew.png
> 
>  Also - rob - it prints in axis every pass velocity at line 8 is 230rpm
>  or such.. (paraphrasing..)
> 
>  sam
> 
> 
>  On 09/25/2016 07:47 AM, Robert Ellenberg wrote:
> > Hi All,
> >
> > Recently, I found a way to reduce the acceleration / velocity jitter
>  during
> > threading and tapping motions (see this issue on github
> >  and the
> > feature/spindle-sync-jiiter-fix branch
> > <
> 
> https://github.com/robEllenberg/linuxcnc-mirror/tree/feature/spindle-sync-jitter-fix
> > ).
> > The effect looks significant on the HALscope, but I'm not sure how
> much
>  of
> > a difference it would make on a real machine. Is anyone interested in
>  doing
> > a before and after test on real hardware?
> >
> > Thanks!
> > Rob
> >
> 
> --
> > ___
> > Emc-developers mailing list
> > Emc-developers@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/emc-developers
> >
> 
> --
>  ___
>  Emc-developers mailing list
>  Emc-developers@lists.sourceforge.net
>  

Re: [Emc-developers] Hardware testing for improved spindle tracking jitter (issue 164)

[sam sokolik]

Here are 2 screenshots showing the threading at 15ipm and the shuttle at 30.

http://electronicsam.com/images/KandT/testing/robthreading/threading.png
http://electronicsam.com/images/KandT/testing/robthreading/shuttle.png

So I am not understanding why the threading would think that 237 is the 
maximum feed.

Side note - this is running rt_preempt and uspace.  A base thread of 
50us seems to work fine with the printer port.

sam


On 11/25/2016 09:24 PM, sam sokolik wrote:
> that is odd because the threading is done at about 16ipm - and the max
> velocity of the axis is 30ipm...  (you can see the z velocity goes
> higher than 16ipm in the plots)
>
> If there is anything else that would help to plot - let me know
>
> sam
>
> On 11/25/2016 08:25 PM, Robert Ellenberg wrote:
>> Nice work! The message you're getting in axis is a new feature I added. It
>> warns you if the combination of spindle speed and thread pitch would
>> require more than 90% of your maximum axis velocity. If so, it slows the
>> spindle down to a safe maximum speed before starting the thread (in this
>> case 230RPM). The 90% value is arbitrary, I just wanted to have some safety
>> factor in there.
>>
>> Comparing the two acceleration plots, it seems like the acceleration during
>> the start of the thread is higher in stock 2.7 than with my branch/ The
>> high initial acceleration is good, though, since it settles in about 120ms,
>> whereas the new branch takes about 200ms. I'll run the same program in
>> simulation tomorrow and see if I can reproduce the effect. It may be worth
>> trying the same comparison in G61 (in case blending is causing it).
>>
>> Best,
>> Rob
>>
>> On Fri, Nov 25, 2016 at 8:37 PM sam sokolik  wrote:
>>
>>> ok - I finally did some testing on the emco using this branch..
>>>
>>>
>>> https://github.com/robEllenberg/linuxcnc-mirror/commits/feature/nominal-vel-during-sync
>>>
>>> This is a thread using this program
>>> http://electronicsam.com/images/KandT/testing/robthreading/test.ngc
>>>
>>> This is the current 2.7 behavior
>>> http://electronicsam.com/images/KandT/testing/robthreading/current.png
>>>
>>> This is with robs fixes
>>> http://electronicsam.com/images/KandT/testing/robthreading/robnew1.png
>>>
>>> It looks like the acceleration spike are defiantly smaller.
>>>
>>> I did find an oddity on both branches - quite often it seemed to
>>> overshoot initially and then slow back down.  I don't know if it is an
>>> artifact of my config (100 line single channel encoder + index. never
>>> seemed to effect the threading I have done.
>>>
>>> http://electronicsam.com/images/KandT/testing/robthreading/current1.png
>>> http://electronicsam.com/images/KandT/testing/robthreading/robnew.png
>>>
>>> Also - rob - it prints in axis every pass velocity at line 8 is 230rpm
>>> or such.. (paraphrasing..)
>>>
>>> sam
>>>
>>>
>>> On 09/25/2016 07:47 AM, Robert Ellenberg wrote:
 Hi All,

 Recently, I found a way to reduce the acceleration / velocity jitter
>>> during
 threading and tapping motions (see this issue on github
  and the
 feature/spindle-sync-jiiter-fix branch
 <
>>> https://github.com/robEllenberg/linuxcnc-mirror/tree/feature/spindle-sync-jitter-fix
 ).
 The effect looks significant on the HALscope, but I'm not sure how much
>>> of
 a difference it would make on a real machine. Is anyone interested in
>>> doing
 a before and after test on real hardware?

 Thanks!
 Rob

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

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


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

Re: [Emc-developers] Hardware testing for improved spindle tracking jitter (issue 164)

[sam sokolik]

that is odd because the threading is done at about 16ipm - and the max 
velocity of the axis is 30ipm...  (you can see the z velocity goes 
higher than 16ipm in the plots)

If there is anything else that would help to plot - let me know

sam

On 11/25/2016 08:25 PM, Robert Ellenberg wrote:
> Nice work! The message you're getting in axis is a new feature I added. It
> warns you if the combination of spindle speed and thread pitch would
> require more than 90% of your maximum axis velocity. If so, it slows the
> spindle down to a safe maximum speed before starting the thread (in this
> case 230RPM). The 90% value is arbitrary, I just wanted to have some safety
> factor in there.
>
> Comparing the two acceleration plots, it seems like the acceleration during
> the start of the thread is higher in stock 2.7 than with my branch/ The
> high initial acceleration is good, though, since it settles in about 120ms,
> whereas the new branch takes about 200ms. I'll run the same program in
> simulation tomorrow and see if I can reproduce the effect. It may be worth
> trying the same comparison in G61 (in case blending is causing it).
>
> Best,
> Rob
>
> On Fri, Nov 25, 2016 at 8:37 PM sam sokolik  wrote:
>
>> ok - I finally did some testing on the emco using this branch..
>>
>>
>> https://github.com/robEllenberg/linuxcnc-mirror/commits/feature/nominal-vel-during-sync
>>
>> This is a thread using this program
>> http://electronicsam.com/images/KandT/testing/robthreading/test.ngc
>>
>> This is the current 2.7 behavior
>> http://electronicsam.com/images/KandT/testing/robthreading/current.png
>>
>> This is with robs fixes
>> http://electronicsam.com/images/KandT/testing/robthreading/robnew1.png
>>
>> It looks like the acceleration spike are defiantly smaller.
>>
>> I did find an oddity on both branches - quite often it seemed to
>> overshoot initially and then slow back down.  I don't know if it is an
>> artifact of my config (100 line single channel encoder + index. never
>> seemed to effect the threading I have done.
>>
>> http://electronicsam.com/images/KandT/testing/robthreading/current1.png
>> http://electronicsam.com/images/KandT/testing/robthreading/robnew.png
>>
>> Also - rob - it prints in axis every pass velocity at line 8 is 230rpm
>> or such.. (paraphrasing..)
>>
>> sam
>>
>>
>> On 09/25/2016 07:47 AM, Robert Ellenberg wrote:
>>> Hi All,
>>>
>>> Recently, I found a way to reduce the acceleration / velocity jitter
>> during
>>> threading and tapping motions (see this issue on github
>>>  and the
>>> feature/spindle-sync-jiiter-fix branch
>>> <
>> https://github.com/robEllenberg/linuxcnc-mirror/tree/feature/spindle-sync-jitter-fix
>>> ).
>>> The effect looks significant on the HALscope, but I'm not sure how much
>> of
>>> a difference it would make on a real machine. Is anyone interested in
>> doing
>>> a before and after test on real hardware?
>>>
>>> Thanks!
>>> Rob
>>>
>> --
>>> ___
>>> Emc-developers mailing list
>>> Emc-developers@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/emc-developers
>>>
>>
>>
>> --
>> ___
>> Emc-developers mailing list
>> Emc-developers@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/emc-developers
>>
> --
> ___
> Emc-developers mailing list
> Emc-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-developers
>


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

Re: [Emc-developers] Hardware testing for improved spindle tracking jitter (issue 164)

[Robert Ellenberg]

Nice work! The message you're getting in axis is a new feature I added. It
warns you if the combination of spindle speed and thread pitch would
require more than 90% of your maximum axis velocity. If so, it slows the
spindle down to a safe maximum speed before starting the thread (in this
case 230RPM). The 90% value is arbitrary, I just wanted to have some safety
factor in there.

Comparing the two acceleration plots, it seems like the acceleration during
the start of the thread is higher in stock 2.7 than with my branch/ The
high initial acceleration is good, though, since it settles in about 120ms,
whereas the new branch takes about 200ms. I'll run the same program in
simulation tomorrow and see if I can reproduce the effect. It may be worth
trying the same comparison in G61 (in case blending is causing it).

Best,
Rob

On Fri, Nov 25, 2016 at 8:37 PM sam sokolik  wrote:

> ok - I finally did some testing on the emco using this branch..
>
>
> https://github.com/robEllenberg/linuxcnc-mirror/commits/feature/nominal-vel-during-sync
>
> This is a thread using this program
> http://electronicsam.com/images/KandT/testing/robthreading/test.ngc
>
> This is the current 2.7 behavior
> http://electronicsam.com/images/KandT/testing/robthreading/current.png
>
> This is with robs fixes
> http://electronicsam.com/images/KandT/testing/robthreading/robnew1.png
>
> It looks like the acceleration spike are defiantly smaller.
>
> I did find an oddity on both branches - quite often it seemed to
> overshoot initially and then slow back down.  I don't know if it is an
> artifact of my config (100 line single channel encoder + index. never
> seemed to effect the threading I have done.
>
> http://electronicsam.com/images/KandT/testing/robthreading/current1.png
> http://electronicsam.com/images/KandT/testing/robthreading/robnew.png
>
> Also - rob - it prints in axis every pass velocity at line 8 is 230rpm
> or such.. (paraphrasing..)
>
> sam
>
>
> On 09/25/2016 07:47 AM, Robert Ellenberg wrote:
> > Hi All,
> >
> > Recently, I found a way to reduce the acceleration / velocity jitter
> during
> > threading and tapping motions (see this issue on github
> >  and the
> > feature/spindle-sync-jiiter-fix branch
> > <
> https://github.com/robEllenberg/linuxcnc-mirror/tree/feature/spindle-sync-jitter-fix
> >).
> > The effect looks significant on the HALscope, but I'm not sure how much
> of
> > a difference it would make on a real machine. Is anyone interested in
> doing
> > a before and after test on real hardware?
> >
> > Thanks!
> > Rob
> >
> --
> > ___
> > Emc-developers mailing list
> > Emc-developers@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/emc-developers
> >
>
>
>
> --
> ___
> Emc-developers mailing list
> Emc-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-developers
>
--
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] Hardware testing for improved spindle tracking jitter (issue 164)

[sam sokolik]

ok - I finally did some testing on the emco using this branch..

https://github.com/robEllenberg/linuxcnc-mirror/commits/feature/nominal-vel-during-sync

This is a thread using this program
http://electronicsam.com/images/KandT/testing/robthreading/test.ngc

This is the current 2.7 behavior
http://electronicsam.com/images/KandT/testing/robthreading/current.png

This is with robs fixes
http://electronicsam.com/images/KandT/testing/robthreading/robnew1.png

It looks like the acceleration spike are defiantly smaller.

I did find an oddity on both branches - quite often it seemed to 
overshoot initially and then slow back down.  I don't know if it is an 
artifact of my config (100 line single channel encoder + index. never 
seemed to effect the threading I have done.

http://electronicsam.com/images/KandT/testing/robthreading/current1.png
http://electronicsam.com/images/KandT/testing/robthreading/robnew.png

Also - rob - it prints in axis every pass velocity at line 8 is 230rpm 
or such.. (paraphrasing..)

sam


On 09/25/2016 07:47 AM, Robert Ellenberg wrote:
> Hi All,
>
> Recently, I found a way to reduce the acceleration / velocity jitter during
> threading and tapping motions (see this issue on github
>  and the
> feature/spindle-sync-jiiter-fix branch
> ).
> The effect looks significant on the HALscope, but I'm not sure how much of
> a difference it would make on a real machine. Is anyone interested in doing
> a before and after test on real hardware?
>
> Thanks!
> Rob
> --
> ___
> Emc-developers mailing list
> Emc-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-developers
>


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

Re: [Emc-developers] Hardware testing for improved spindle tracking jitter (issue 164)

[Robert Ellenberg]

I just pushed some commits to this branch that implement a crude error
message:

https://github.com/robEllenberg/linuxcnc-mirror/tree/feature/nominal-vel-during-sync

I also opened an issue for this:

https://github.com/LinuxCNC/linuxcnc/issues/167

-Rob

On Fri, Sep 30, 2016 at 12:20 AM Robert Ellenberg  wrote:

> That's a good point, it's not a perfect solution. At least in the case you
> describe, it wouldn't be any worse than today. The spindle speed command
> would be ignored, the user would get a warning, and the motion would keep
> going.
>
> That to me a is a good reason to make this an interpreter error, so the
> user gets some advance notice. By the time the motion starts, it could be
> too late to save the thread.
>
> Rob
>
> On Thu, Sep 29, 2016, 11:32 AM Gene Heskett  wrote:
>
> On Thursday 29 September 2016 08:49:50 John Kasunich wrote:
>
> > On Wed, Sep 28, 2016, at 09:35 PM, Robert Ellenberg wrote:
> > > That would certainly be convenient. What if we took it one step
> > > further and automatically limit the maximum spindle speed for each
> > > G33 segment? It would be ugly, but we may be able to stuff a spindle
> > > speed command into the queue before adding the line segment.
> > > Combined with a message to the user than this is occurring, it would
> > > be both safe and convenient for the user.
> >
> > That assumes that the machine has active control over the spindle
> > speed. Which is NOT necessary for threading and other G33 work.
> >
> > For example, my lathe has 16 spindle speeds which are determined by
> > how you set the belts on the pulleys.  The S-word has absolutely no
> > effect on the speed.  It doesn't matter whether you write M3S100 or
> > M3S1, the spindle is going to start and run at the speed
> > determined by the belts.
> >
> > The spindle encoder tells LinuxCNC how fast the spindle is going and
> > thus allows for synchronized moves, but:
> >
> > 1) LinuxCNC can't change the speed if it doesn't like it
> > 2) LinuxCNC doesn't know the speed at the interp level, because the
> > S-word means nothing.  Only the encoder feedback can tell it the
> > spindle speed.
>
> I'll be in somewhat better shape with this Sheldon conversion John.
> Sure, mechanically I'll have the same old 8 speed spindle, backgear
> in/out plus 4 positions of the belt, but I'll also have a vfd running
> the 1 hp motor, replaceing its original 3/4 hp which had been fitted
> with a reverseing switch, which I'll likely have programmed for a 1/2 to
> 2 or 3x nameplate speed, so I'll have an ability to make use of such a
> feature.
>
> And depending on how fast the vfd can reverse it safely, G33.1 rigid
> tapping seems do-able.  Much better if I can start a tap drill for say a
> 1/4" bolt, centered on the mating face of the chucks backplate and the
> flange of the spindle it seats on, drill so half the hole is in the
> backplate and half in the spindle flange and tap the hole & put a bolt
> in it to lock the chuck so it can't be unscrewed by a quick reverse. I
> had to do that to the motor in TLM as the flywheel/fan/pulley is screwed
> to the motor shaft. I put 2 such bolts in it, 180 degrees apart. 1st
> mptor I used a 10-24 set screw, wrecked/crushed it and the shaft so the
> 2nd motor has 2 solid bolts in it.  Hasn't come loose yet. I've also put
> some ramping in the hal file to make the reversal a bit less violent.
>
> That limits the spindle speed for a g33.1 on TLM, but not from Z speed
> limits, but from turnaround overshoots, about 2.5 turns at 200 rpms in
> high gear, 4 or so turns in low gear because of the heavy motor
> flywheel. I've some hal stuff I can watch with a halmeter to tell me how
> many encoder counts this overshoot is so I can start the turnaround
> early enough I don't slip the tap or break it against the bottom of a
> blind hole.
>
> 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)
> Genes Web page 
>
>
> --
> ___
> Emc-developers mailing list
> Emc-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-developers
>
>
--
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] Hardware testing for improved spindle tracking jitter (issue 164)

[Robert Ellenberg]

That's a good point, it's not a perfect solution. At least in the case you
describe, it wouldn't be any worse than today. The spindle speed command
would be ignored, the user would get a warning, and the motion would keep
going.

That to me a is a good reason to make this an interpreter error, so the
user gets some advance notice. By the time the motion starts, it could be
too late to save the thread.

Rob

On Thu, Sep 29, 2016, 11:32 AM Gene Heskett  wrote:

> On Thursday 29 September 2016 08:49:50 John Kasunich wrote:
>
> > On Wed, Sep 28, 2016, at 09:35 PM, Robert Ellenberg wrote:
> > > That would certainly be convenient. What if we took it one step
> > > further and automatically limit the maximum spindle speed for each
> > > G33 segment? It would be ugly, but we may be able to stuff a spindle
> > > speed command into the queue before adding the line segment.
> > > Combined with a message to the user than this is occurring, it would
> > > be both safe and convenient for the user.
> >
> > That assumes that the machine has active control over the spindle
> > speed. Which is NOT necessary for threading and other G33 work.
> >
> > For example, my lathe has 16 spindle speeds which are determined by
> > how you set the belts on the pulleys.  The S-word has absolutely no
> > effect on the speed.  It doesn't matter whether you write M3S100 or
> > M3S1, the spindle is going to start and run at the speed
> > determined by the belts.
> >
> > The spindle encoder tells LinuxCNC how fast the spindle is going and
> > thus allows for synchronized moves, but:
> >
> > 1) LinuxCNC can't change the speed if it doesn't like it
> > 2) LinuxCNC doesn't know the speed at the interp level, because the
> > S-word means nothing.  Only the encoder feedback can tell it the
> > spindle speed.
>
> I'll be in somewhat better shape with this Sheldon conversion John.
> Sure, mechanically I'll have the same old 8 speed spindle, backgear
> in/out plus 4 positions of the belt, but I'll also have a vfd running
> the 1 hp motor, replaceing its original 3/4 hp which had been fitted
> with a reverseing switch, which I'll likely have programmed for a 1/2 to
> 2 or 3x nameplate speed, so I'll have an ability to make use of such a
> feature.
>
> And depending on how fast the vfd can reverse it safely, G33.1 rigid
> tapping seems do-able.  Much better if I can start a tap drill for say a
> 1/4" bolt, centered on the mating face of the chucks backplate and the
> flange of the spindle it seats on, drill so half the hole is in the
> backplate and half in the spindle flange and tap the hole & put a bolt
> in it to lock the chuck so it can't be unscrewed by a quick reverse. I
> had to do that to the motor in TLM as the flywheel/fan/pulley is screwed
> to the motor shaft. I put 2 such bolts in it, 180 degrees apart. 1st
> mptor I used a 10-24 set screw, wrecked/crushed it and the shaft so the
> 2nd motor has 2 solid bolts in it.  Hasn't come loose yet. I've also put
> some ramping in the hal file to make the reversal a bit less violent.
>
> That limits the spindle speed for a g33.1 on TLM, but not from Z speed
> limits, but from turnaround overshoots, about 2.5 turns at 200 rpms in
> high gear, 4 or so turns in low gear because of the heavy motor
> flywheel. I've some hal stuff I can watch with a halmeter to tell me how
> many encoder counts this overshoot is so I can start the turnaround
> early enough I don't slip the tap or break it against the bottom of a
> blind hole.
>
> 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)
> Genes Web page 
>
>
> --
> ___
> Emc-developers mailing list
> Emc-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-developers
>
--
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] Hardware testing for improved spindle tracking jitter (issue 164)

[Gene Heskett]

On Thursday 29 September 2016 08:49:50 John Kasunich wrote:

> On Wed, Sep 28, 2016, at 09:35 PM, Robert Ellenberg wrote:
> > That would certainly be convenient. What if we took it one step
> > further and automatically limit the maximum spindle speed for each
> > G33 segment? It would be ugly, but we may be able to stuff a spindle
> > speed command into the queue before adding the line segment.
> > Combined with a message to the user than this is occurring, it would
> > be both safe and convenient for the user.
>
> That assumes that the machine has active control over the spindle
> speed. Which is NOT necessary for threading and other G33 work.
>
> For example, my lathe has 16 spindle speeds which are determined by
> how you set the belts on the pulleys.  The S-word has absolutely no
> effect on the speed.  It doesn't matter whether you write M3S100 or
> M3S1, the spindle is going to start and run at the speed
> determined by the belts.
>
> The spindle encoder tells LinuxCNC how fast the spindle is going and
> thus allows for synchronized moves, but:
>
> 1) LinuxCNC can't change the speed if it doesn't like it
> 2) LinuxCNC doesn't know the speed at the interp level, because the
> S-word means nothing.  Only the encoder feedback can tell it the
> spindle speed.

I'll be in somewhat better shape with this Sheldon conversion John.  
Sure, mechanically I'll have the same old 8 speed spindle, backgear 
in/out plus 4 positions of the belt, but I'll also have a vfd running 
the 1 hp motor, replaceing its original 3/4 hp which had been fitted 
with a reverseing switch, which I'll likely have programmed for a 1/2 to 
2 or 3x nameplate speed, so I'll have an ability to make use of such a 
feature.

And depending on how fast the vfd can reverse it safely, G33.1 rigid 
tapping seems do-able.  Much better if I can start a tap drill for say a 
1/4" bolt, centered on the mating face of the chucks backplate and the 
flange of the spindle it seats on, drill so half the hole is in the 
backplate and half in the spindle flange and tap the hole & put a bolt 
in it to lock the chuck so it can't be unscrewed by a quick reverse. I 
had to do that to the motor in TLM as the flywheel/fan/pulley is screwed 
to the motor shaft. I put 2 such bolts in it, 180 degrees apart. 1st 
mptor I used a 10-24 set screw, wrecked/crushed it and the shaft so the 
2nd motor has 2 solid bolts in it.  Hasn't come loose yet. I've also put 
some ramping in the hal file to make the reversal a bit less violent. 

That limits the spindle speed for a g33.1 on TLM, but not from Z speed 
limits, but from turnaround overshoots, about 2.5 turns at 200 rpms in 
high gear, 4 or so turns in low gear because of the heavy motor 
flywheel. I've some hal stuff I can watch with a halmeter to tell me how 
many encoder counts this overshoot is so I can start the turnaround 
early enough I don't slip the tap or break it against the bottom of a 
blind hole.

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)
Genes Web page 

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

Re: [Emc-developers] Hardware testing for improved spindle tracking jitter (issue 164)

[John Kasunich]

On Wed, Sep 28, 2016, at 09:35 PM, Robert Ellenberg wrote:
> That would certainly be convenient. What if we took it one step further and
> automatically limit the maximum spindle speed for each G33 segment? It
> would be ugly, but we may be able to stuff a spindle speed command into the
> queue before adding the line segment. Combined with a message to the user
> than this is occurring, it would be both safe and convenient for the user.

That assumes that the machine has active control over the spindle speed.
Which is NOT necessary for threading and other G33 work.

For example, my lathe has 16 spindle speeds which are determined by how
you set the belts on the pulleys.  The S-word has absolutely no effect on the
speed.  It doesn't matter whether you write M3S100 or M3S1, the spindle
is going to start and run at the speed determined by the belts.

The spindle encoder tells LinuxCNC how fast the spindle is going and
thus allows for synchronized moves, but:

1) LinuxCNC can't change the speed if it doesn't like it
2) LinuxCNC doesn't know the speed at the interp level, because the S-word
means nothing.  Only the encoder feedback can tell it the spindle speed.


-- 
  John Kasunich
  jmkasun...@fastmail.fm

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

Re: [Emc-developers] Hardware testing for improved spindle tracking jitter (issue 164)

[andy pugh]

On 29 September 2016 at 02:35, Robert Ellenberg  wrote:

> That would certainly be convenient. What if we took it one step further and
> automatically limit the maximum spindle speed for each G33 segment?
> 
>

If like me, they have a gearbox, and doing so it causes some other "thing"
the they might be upset. But the point is that they have actually messed up
by asking the machine to do something that _they_ have told LinuxCNC the
machine can't do.

So, yes, dropping spindle speed and explaining why does seem like quite an
elegant solution. In my day job we would cal that a "Surprise and delight"
 feature. Most users would thing "Ooh, that's clever"

-- 
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, 1916
--
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] Hardware testing for improved spindle tracking jitter (issue 164)

[Robert Ellenberg]

That would certainly be convenient. What if we took it one step further and
automatically limit the maximum spindle speed for each G33 segment? It
would be ugly, but we may be able to stuff a spindle speed command into the
queue before adding the line segment. Combined with a message to the user
than this is occurring, it would be both safe and convenient for the user.

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

Re: [Emc-developers] Hardware testing for improved spindle tracking jitter (issue 164)

[andy pugh]

On 29 September 2016 at 01:51, Robert Ellenberg  wrote:

>
> Ideally, I'd like to have the interpreter catch the error, so that we get
> as much advance warning as possible.  Doing so is a bit tricky, because the
> error condition happens fairly deep within canon. This means either
> throwing an exception, or changing a few canon calls to return error codes.


I was originally thinking that just giving up was the right behaviour. But,
thinking about it, an error message could, in theory, suggest using spindle
override to reduce the spindle speed, and then the cycle could start when
there was 10% overhead.
I think users would prefer that.

-- 
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, 1916
--
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] Hardware testing for improved spindle tracking jitter (issue 164)

[Robert Ellenberg]

On Wed, Sep 28, 2016 at 8:41 PM andy pugh  wrote:

> On 29 September 2016 at 01:36, andy pugh  wrote:
>
> >
> > I approve of this warning, definitely.
> > Given that (as far as I can guess) nobody ever prefers to make a bad
> > thread than no thread, could the warning abort all motion?
> >
>
> (Supplementary thought). It's a following error.  We abort those hard.
> Maybe trigger on the same error with the same message?
>

It would be nice to force the machine to stop at that point. The problem is
that by the time the error is triggered (currently), it's already in
cutting position, and stopping hard might do even more damage.

Ideally, I'd like to have the interpreter catch the error, so that we get
as much advance warning as possible.  Doing so is a bit tricky, because the
error condition happens fairly deep within canon. This means either
throwing an exception, or changing a few canon calls to return error codes.

-Rob

--
> 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, 1916
>
> --
> ___
> Emc-developers mailing list
> Emc-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-developers
>
--
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] Hardware testing for improved spindle tracking jitter (issue 164)

[andy pugh]

On 29 September 2016 at 01:30, Robert Ellenberg  wrote:

> This branch also adds a canon-level warning if the user tries to start a
> G33 move that isn't capable of reaching the required feed. Unfortunately,
> the warning only appears when the motion starts, but it's better than
> nothing.
>

I approve of this warning, definitely.
Given that (as far as I can guess) nobody ever prefers to make a bad thread
than no thread, could the warning abort all motion?


-- 
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, 1916
--
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] Hardware testing for improved spindle tracking jitter (issue 164)

[Robert Ellenberg]

Update: I've combined my fix for Issue 68
 with the jitter
improvement in this branch (also pushed to the official repo for the
buildbot):

https://github.com/robEllenberg/linuxcnc-mirror/tree/feature/nominal-vel-during-sync

This branch also adds a canon-level warning if the user tries to start a
G33 move that isn't capable of reaching the required feed. Unfortunately,
the warning only appears when the motion starts, but it's better than
nothing.

Together, these fixes should resolve issue 68 without any
backwards-incompatible changes to the 2.7 TP.

-Rob

On Mon, Sep 26, 2016 at 10:32 AM Gene Heskett  wrote:

> On Monday 26 September 2016 08:22:23 Robert Ellenberg wrote:
>
> > Hi Kirk,
> >
> > The best way to compare would be Z acceleration. It's easy to add to
> > the HAL file (needs an extra differentiator). Then, we can look
> > directly at the magnitudes of acceleration. Lower amplitude = less
> > jitter.
> >
> > On a slight tangent what do you think of adding a warning / error if
> > the TP can't reach the requested feed in G33 moves? It seems that if
> > you're doing threading, close enough is not good enough in terms of
> > tracking. The user might want to know before they cut that the spindle
> > speed or feed / rev is too high.
> >
> Field report:
>
> I actually ran into this on my G0704 when I had that 1600oz/in motor on
> the Z.  Because the tap in the spindle was a 1/2" 13 tpi, I had visions
> of doing a peck tap that was a small enough peck that the stored energy
> in the 800 rpm spindle would contribute to the cutting. But that 800
> exceeded the Z maxvel with that motor which was around 28 IPM.  So I had
> to slow it down.  At 400 the tap slipped after about 3/4 turn into the
> work, which I caught, backed it out and put a tap handle on the tap &
> finished the hole by hand.
>
> That was when I questioned the list for a tap holder that would grab the
> square butt of the tap, but even in R8, which is keyed to the spindle, I
> was not able to source a tap holder I could afford. All north of a 100$
> bill and to cover all the taps I might use I would have blown a kilobuck
> or more.
>
> I even knocked the T handle out of a hand tapper that looked promising,
> but it was, when chucked up, about 5mm's out of plumb with its own
> knurled nut on the other end. So bad I never put a tap in it, I'd have
> broken the tap pushing it into line with the hole.  The pick any 2 rule
> hard at work...
>
> Even with Jon Elson's driver making a horse and a half, maybe 2 out of
> that 1 horse, the spindles low gear still couldn't turn that tap
> steadily to the bottom of the hole, not enough geardown. 800 revs was
> about 55% of wide open in low gear. Its about a 2/1 gearchange, and the
> motor rated at 1 hp at 2250 revs stock in high gear when driven by the
> OEM driver, can be driven to 2850 with a 126 volt dc supply which is
> current limited in the amp setup to about 16 amps. How many hp is that?
>
> And yes, I do recognize the singing when it limits. Even TLM does it at
> startup.  The gears in the G0704's head seem to be holding, but the
> roller skate bearings in the head are destroying their ball cages. I am
> hoping it hangs in there till I get this Sheldon working. :(  That lack
> of turn a tap torque is why the new brass gib on the front of the
> Sheldon saddle will have a row of 4mm cap screws holding it. The saddle
> castings front edge is not IMO, robust enough to do that job if
> perforated for a row of 1/4" cap screws. So I figure a 4mm cap screw
> about every 2 cm is about what the Dr. would order. It will need a few
> thou of shimming. That I can cut from what Ed Nisley was nice enough to
> send me, and punch the bolt holes with a paper punch.
>
> Thanks Robert.
>
> [...]
>
> 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)
> Genes Web page 
>
>
> --
> ___
> Emc-developers mailing list
> Emc-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-developers
>
--
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] Hardware testing for improved spindle tracking jitter (issue 164)

[Gene Heskett]

On Monday 26 September 2016 08:22:23 Robert Ellenberg wrote:

> Hi Kirk,
>
> The best way to compare would be Z acceleration. It's easy to add to
> the HAL file (needs an extra differentiator). Then, we can look
> directly at the magnitudes of acceleration. Lower amplitude = less
> jitter.
>
> On a slight tangent what do you think of adding a warning / error if
> the TP can't reach the requested feed in G33 moves? It seems that if
> you're doing threading, close enough is not good enough in terms of
> tracking. The user might want to know before they cut that the spindle
> speed or feed / rev is too high.
>
Field report:

I actually ran into this on my G0704 when I had that 1600oz/in motor on 
the Z.  Because the tap in the spindle was a 1/2" 13 tpi, I had visions 
of doing a peck tap that was a small enough peck that the stored energy 
in the 800 rpm spindle would contribute to the cutting. But that 800 
exceeded the Z maxvel with that motor which was around 28 IPM.  So I had 
to slow it down.  At 400 the tap slipped after about 3/4 turn into the 
work, which I caught, backed it out and put a tap handle on the tap & 
finished the hole by hand.

That was when I questioned the list for a tap holder that would grab the 
square butt of the tap, but even in R8, which is keyed to the spindle, I 
was not able to source a tap holder I could afford. All north of a 100$ 
bill and to cover all the taps I might use I would have blown a kilobuck 
or more.

I even knocked the T handle out of a hand tapper that looked promising, 
but it was, when chucked up, about 5mm's out of plumb with its own 
knurled nut on the other end. So bad I never put a tap in it, I'd have 
broken the tap pushing it into line with the hole.  The pick any 2 rule 
hard at work...

Even with Jon Elson's driver making a horse and a half, maybe 2 out of 
that 1 horse, the spindles low gear still couldn't turn that tap 
steadily to the bottom of the hole, not enough geardown. 800 revs was 
about 55% of wide open in low gear. Its about a 2/1 gearchange, and the 
motor rated at 1 hp at 2250 revs stock in high gear when driven by the 
OEM driver, can be driven to 2850 with a 126 volt dc supply which is 
current limited in the amp setup to about 16 amps. How many hp is that?

And yes, I do recognize the singing when it limits. Even TLM does it at 
startup.  The gears in the G0704's head seem to be holding, but the 
roller skate bearings in the head are destroying their ball cages. I am 
hoping it hangs in there till I get this Sheldon working. :(  That lack 
of turn a tap torque is why the new brass gib on the front of the 
Sheldon saddle will have a row of 4mm cap screws holding it. The saddle 
castings front edge is not IMO, robust enough to do that job if 
perforated for a row of 1/4" cap screws. So I figure a 4mm cap screw 
about every 2 cm is about what the Dr. would order. It will need a few 
thou of shimming. That I can cut from what Ed Nisley was nice enough to 
send me, and punch the bolt holes with a paper punch.

Thanks Robert.

[...]

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)
Genes Web page 

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

Re: [Emc-developers] Hardware testing for improved spindle tracking jitter (issue 164)

[Robert Ellenberg]

Hi Kirk,

The best way to compare would be Z acceleration. It's easy to add to the
HAL file (needs an extra differentiator). Then, we can look directly at the
magnitudes of acceleration. Lower amplitude = less jitter.

On a slight tangent what do you think of adding a warning / error if the TP
can't reach the requested feed in G33 moves? It seems that if you're doing
threading, close enough is not good enough in terms of tracking. The user
might want to know before they cut that the spindle speed or feed / rev is
too high.

On Sun, Sep 25, 2016, 10:45 PM Kirk Wallace 
wrote:

> On 09/25/2016 04:46 PM, Robert Ellenberg wrote:
> > Hi Kirk,
> >
> > Thanks for giving it a run! It is hard to tell if it's an improvement,
> but
> > it does look like it's tracking smoothly, It would likely help to compare
> > the same run without the patch to see if the velocity jitters more.
>
> Oops, I'm sorry, what I posted was a run of the stock LinuxCNC on my
> lathe as a baseline. I haven't installed your fork yet. At this point I
> think I have two tasks, update to Jon's timestamp feature and also try
> your fork. If you can give me a hint for what to look for that may help,
> or I'll look at the issue entries and go from there.
>
> I seem to recall, quite a few years back my threading on this lathe was
> very unstable at the start of the thread. I think synchronized threading
> was fairly new, and someone on the list said to try the new (now old)
> version. Since then threading has worked very well. Jon's timestamp
> feature has been around for a while, but I haven't used my lathe much
> until recently.
>
>
> --
> Kirk Wallace
> http://www.wallacecompany.com/machine_shop/
> http://www.wallacecompany.com/E45/
>
>
> --
> ___
> Emc-developers mailing list
> Emc-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-developers
>
--
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] Hardware testing for improved spindle tracking jitter (issue 164)

[andy pugh]

On 26 September 2016 at 01:31, Robert Ellenberg  wrote:

> I'm glad that it's running well now. It would be cool to find a machine
> that's borderline and see if the patch makes it run smoother.
>

This one (from the LinuxCNC Showcase) actually sounds a little borderline:
https://www.youtube.com/watch?v=zdCQ0X7b2uo


-- 
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, 1916
--
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] Hardware testing for improved spindle tracking jitter (issue 164)

[Jon Elson]

On 09/25/2016 09:41 PM, Kirk Wallace wrote:
> On 09/25/2016 04:46 PM, Robert Ellenberg wrote:
>> Hi Kirk,
>>
>> Thanks for giving it a run! It is hard to tell if it's an improvement, but
>> it does look like it's tracking smoothly, It would likely help to compare
>> the same run without the patch to see if the velocity jitters more.
> Oops, I'm sorry, what I posted was a run of the stock LinuxCNC on my
> lathe as a baseline. I haven't installed your fork yet. At this point I
> think I have two tasks, update to Jon's timestamp feature
The timestamp feature requires firmware in the UPC board 
that supports it.  The USC (stepper controller) does not 
support it at all.  Newer UPCs (PWM controller) do support 
it, but your board SN0035 was bought in 2007, and cannot be 
updated, due to the FPGA being 2 generations out of date.  
(If you have  a newer board, pardon me, but those are the 
ones I see in my database.)

Jon

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

Re: [Emc-developers] Hardware testing for improved spindle tracking jitter (issue 164)

[Kirk Wallace]

On 09/25/2016 04:46 PM, Robert Ellenberg wrote:
> Hi Kirk,
>
> Thanks for giving it a run! It is hard to tell if it's an improvement, but
> it does look like it's tracking smoothly, It would likely help to compare
> the same run without the patch to see if the velocity jitters more.

Oops, I'm sorry, what I posted was a run of the stock LinuxCNC on my 
lathe as a baseline. I haven't installed your fork yet. At this point I 
think I have two tasks, update to Jon's timestamp feature and also try 
your fork. If you can give me a hint for what to look for that may help, 
or I'll look at the issue entries and go from there.

I seem to recall, quite a few years back my threading on this lathe was 
very unstable at the start of the thread. I think synchronized threading 
was fairly new, and someone on the list said to try the new (now old) 
version. Since then threading has worked very well. Jon's timestamp 
feature has been around for a while, but I haven't used my lathe much 
until recently.


-- 
Kirk Wallace
http://www.wallacecompany.com/machine_shop/
http://www.wallacecompany.com/E45/

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

Re: [Emc-developers] Hardware testing for improved spindle tracking jitter (issue 164)

[Robert Ellenberg]

I'm glad that it's running well now. It would be cool to find a machine
that's borderline and see if the patch makes it run smoother.

On Sun, Sep 25, 2016, 8:00 PM andy pugh  wrote:

> On 26 September 2016 at 00:46, Robert Ellenberg  wrote:
>
> > Thanks for giving it a run! It is hard to tell if it's an improvement,
> but
> > it does look like it's tracking smoothly, It would likely help to compare
> > the same run without the patch to see if the velocity jitters more.
> >
>
> I used to have a terribly jittery machine during threading, it was almost
> funny how bad it was. But various improvements to the software and the
> hardware fixed it.
> I don't seem to have any of the videos any more, either.
>
> --
> 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, 1916
>
> --
> ___
> Emc-developers mailing list
> Emc-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-developers
>
--
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] Hardware testing for improved spindle tracking jitter (issue 164)

[andy pugh]

On 26 September 2016 at 00:46, Robert Ellenberg  wrote:

> Thanks for giving it a run! It is hard to tell if it's an improvement, but
> it does look like it's tracking smoothly, It would likely help to compare
> the same run without the patch to see if the velocity jitters more.
>

I used to have a terribly jittery machine during threading, it was almost
funny how bad it was. But various improvements to the software and the
hardware fixed it.
I don't seem to have any of the videos any more, either.

-- 
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, 1916
--
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] Hardware testing for improved spindle tracking jitter (issue 164)

[Robert Ellenberg]

Hi Kirk,

Thanks for giving it a run! It is hard to tell if it's an improvement, but
it does look like it's tracking smoothly, It would likely help to compare
the same run without the patch to see if the velocity jitters more.

On Sun, Sep 25, 2016 at 5:41 PM Kirk Wallace 
wrote:

> On 09/25/2016 11:21 AM, Jon Elson wrote:
> > On 09/25/2016 11:52 AM, Kirk Wallace wrote:
> >> Hmm... I found this which means I need to look a little
> >> closer at my pin list: "... (All float output)
> >> 'ppmc..encoder..velocity - Velocity scaled
> >> in user units per second. On PPMC and USC this is derived
> >> from raw encoder counts per servo period, and hence is
> >> affected by encoder granularity. On UPC boards with the
> >> 8/21/09 and later firmware, velocity estimation by
> >> timestamping encoder counts can be used to improve the
> >> smoothness of this velocity output. This can be fed to the
> >> PID HAL component to produce a more stable servo response.
> >> This function has to be enabled in the HAL command line
> >> that starts the PPMC driver, with the timestamp=0x00
> >> option. ..."
> > On older PWM boards without the timestamp feature, and all
> > USC boards, velocity is just delta scaled by the the encoder
> > scale factor.  On the newer PWM and PPMC boards with the
> > timestamp feature, then the velocity is smoothed by
> > estimation based on time since the last encoder count.  This
> > is considerably smoother than velocity derived from delta,
> > which is just current position - last position, and this
> > quite noisy.
>
> (My last message went to moderation due to the attachments, I made them
> smaller on this one)
> For fun I attached a screen shot of my HNC lathe running the G33 code
> Rob posted. I don't have a Z acceleration pin so I have Z velocity on
> the bottom trace and the spindle encoder velocity on top, at two
> resolutions.  I don't know if this indicates anything with Rob's issue.
>
>
> --
> Kirk Wallace
> http://www.wallacecompany.com/machine_shop/
> http://www.wallacecompany.com/E45/
>
> --
> ___
> Emc-developers mailing list
> Emc-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-developers
>
--
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] Hardware testing for improved spindle tracking jitter (issue 164)

[Kirk Wallace]

On 09/25/2016 11:21 AM, Jon Elson wrote:

On 09/25/2016 11:52 AM, Kirk Wallace wrote:

Hmm... I found this which means I need to look a little
closer at my pin list: "... (All float output)
'ppmc..encoder..velocity - Velocity scaled
in user units per second. On PPMC and USC this is derived
from raw encoder counts per servo period, and hence is
affected by encoder granularity. On UPC boards with the
8/21/09 and later firmware, velocity estimation by
timestamping encoder counts can be used to improve the
smoothness of this velocity output. This can be fed to the
PID HAL component to produce a more stable servo response.
This function has to be enabled in the HAL command line
that starts the PPMC driver, with the timestamp=0x00
option. ..."

On older PWM boards without the timestamp feature, and all
USC boards, velocity is just delta scaled by the the encoder
scale factor.  On the newer PWM and PPMC boards with the
timestamp feature, then the velocity is smoothed by
estimation based on time since the last encoder count.  This
is considerably smoother than velocity derived from delta,
which is just current position - last position, and this
quite noisy.


(My last message went to moderation due to the attachments, I made them 
smaller on this one)
For fun I attached a screen shot of my HNC lathe running the G33 code 
Rob posted. I don't have a Z acceleration pin so I have Z velocity on 
the bottom trace and the spindle encoder velocity on top, at two 
resolutions.  I don't know if this indicates anything with Rob's issue.



--
Kirk Wallace
http://www.wallacecompany.com/machine_shop/
http://www.wallacecompany.com/E45/
--
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] Hardware testing for improved spindle tracking jitter (issue 164)

[Jon Elson]

On 09/25/2016 11:52 AM, Kirk Wallace wrote:
> Hmm... I found this which means I need to look a little 
> closer at my pin list: "... (All float output) 
> 'ppmc..encoder..velocity - Velocity scaled 
> in user units per second. On PPMC and USC this is derived 
> from raw encoder counts per servo period, and hence is 
> affected by encoder granularity. On UPC boards with the 
> 8/21/09 and later firmware, velocity estimation by 
> timestamping encoder counts can be used to improve the 
> smoothness of this velocity output. This can be fed to the 
> PID HAL component to produce a more stable servo response. 
> This function has to be enabled in the HAL command line 
> that starts the PPMC driver, with the timestamp=0x00 
> option. ..." 
On older PWM boards without the timestamp feature, and all 
USC boards, velocity is just delta scaled by the the encoder 
scale factor.  On the newer PWM and PPMC boards with the 
timestamp feature, then the velocity is smoothed by 
estimation based on time since the last encoder count.  This 
is considerably smoother than velocity derived from delta, 
which is just current position - last position, and this 
quite noisy.

Jon

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

Re: [Emc-developers] Hardware testing for improved spindle tracking jitter (issue 164)

[Robert Ellenberg]

Thanks to you both! I just pushed the branch of the same name to the
official repo. Unfortunately, it looks like the buildbot queue has stalled
on this build:

http://buildbot.linuxcnc.org/buildbot/builders/.checkin/builds/4528

Once it gets through the queue, though, my branch should have a build
available.

On Sun, Sep 25, 2016 at 11:41 AM Gene Heskett  wrote:

> On Sunday 25 September 2016 08:47:13 Robert Ellenberg wrote:
>
> > Hi All,
> >
> > Recently, I found a way to reduce the acceleration / velocity jitter
> > during threading and tapping motions (see this issue on github
> >  and the
> > feature/spindle-sync-jiiter-fix branch
> >  >sync-jitter-fix>). The effect looks significant on the HALscope, but
> > I'm not sure how much of a difference it would make on a real machine.
> > Is anyone interested in doing a before and after test on real
> > hardware?
> >
> I am in the middle of converting a Sheldon 11x36, and finding I need to
> make everything but most of the bolts.  Otherwise I'd be up for it in a
> heartbeat.
>
> > Thanks!
> > Rob
>
> I hadn't seen the github posts, but will look. And the 1st link is
> exactly what I've been fighting with. Enough Pgain to be usefull and its
> hammering the headstock gears. Fiddling with the opto spacings helps, as
> does a brghtness pot to each opto's led. But there is no true null
> point, ever.
>
> What I've now done is a bit of filtering on the two, soon to be 3
> machines that have a spindle encoder, but it does so at the cost of 2 to
> 4 edges worth of delay of the encoder output fed back to the PID. I am
> running the position data thru a 4 stage fifo I've constructed out of
> hal modules, with the feedback to the PID being the unity gain sum of
> those 4 fifo buckets.  Timing and sequencing being controlled by the
> addf order such that its output is available without any additional
> delays caused by miss-ordering in the servo-thread period.  At low
> spindle speeds, the update of the fifo is done only if an edge has been
> detected, fifo update triggered by an unequal from a comp module,
> looking at the last data and the current data.  It works well, reducing
> that noise by /4, allowing more Pgain, and hasn't seemed to have
> affected rigid tapping operations unless thats why a peck cycle cuts a
> looser tap. I have noted that using cheap taps that I have to back out,
> clean and anoint about every turn. But I have blamed the majority of
> those problems on the fact that cheap taps aren't straight.  Cheap,
> straight and sharp, pick any 2. :(
>
> Thank you very much for taking a look at this Robert.
>
> Are you running a buildbot, the output of which is available to apt-get
> etc? That would make it much easier tested here.
>
> 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)
> Genes Web page 
>
>
> --
> ___
> Emc-developers mailing list
> Emc-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-developers
>
--
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] Hardware testing for improved spindle tracking jitter (issue 164)

[Gene Heskett]

On Sunday 25 September 2016 08:47:13 Robert Ellenberg wrote:

> Hi All,
>
> Recently, I found a way to reduce the acceleration / velocity jitter
> during threading and tapping motions (see this issue on github
>  and the
> feature/spindle-sync-jiiter-fix branch
> sync-jitter-fix>). The effect looks significant on the HALscope, but
> I'm not sure how much of a difference it would make on a real machine.
> Is anyone interested in doing a before and after test on real
> hardware?
>
I am in the middle of converting a Sheldon 11x36, and finding I need to 
make everything but most of the bolts.  Otherwise I'd be up for it in a 
heartbeat.

> Thanks!
> Rob

I hadn't seen the github posts, but will look. And the 1st link is 
exactly what I've been fighting with. Enough Pgain to be usefull and its 
hammering the headstock gears. Fiddling with the opto spacings helps, as 
does a brghtness pot to each opto's led. But there is no true null 
point, ever.

What I've now done is a bit of filtering on the two, soon to be 3 
machines that have a spindle encoder, but it does so at the cost of 2 to 
4 edges worth of delay of the encoder output fed back to the PID. I am 
running the position data thru a 4 stage fifo I've constructed out of 
hal modules, with the feedback to the PID being the unity gain sum of 
those 4 fifo buckets.  Timing and sequencing being controlled by the 
addf order such that its output is available without any additional 
delays caused by miss-ordering in the servo-thread period.  At low 
spindle speeds, the update of the fifo is done only if an edge has been 
detected, fifo update triggered by an unequal from a comp module, 
looking at the last data and the current data.  It works well, reducing 
that noise by /4, allowing more Pgain, and hasn't seemed to have 
affected rigid tapping operations unless thats why a peck cycle cuts a 
looser tap. I have noted that using cheap taps that I have to back out, 
clean and anoint about every turn. But I have blamed the majority of 
those problems on the fact that cheap taps aren't straight.  Cheap, 
straight and sharp, pick any 2. :(

Thank you very much for taking a look at this Robert.

Are you running a buildbot, the output of which is available to apt-get 
etc? That would make it much easier tested here.

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)
Genes Web page 

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

Re: [Emc-developers] Hardware testing for improved spindle tracking jitter (issue 164)

[Kirk Wallace]

On 09/25/2016 05:47 AM, Robert Ellenberg wrote:
> Hi All,
>
> Recently, I found a way to reduce the acceleration / velocity jitter during
> threading and tapping motions (see this issue on github
>  and the
> feature/spindle-sync-jiiter-fix branch
> ).
> The effect looks significant on the HALscope, but I'm not sure how much of
> a difference it would make on a real machine. Is anyone interested in doing
> a before and after test on real hardware?

I added tapered threading to G76 to my local 2.7.6 branch. I had 
concerns that the transitions between up to three synchronized path 
sections might not be handled well. My tests with 1/8 NPT and .25-20 
straight threads with end taper worked well, but these probably would 
tolerate some variation. The end tapers usually don't mate with 
anything. I wanted to see what HALscope might show at these path 
transitions, but I didn't see any velocity HALpins, off hand, on my Pico 
servo setup, and I haven't taken the time to go any further on this. I 
would like to, maybe in the coming week. I can look at your issue while 
I'm at it.

http://www.wallacecompany.com/cnc_lathe/HNC/

http://www.wallacecompany.com/cnc_lathe/HNC/
(BTW, I had to repair this encoder. The local voltage regulator was 
going into thermal shutdown, but I could not find excess current going 
into the near or far end of the cable. It turned out that I had old 
tantalum capacitors on the voltage regulator input and output that were 
going bad. I replaced the regulator with a high current version and 
smoked a tantalum, therefore indicating the problem. Not the most 
elegant trouble shooting, but finally found the problem.)

-- 
Kirk Wallace
http://www.wallacecompany.com/machine_shop/
http://www.wallacecompany.com/E45/

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