Re: [Emc-developers] Spindle speed signal

[Robert Ellenberg]

That sounds right, it's a queue buster because of the spindle speed change,
so it acts like exact stop. I'm still not sure why it's capping the speed
at 237RPM.
Your outputs make sense (~19 ipm at ~270RPM actual speed is about 0.07 in /
rev). I'll poke around some more and see what I can find. Thanks again for
putting it through its paces!

On Wed, Dec 14, 2016 at 8:58 PM sam sokolik  wrote:

> oh - what - did you mention you get exact stop when it is trying to
> change the spindle speed?  Is that why it is happening on this system?
>
> sam
>
> On 12/14/2016 05:56 PM, sam sokolik wrote:
> > Here is a plot with motion.spindle-speed-in
> >
> >
> http://electronicsam.com/images/KandT/testing/robthreading/latest/robnewandspindlein.png
> >
> > sam
> >
> >
> >
> > On 12/11/2016 03:52 PM, Robert Ellenberg wrote:
> >> Sam, one last thing, is it possible to put the spindle-speed-in pin on a
> >> halscope channel? I'd like to see what the spindle velocity is when it
> >> transitions out of accel sync.
> >>
> >> On Sun, Dec 11, 2016 at 4:44 PM Robert Ellenberg 
> wrote:
> >>
> >>> Thanks for giving it a spin!
> >>>
> >>> I am still getting the error about the spindle going too fast..  You
> can
> >>> see the threading is happening at 19.12 ipm and the axis max vel is
> >>> 30ipm.  I tried a similar config and got the same result (could be both
> >>> configs have some odd issue we have not figured out.)
> >>>
> >>>
> http://electronicsam.com/images/KandT/testing/robthreading/latest/newthreadingfix2Error.png
> >>>
> >>>
> >>> There's definitely an edge case there I didn't account for. I'll keep
> >>> working on it and see if I can isolate a test case to reproduce.
> >>>
> >>> Current 2.7 behavior with the blip at the beginning (again - didn't see
> >>> this with your latest push)
> >>>
> >>>
> http://electronicsam.com/images/KandT/testing/robthreading/latest/current2.png
> >>>
> >>>
> >>> Another thing I'm noticing is that my modified position-error
> calculation
> >>> seems to perform worse with the stock-like velocity estimate (in terms
> of
> >>> steady-state error). I'll play with a few approaches and see if I can
> get
> >>> something better than stock.
> >>>
> >>> Sam, do you do any kind of filtering / averaging in your spindle-speed
> >>> input?  It would be interesting to see the effect if so. I suspect
> that the
> >>> velocity signal could be filtered significantly without impacting the
> >>> position tracking performance.
> >>>
> >>> Best,
> >>> Rob
> >>>
> >>
> --
> >> Developer Access Program for Intel Xeon Phi Processors
> >> Access to Intel Xeon Phi processor-based developer platforms.
> >> With one year of Intel Parallel Studio XE.
> >> Training and support from Colfax.
> >> Order your platform today.http://sdm.link/xeonphi
> >> ___
> >> 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
> >
>
>
>
> --
> 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
>
--
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] Spindle speed signal

[sam sokolik]

oh - what - did you mention you get exact stop when it is trying to 
change the spindle speed?  Is that why it is happening on this system?

sam

On 12/14/2016 05:56 PM, sam sokolik wrote:
> Here is a plot with motion.spindle-speed-in
>
> http://electronicsam.com/images/KandT/testing/robthreading/latest/robnewandspindlein.png
>
> sam
>
>
>
> On 12/11/2016 03:52 PM, Robert Ellenberg wrote:
>> Sam, one last thing, is it possible to put the spindle-speed-in pin on a
>> halscope channel? I'd like to see what the spindle velocity is when it
>> transitions out of accel sync.
>>
>> On Sun, Dec 11, 2016 at 4:44 PM Robert Ellenberg  wrote:
>>
>>> Thanks for giving it a spin!
>>>
>>> I am still getting the error about the spindle going too fast..  You can
>>> see the threading is happening at 19.12 ipm and the axis max vel is
>>> 30ipm.  I tried a similar config and got the same result (could be both
>>> configs have some odd issue we have not figured out.)
>>>
>>> http://electronicsam.com/images/KandT/testing/robthreading/latest/newthreadingfix2Error.png
>>>
>>>
>>> There's definitely an edge case there I didn't account for. I'll keep
>>> working on it and see if I can isolate a test case to reproduce.
>>>
>>> Current 2.7 behavior with the blip at the beginning (again - didn't see
>>> this with your latest push)
>>>
>>> http://electronicsam.com/images/KandT/testing/robthreading/latest/current2.png
>>>
>>>
>>> Another thing I'm noticing is that my modified position-error calculation
>>> seems to perform worse with the stock-like velocity estimate (in terms of
>>> steady-state error). I'll play with a few approaches and see if I can get
>>> something better than stock.
>>>
>>> Sam, do you do any kind of filtering / averaging in your spindle-speed
>>> input?  It would be interesting to see the effect if so. I suspect that the
>>> velocity signal could be filtered significantly without impacting the
>>> position tracking performance.
>>>
>>> Best,
>>> Rob
>>>
>> --
>> Developer Access Program for Intel Xeon Phi Processors
>> Access to Intel Xeon Phi processor-based developer platforms.
>> With one year of Intel Parallel Studio XE.
>> Training and support from Colfax.
>> Order your platform today.http://sdm.link/xeonphi
>> ___
>> 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
>


--
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] Spindle speed signal

[sam sokolik]

also - am I seeing an exact stop at the pull out?

2.7 doesn't seem to do that.  (I am positive we want blending on pull out)

http://electronicsam.com/images/KandT/testing/robthreading/latest/current2.png

sam

On 12/14/2016 05:56 PM, sam sokolik wrote:
> Here is a plot with motion.spindle-speed-in
>
> http://electronicsam.com/images/KandT/testing/robthreading/latest/robnewandspindlein.png
>
> sam
>
>
>
> On 12/11/2016 03:52 PM, Robert Ellenberg wrote:
>> Sam, one last thing, is it possible to put the spindle-speed-in pin on a
>> halscope channel? I'd like to see what the spindle velocity is when it
>> transitions out of accel sync.
>>
>> On Sun, Dec 11, 2016 at 4:44 PM Robert Ellenberg  wrote:
>>
>>> Thanks for giving it a spin!
>>>
>>> I am still getting the error about the spindle going too fast..  You can
>>> see the threading is happening at 19.12 ipm and the axis max vel is
>>> 30ipm.  I tried a similar config and got the same result (could be both
>>> configs have some odd issue we have not figured out.)
>>>
>>> http://electronicsam.com/images/KandT/testing/robthreading/latest/newthreadingfix2Error.png
>>>
>>>
>>> There's definitely an edge case there I didn't account for. I'll keep
>>> working on it and see if I can isolate a test case to reproduce.
>>>
>>> Current 2.7 behavior with the blip at the beginning (again - didn't see
>>> this with your latest push)
>>>
>>> http://electronicsam.com/images/KandT/testing/robthreading/latest/current2.png
>>>
>>>
>>> Another thing I'm noticing is that my modified position-error calculation
>>> seems to perform worse with the stock-like velocity estimate (in terms of
>>> steady-state error). I'll play with a few approaches and see if I can get
>>> something better than stock.
>>>
>>> Sam, do you do any kind of filtering / averaging in your spindle-speed
>>> input?  It would be interesting to see the effect if so. I suspect that the
>>> velocity signal could be filtered significantly without impacting the
>>> position tracking performance.
>>>
>>> Best,
>>> Rob
>>>
>> --
>> Developer Access Program for Intel Xeon Phi Processors
>> Access to Intel Xeon Phi processor-based developer platforms.
>> With one year of Intel Parallel Studio XE.
>> Training and support from Colfax.
>> Order your platform today.http://sdm.link/xeonphi
>> ___
>> 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
>


--
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] Spindle speed signal

[sam sokolik]

Here is a plot with motion.spindle-speed-in

http://electronicsam.com/images/KandT/testing/robthreading/latest/robnewandspindlein.png

sam



On 12/11/2016 03:52 PM, Robert Ellenberg wrote:
> Sam, one last thing, is it possible to put the spindle-speed-in pin on a
> halscope channel? I'd like to see what the spindle velocity is when it
> transitions out of accel sync.
>
> On Sun, Dec 11, 2016 at 4:44 PM Robert Ellenberg  wrote:
>
>> Thanks for giving it a spin!
>>
>> I am still getting the error about the spindle going too fast..  You can
>> see the threading is happening at 19.12 ipm and the axis max vel is
>> 30ipm.  I tried a similar config and got the same result (could be both
>> configs have some odd issue we have not figured out.)
>>
>> http://electronicsam.com/images/KandT/testing/robthreading/latest/newthreadingfix2Error.png
>>
>>
>> There's definitely an edge case there I didn't account for. I'll keep
>> working on it and see if I can isolate a test case to reproduce.
>>
>> Current 2.7 behavior with the blip at the beginning (again - didn't see
>> this with your latest push)
>>
>> http://electronicsam.com/images/KandT/testing/robthreading/latest/current2.png
>>
>>
>> Another thing I'm noticing is that my modified position-error calculation
>> seems to perform worse with the stock-like velocity estimate (in terms of
>> steady-state error). I'll play with a few approaches and see if I can get
>> something better than stock.
>>
>> Sam, do you do any kind of filtering / averaging in your spindle-speed
>> input?  It would be interesting to see the effect if so. I suspect that the
>> velocity signal could be filtered significantly without impacting the
>> position tracking performance.
>>
>> Best,
>> Rob
>>
> --
> Developer Access Program for Intel Xeon Phi Processors
> Access to Intel Xeon Phi processor-based developer platforms.
> With one year of Intel Parallel Studio XE.
> Training and support from Colfax.
> Order your platform today.http://sdm.link/xeonphi
> ___
> 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] Spindle speed signal

[sam sokolik]

There is no filtering.  Here is the complete config

net spindle-vel encoder.0.velocity motion.spindle-speed-in

http://electronicsam.com/images/KandT/testing/robthreading/latest/Emco_HalfFull_Morph.tar.gz

I can scope more pins but it will have to wait a few days.

sam

On 12/11/2016 03:44 PM, Robert Ellenberg wrote:
> Thanks for giving it a spin!
>
> I am still getting the error about the spindle going too fast..  You can
> see the threading is happening at 19.12 ipm and the axis max vel is
> 30ipm.  I tried a similar config and got the same result (could be both
> configs have some odd issue we have not figured out.)
> http://electronicsam.com/images/KandT/testing/robthreading/latest/newthreadingfix2Error.png
>
>
> There's definitely an edge case there I didn't account for. I'll keep
> working on it and see if I can isolate a test case to reproduce.
>
> Current 2.7 behavior with the blip at the beginning (again - didn't see
> this with your latest push)
> http://electronicsam.com/images/KandT/testing/robthreading/latest/current2.png
>
>
> Another thing I'm noticing is that my modified position-error calculation
> seems to perform worse with the stock-like velocity estimate (in terms of
> steady-state error). I'll play with a few approaches and see if I can get
> something better than stock.
>
> Sam, do you do any kind of filtering / averaging in your spindle-speed
> input?  It would be interesting to see the effect if so. I suspect that the
> velocity signal could be filtered significantly without impacting the
> position tracking performance.
>
> Best,
> Rob
> --
> Developer Access Program for Intel Xeon Phi Processors
> Access to Intel Xeon Phi processor-based developer platforms.
> With one year of Intel Parallel Studio XE.
> Training and support from Colfax.
> Order your platform today.http://sdm.link/xeonphi
> ___
> Emc-developers mailing list
> Emc-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-developers
>


--
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today.http://sdm.link/xeonphi
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] Spindle speed signal

[Robert Ellenberg]

Sam, one last thing, is it possible to put the spindle-speed-in pin on a
halscope channel? I'd like to see what the spindle velocity is when it
transitions out of accel sync.

On Sun, Dec 11, 2016 at 4:44 PM Robert Ellenberg  wrote:

> Thanks for giving it a spin!
>
> I am still getting the error about the spindle going too fast..  You can
> see the threading is happening at 19.12 ipm and the axis max vel is
> 30ipm.  I tried a similar config and got the same result (could be both
> configs have some odd issue we have not figured out.)
>
> http://electronicsam.com/images/KandT/testing/robthreading/latest/newthreadingfix2Error.png
>
>
> There's definitely an edge case there I didn't account for. I'll keep
> working on it and see if I can isolate a test case to reproduce.
>
> Current 2.7 behavior with the blip at the beginning (again - didn't see
> this with your latest push)
>
> http://electronicsam.com/images/KandT/testing/robthreading/latest/current2.png
>
>
> Another thing I'm noticing is that my modified position-error calculation
> seems to perform worse with the stock-like velocity estimate (in terms of
> steady-state error). I'll play with a few approaches and see if I can get
> something better than stock.
>
> Sam, do you do any kind of filtering / averaging in your spindle-speed
> input?  It would be interesting to see the effect if so. I suspect that the
> velocity signal could be filtered significantly without impacting the
> position tracking performance.
>
> Best,
> Rob
>
--
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today.http://sdm.link/xeonphi
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] Spindle speed signal

[Robert Ellenberg]

Hi Gene,

I don't fully understand your question, but I have reason to think that my
fixes will improve position tracking accuracy and consistency, and may help
in the scenario you describe.

In case you're not familiar with motion's internals, here's what happens at
the start of a position sync move (rigid tap, G33 threading)

   1. Wait at the start of the thread for an index pulse (i.e. motion
   progress is 0).
   2. At index, spindle position (in revs) is now 0
   3. Start "sync accel", i.e. accelerate at maximum rate to match speed
   with spindle
   4. Once the axis feed and spindle speeds match, we declare that point to
   be "synced". Save the current spindle position and motion progress
   internally.
   5. Now, we track / correct position error relative to this sync point.

Without the "sync accel" phase, the initial position error would be very
large, which could lead to overshoots and a long settling time.

There were a few subtle issues with the implementation that may reduce
threading accuracy:

The biggest issue I see is estimation of velocity for low PPR encoders.
Currently, motion estimates velocity with a simple backward difference.
This leads to a very jittery velocity estimate. For example, at 120RPM with
a 100PPR encoder, we'll see once pulse every 5 servo interrupts (@ 1kHz).
Our naive velocity will swing between 0 and 600 RPM. This is a problem for
a few reasons:

   - sync accel is over when axis velocity >= spindle speed * uu/rev. In
   the above example, sync accel will never last more than 2 timesteps,
   leaving a large initial position error.
   - Spindle speed jitter appears in axis motions as acceleration spikes
   (see issue 164 )
   - There will be a steady-state error, because the velocity "peaks" are
   rarer than the troughs, and the correction is rate-limited by the maximum
   axis acceleration.

The simple fix here is just to provide a better spindle speed measurement.
Most encoder counters can do this already, so we get the benefit for free.

On Sun, Dec 11, 2016 at 12:18 PM Gene Heskett  wrote:

On Sunday 11 December 2016 09:17:32 Robert Ellenberg wrote:

> Ahh, that would have been smart to include before:
>
>- sim_spindle_encoder's position signal is now quantized based on
>encoder resolution.
>- Use motion.spindle-speed-in as the velocity reference for spindle
>position tracking (falls back to old velocity calculation if this
> pin is unconnected)
>- Tweak position error correction math to reduce acceleration
> jitter - Add a HAL pin, motion.spindle-tracking-gain (range 0.0 to
> 1.0) to control how aggressive position tracking is. 1.0 is stock
> behavior, 0.0 is no position tracking.
>- Fix "sync_accel" phase of position tracking for low-count
> encoders. - Experimental fix for issue 167

Was this caused by an attempt to get z in position closer or effectively
on the index by the time it has arrived at the workpiece, thereby
reducing that thread wrecking spindle speed vs phase of the thread
change that occurs when the operator sees that everything clears and
cranks up the rpms to cut a cleaner thread?

I had noted a rather large, wrecked the thread, change in the cutting tip
position vs thread clear back in 2.5 IIRC while using g76.  The cause
was explained as being the time to accell to a locked phase, which
caused the thread to move to the right. By over accelerating Z, if it
had the headroom to do so, such that the actual spindle to Z stayed
effectively at the index pulse seemed like a good idea. If it doesn't
have the headroom to catch up by the time it arrives at the work, there
will be bad threads cut at the entry. That of course can only be derived
if the g33 knows how much room it has to get that done.

I wrote some .hal code that if I put a halmeter on its output, that tells
me the number of encoder edges between motions reversal to effect the
backout move for telling me how long in encoder counts between motions
issuance of the spindle reverse, and the first encoder pulse received in
reverse direction. That was to aid me in preventing broken taps because
it had hit the bottom on the drilled hole. A calculator can quickly
convert that into distance traveled, overshoot if you will. With the
needed accell limits to keep from breaking flimsy drive parts on TLM, it
quickly became obvious that the practical limits for threading rpms was
well below 300 rpm, and more practically around 200.  At 600, cutting
air, the overshoot was around 9 turns of the chuck, at 300, around 2.5,
and at 200, about 1 full turn. Somewhat interesting was that it did the
reverse in high gear faster, in low gear the higher MV2 energy in the
massive flywheel/pulley/cooling fan of the motor actually slowed the
decel to stop rate.


> by popping an
> error message to the user and reducing spindle speed (if possible) -
> Fix for issue 68 

Re: [Emc-developers] Spindle speed signal

[Robert Ellenberg]

Thanks for giving it a spin!

I am still getting the error about the spindle going too fast..  You can
see the threading is happening at 19.12 ipm and the axis max vel is
30ipm.  I tried a similar config and got the same result (could be both
configs have some odd issue we have not figured out.)
http://electronicsam.com/images/KandT/testing/robthreading/latest/newthreadingfix2Error.png


There's definitely an edge case there I didn't account for. I'll keep
working on it and see if I can isolate a test case to reproduce.

Current 2.7 behavior with the blip at the beginning (again - didn't see
this with your latest push)
http://electronicsam.com/images/KandT/testing/robthreading/latest/current2.png


Another thing I'm noticing is that my modified position-error calculation
seems to perform worse with the stock-like velocity estimate (in terms of
steady-state error). I'll play with a few approaches and see if I can get
something better than stock.

Sam, do you do any kind of filtering / averaging in your spindle-speed
input?  It would be interesting to see the effect if so. I suspect that the
velocity signal could be filtered significantly without impacting the
position tracking performance.

Best,
Rob
--
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today.http://sdm.link/xeonphi
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] Spindle speed signal

[sam sokolik]

Threading air..

The motion seems a lot more consistent - no funny blip the original did. 
run after run looked pretty much identical in halscope.

http://electronicsam.com/images/KandT/testing/robthreading/latest/newthreadingfix.png
motion.spindle-tracking-gain set to .5
http://electronicsam.com/images/KandT/testing/robthreading/latest/newthreadingfixmotion.spindle-tracking-gain.5.png

I am still getting the error about the spindle going too fast..  You can 
see the threading is happening at 19.12 ipm and the axis max vel is 
30ipm.  I tried a similar config and got the same result (could be both 
configs have some odd issue we have not figured out.)
http://electronicsam.com/images/KandT/testing/robthreading/latest/newthreadingfix2Error.png

Current 2.7 behavior with the blip at the beginning (again - didn't see 
this with your latest push)
http://electronicsam.com/images/KandT/testing/robthreading/latest/current2.png

Again - great work!
sam

On 12/11/2016 08:17 AM, Robert Ellenberg wrote:
> Ahh, that would have been smart to include before:
>
> - sim_spindle_encoder's position signal is now quantized based on
> encoder resolution.
> - Use motion.spindle-speed-in as the velocity reference for spindle
> position tracking (falls back to old velocity calculation if this pin is
> unconnected)
> - Tweak position error correction math to reduce acceleration jitter
> - Add a HAL pin, motion.spindle-tracking-gain (range 0.0 to 1.0) to
> control how aggressive position tracking is. 1.0 is stock behavior, 0.0 is
> no position tracking.
> - Fix "sync_accel" phase of position tracking for low-count encoders.
> - Experimental fix for issue 167
>  by popping an error
> message to the user and reducing spindle speed (if possible)
> - Fix for issue 68  by
> disabling blending at start of G33 (to be consistent w/ 2.6.x)
>
> Backend changes:
>
> - Group some spindle status variables into struct:
>- Motion spindle command outputs are in a struct called "spindle_cmd"
>in emcStatus
>- motion spindle inputs are now in a struct called "spindle_fb"
> - Math tweaks to rigid tapping / position tracking to prevent
> discontinuities due to sign changes.
>
> -Rob
>
> On Sun, Dec 11, 2016 at 8:20 AM andy pugh  wrote:
>
> On 11 December 2016 at 06:30, Robert Ellenberg  wrote:
>> For anyone interested in testing, my latest branch based on Peter's
>> suggestion, and a bunch of other spindle tracking fixes is here:
> Can you explain what is changed and improved?
>
> --
> 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
>
> --
> Developer Access Program for Intel Xeon Phi Processors
> Access to Intel Xeon Phi processor-based developer platforms.
> With one year of Intel Parallel Studio XE.
> Training and support from Colfax.
> Order your platform today.http://sdm.link/xeonphi
> ___
> Emc-developers mailing list
> Emc-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-developers
> --
> Developer Access Program for Intel Xeon Phi Processors
> Access to Intel Xeon Phi processor-based developer platforms.
> With one year of Intel Parallel Studio XE.
> Training and support from Colfax.
> Order your platform today.http://sdm.link/xeonphi
> ___
> Emc-developers mailing list
> Emc-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-developers


--
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today.http://sdm.link/xeonphi
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] Spindle speed signal

[Gene Heskett]

On Sunday 11 December 2016 09:17:32 Robert Ellenberg wrote:

> Ahh, that would have been smart to include before:
>
>- sim_spindle_encoder's position signal is now quantized based on
>encoder resolution.
>- Use motion.spindle-speed-in as the velocity reference for spindle
>position tracking (falls back to old velocity calculation if this
> pin is unconnected)
>- Tweak position error correction math to reduce acceleration
> jitter - Add a HAL pin, motion.spindle-tracking-gain (range 0.0 to
> 1.0) to control how aggressive position tracking is. 1.0 is stock
> behavior, 0.0 is no position tracking.
>- Fix "sync_accel" phase of position tracking for low-count
> encoders. - Experimental fix for issue 167

Was this caused by an attempt to get z in position closer or effectively 
on the index by the time it has arrived at the workpiece, thereby 
reducing that thread wrecking spindle speed vs phase of the thread 
change that occurs when the operator sees that everything clears and 
cranks up the rpms to cut a cleaner thread?

I had noted a rather large, wrecked the thread, change in the cutting tip 
position vs thread clear back in 2.5 IIRC while using g76.  The cause 
was explained as being the time to accell to a locked phase, which 
caused the thread to move to the right. By over accelerating Z, if it 
had the headroom to do so, such that the actual spindle to Z stayed 
effectively at the index pulse seemed like a good idea. If it doesn't 
have the headroom to catch up by the time it arrives at the work, there 
will be bad threads cut at the entry. That of course can only be derived 
if the g33 knows how much room it has to get that done.

I wrote some .hal code that if I put a halmeter on its output, that tells 
me the number of encoder edges between motions reversal to effect the 
backout move for telling me how long in encoder counts between motions 
issuance of the spindle reverse, and the first encoder pulse received in 
reverse direction. That was to aid me in preventing broken taps because 
it had hit the bottom on the drilled hole. A calculator can quickly 
convert that into distance traveled, overshoot if you will. With the 
needed accell limits to keep from breaking flimsy drive parts on TLM, it 
quickly became obvious that the practical limits for threading rpms was 
well below 300 rpm, and more practically around 200.  At 600, cutting 
air, the overshoot was around 9 turns of the chuck, at 300, around 2.5, 
and at 200, about 1 full turn. Somewhat interesting was that it did the 
reverse in high gear faster, in low gear the higher MV2 energy in the 
massive flywheel/pulley/cooling fan of the motor actually slowed the 
decel to stop rate.


> by popping an
> error message to the user and reducing spindle speed (if possible) -
> Fix for issue 68  by
> disabling blending at start of G33 (to be consistent w/ 2.6.x)
>
> Backend changes:
>
>- Group some spindle status variables into struct:
>   - Motion spindle command outputs are in a struct called
> "spindle_cmd" in emcStatus
>   - motion spindle inputs are now in a struct called "spindle_fb"
>- Math tweaks to rigid tapping / position tracking to prevent
>discontinuities due to sign changes.
>
> -Rob
>
> On Sun, Dec 11, 2016 at 8:20 AM andy pugh  wrote:
>
> On 11 December 2016 at 06:30, Robert Ellenberg  
wrote:
> > For anyone interested in testing, my latest branch based on Peter's
> > suggestion, and a bunch of other spindle tracking fixes is here:
>
> Can you explain what is changed and improved?

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 

--
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today.http://sdm.link/xeonphi
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] Spindle speed signal

[Robert Ellenberg]

Ahh, that would have been smart to include before:

   - sim_spindle_encoder's position signal is now quantized based on
   encoder resolution.
   - Use motion.spindle-speed-in as the velocity reference for spindle
   position tracking (falls back to old velocity calculation if this pin is
   unconnected)
   - Tweak position error correction math to reduce acceleration jitter
   - Add a HAL pin, motion.spindle-tracking-gain (range 0.0 to 1.0) to
   control how aggressive position tracking is. 1.0 is stock behavior, 0.0 is
   no position tracking.
   - Fix "sync_accel" phase of position tracking for low-count encoders.
   - Experimental fix for issue 167
    by popping an error
   message to the user and reducing spindle speed (if possible)
   - Fix for issue 68  by
   disabling blending at start of G33 (to be consistent w/ 2.6.x)

Backend changes:

   - Group some spindle status variables into struct:
  - Motion spindle command outputs are in a struct called "spindle_cmd"
  in emcStatus
  - motion spindle inputs are now in a struct called "spindle_fb"
   - Math tweaks to rigid tapping / position tracking to prevent
   discontinuities due to sign changes.

-Rob

On Sun, Dec 11, 2016 at 8:20 AM andy pugh  wrote:

On 11 December 2016 at 06:30, Robert Ellenberg  wrote:
> For anyone interested in testing, my latest branch based on Peter's
> suggestion, and a bunch of other spindle tracking fixes is here:

Can you explain what is changed and improved?

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

--
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today.http://sdm.link/xeonphi
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers
--
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today.http://sdm.link/xeonphi
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] Spindle speed signal

[andy pugh]

On 11 December 2016 at 06:30, Robert Ellenberg  wrote:
> For anyone interested in testing, my latest branch based on Peter's
> suggestion, and a bunch of other spindle tracking fixes is here:

Can you explain what is changed and improved?

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

--
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today.http://sdm.link/xeonphi
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] Spindle speed signal

[Gene Heskett]

On Sunday 11 December 2016 01:30:42 Robert Ellenberg wrote:

> For anyone interested in testing, my latest branch based on Peter's
> suggestion, and a bunch of other spindle tracking fixes is here:
>
> https://github.com/robEllenberg/linuxcnc-mirror/tree/feature/spindle-s
>ync-overhaul-2.7
>
> I've tweaked a lot of spindle tracking code, so I'd be careful when
> running it on hardware (cut air or wax first!).
>
> Best,
> Rob
>
Thank you Robert, I look fwd to giving it a workout if it applies to the 
vfd controlled spindle in my now underway Sheldon conversion.  The vfd 
is a stiff enough control, so unlike 2 of my other machines treating the 
dc spindle motors as velocity servo's, I won't need the PID with the vfd 
doing the work.  At least thats what it says here according to my 
testing it on the worktable.

Running the 2.8-pre tree on a raspberry pi feeding a 7i90HD, I would hope 
that it gets migrated to the pi's (running a rt kernel on a basically 
armbian jessie build) 2.8-pre fairly quickly.  I fact, none of my 3.5 
machines is running a 2.7 and hasn't been in close to a year.

Stay warm everybody, the weather folks are making threatening noises 
about the next week or so in my neck of the woods.

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 

--
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today.http://sdm.link/xeonphi
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] Spindle speed signal

[Robert Ellenberg]

For anyone interested in testing, my latest branch based on Peter's
suggestion, and a bunch of other spindle tracking fixes is here:

https://github.com/robEllenberg/linuxcnc-mirror/tree/feature/spindle-sync-overhaul-2.7

I've tweaked a lot of spindle tracking code, so I'd be careful when running
it on hardware (cut air or wax first!).

Best,
Rob

On Fri, Dec 9, 2016 at 12:17 PM Robert Ellenberg  wrote:

> Peter, I like your idea of calculating a velocity if none is provided.
> I'll take a look at the PID component.
>
> Andy / Chris, from your feedback, it sounds like cases like Jon's are
> rare, but we shouldn't break them. Peter's approach gives a safe if
> suboptimal fallback. If the future manual explains the benefits of
> connecting both pins, then a user that cares will know why it's important
> to have both.
>
--
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today.http://sdm.link/xeonphi
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] Spindle speed signal

[Robert Ellenberg]

Peter, I like your idea of calculating a velocity if none is provided. I'll
take a look at the PID component.

Andy / Chris, from your feedback, it sounds like cases like Jon's are rare,
but we shouldn't break them. Peter's approach gives a safe if suboptimal
fallback. If the future manual explains the benefits of connecting both
pins, then a user that cares will know why it's important to have both.
--
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today.http://sdm.link/xeonphi
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] Spindle speed signal

[Jon Elson]

On 12/08/2016 12:19 PM, andy pugh wrote:
> On 8 December 2016 at 18:10, Robert Ellenberg  wrote:
>> Does anyone use a spindle encoder with only position output? In other
>> words, encoder position linked to  motion.spindle-revs, but no input to
>> motion.spindle-speed-in?
> I would imagine that it might be uncommon, but not unknown. For
> example a serial encoder might not have velocity data.
>
First, I have to say I'm using some old LinuxCNC versions, 2.5.x and 
2.6.x, but I have no connection to

motion.spindle-speed-in

motion.spindle-revs is hooked up for threading.

Jon


--
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today.http://sdm.link/xeonphi
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] Spindle speed signal

[Chris Radek]

On Thu, Dec 08, 2016 at 06:10:09PM +, Robert Ellenberg wrote:
> Hi All,
> 
> Does anyone use a spindle encoder with only position output? In other
> words, encoder position linked to  motion.spindle-revs, but no input to
> motion.spindle-speed-in?

motion.spindle-speed-in IN FLOAT

Actual spindle speed feedback in revolutions per second;
used for G96 (constant surface speed) and G95 (feed per
revolution) modes.

Because important things don't work without it, I think all lathes
will have a signal here, whether it comes from an encoder (directly
or through a ddt) or it's just a loopback from the commanded spindle
speed (in the no spindle encoder case).

I'd go ahead and depend on it being there, if it solves a problem.
Maybe also add another note to the documentation here?


--
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today.http://sdm.link/xeonphi
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] Spindle speed signal

[andy pugh]

On 8 December 2016 at 18:10, Robert Ellenberg  wrote:
> Does anyone use a spindle encoder with only position output? In other
> words, encoder position linked to  motion.spindle-revs, but no input to
> motion.spindle-speed-in?

I would imagine that it might be uncommon, but not unknown. For
example a serial encoder might not have velocity data.

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

--
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today.http://sdm.link/xeonphi
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers