Re: [Emc-developers] jerk limited trajectory

2015-12-24 Thread TJoseph Powderly 
Gerald Farin? CAGD Nurbs guy?
tomp

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

Re: [Emc-developers] jerk limited trajectory

2015-12-24 Thread EBo 
yep...

On Dec 24 2015 7:48 AM, TJoseph Powderly wrote:
> Gerald Farin? CAGD Nurbs guy?
> tomp
>
> 
> --
> ___
> 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] jerk limited trajectory

2015-12-23 Thread Pete_Gruendeman 
Hi:
> I like to think of what happens when I apply the breaks on a car.  It
slows down, and if I do not let up a little near the end it grabs...  I
think that is technically jerk.<
 Good example!  Absolutely that is jerk as the curve for acceleration has a 
step function in it.  The higher derivative curves would have a step in them 
also.  They are frequently named Snap, Crackle & Pop.  While I don't know the 
exact significance of them in regards to machine tools, when it comes to 
rotating cams, if all the derivatives through Pop are smooth or at least have 
no step in them, you can pretty much turn as fast as you want without 
developing unintended motions and deflections.  Sine waves and their 
derivatives pass this test very well but there are other motions that can as 
well.  
 Just easing off the brakes as the car comes to a stop would be a big 
improvement for fast moving machinery.  That potentially solves the overshoot 
problem.

Pete Gruendeman

On Tue, 12/22/15, EBo <e...@sandien.com> wrote:

 Subject: Re: [Emc-developers] jerk limited trajectory
 To: emc-developers@lists.sourceforge.net
 Date: Tuesday, December 22, 2015, 10:44 PM
 
 On Dec 22 2015 8:33 PM,
 andy pugh wrote:
 > On 23 December 2015 at
 02:02, Jon Elson <el...@pico-systems.com>
 
 > wrote:
 >> So,
 the spindle's
 >> rotational
 inertia makes jerk MECHANICALLY impossible.
 >
 > I don't think
 that there is a mechanical limit on jerk.
 >
 > This is why you
 stumble when a tube train stops hard.
 
 I like to think of what happens when I apply
 the breaks on a car.  It 
 slows down, and
 if I do not let up a little near the end it grabs...  I 
 think that is technically jerk.  As for
 applying gas, if you pop the 
 clutch...
 
 Seriously though.  The VLA
 example, they installed two motors (each 
 feeding the opposite way, and would feed them
 propositionally to control 
 jerk, and
 possibly higher order derivatives).  They told me that when
 
 they originally had one motor on the
 system, the initial impulse would 
 send a
 shock through the entire antenna.  I could have the story
 wrong, 
 but that is what I remember.
 
 Back to LCNC land...  I can
 see this being useful for most cases, but 
 not critically necessary unless I was spinning
 something less than a 24" 
 chuck.  I
 only had a chance to run a machine that large once, and that
 
 was decades ago.
 
    EBo --
 
 
 --
 ___
 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] jerk limited trajectory

2015-12-23 Thread EBo 
In one of his classes, Farin told us that when they were developing the 
early electronic controls for elevators that if they did not limit jerk 
(or maybe it was snap) that people riding the elector would loose their 
breakfasts.  Apparently the fluid in the inner ear is quite sensitive to 
subtle changes in motion, and motion derivatives.

Now if you have ever ridden a moderns elevator (one made and installed 
in the last 20 years) in really tall buildings, they have very smooth 
motion profiles.  It would be interesting to see just how fine they tune 
them.

   EBo --

On Dec 23 2015 7:50 AM, Pete_Gruendeman wrote:
> Hi:
>> I like to think of what happens when I apply the breaks on a car.  
>> It
>> slows down, and if I do not let up a little near the end it grabs... 
>> I
>> think that is technically jerk.<
>  Good example!  Absolutely that is jerk as the curve for
> acceleration has a step function in it.  The higher derivative curves
> would have a step in them also.  They are frequently named Snap,
> Crackle & Pop.  While I don't know the exact significance of them in
> regards to machine tools, when it comes to rotating cams, if all the
> derivatives through Pop are smooth or at least have no step in them,
> you can pretty much turn as fast as you want without developing
> unintended motions and deflections.  Sine waves and their derivatives
> pass this test very well but there are other motions that can as 
> well.
>
>  Just easing off the brakes as the car comes to a stop would be a
> big improvement for fast moving machinery.  That potentially solves
> the overshoot problem.
>
> Pete Gruendeman
> ------------
> On Tue, 12/22/15, EBo <e...@sandien.com> wrote:
>
>  Subject: Re: [Emc-developers] jerk limited trajectory
>  To: emc-developers@lists.sourceforge.net
>  Date: Tuesday, December 22, 2015, 10:44 PM
>
>  On Dec 22 2015 8:33 PM,
>  andy pugh wrote:
>  > On 23 December 2015 at
>  02:02, Jon Elson <el...@pico-systems.com>
>
>  > wrote:
>  >> So,
>  the spindle's
>  >> rotational
>  inertia makes jerk MECHANICALLY impossible.
>  >
>  > I don't think
>  that there is a mechanical limit on jerk.
>  >
>  > This is why you
>  stumble when a tube train stops hard.
>
>  I like to think of what happens when I apply
>  the breaks on a car.  It
>  slows down, and
>  if I do not let up a little near the end it grabs...  I
>  think that is technically jerk.  As for
>  applying gas, if you pop the
>  clutch...
>
>  Seriously though.  The VLA
>  example, they installed two motors (each
>  feeding the opposite way, and would feed them
>  propositionally to control
>  jerk, and
>  possibly higher order derivatives).  They told me that when
>
>  they originally had one motor on the
>  system, the initial impulse would
>  send a
>  shock through the entire antenna.  I could have the story
>  wrong,
>  but that is what I remember.
>
>  Back to LCNC land...  I can
>  see this being useful for most cases, but
>  not critically necessary unless I was spinning
>  something less than a 24"
>  chuck.  I
>  only had a chance to run a machine that large once, and that
>
>  was decades ago.
>
>     EBo --
>
>
>  
> --
>  ___
>  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] jerk limited trajectory

2015-12-22 Thread Chris Morley 


> Date: Tue, 22 Dec 2015 11:18:20 -0600
> From: el...@pico-systems.com
> To: emc-developers@lists.sourceforge.net
> Subject: Re: [Emc-developers] jerk limited trajectory
> 
> On 12/21/2015 11:59 PM, Chris Morley wrote:
> >
> > That version of jerk-limited just didn't quite work right 
> > with spindle-synch. IIRC the person doing it didn't need 
> > spindle-synch and got little help - lost interest. Not 
> > that i blame him - it looks very difficult!
> Yes, I think combining jerk limiting with spindle synch 
> REQUIRES a compromise.  There are probably a couple ways to 
> do it.  One is to just turn off jerk limiting when in 
> spindle synch.  The other is to warn users that there is 
> some initial part of the motion which will not be fully 
> synched to the spindle, until the jerk limit has been 
> integrated out.  This latter scheme will break taps on 
> spindle reversal, so doesn't seem like the right approach.  
> Maybe somebody else knows a better way?
> 
> Jon
> 

I've heard this argument before and it just doesn't make sense to me.
I can't figure out why one would not want to have jerk limiting.
jerk limiting allows one to define a machine command that the machine
 can actually physically perform. In fact it can allow you to raise acceleration
setting giving you more performance.
If ignoring jerk allowed better performance then ignoring acceleration should be
 even better? I don't think that would be very successful.
I mean obviously if your jerk setting is out to lunch that could be just as bad.
but I bet jerk is such a small part of machine movement that it wouldn't break 
the tap.
I say this because all linuxcnc machines out there ignore jerk and they don't 
break taps
 all the time. Though i guess one could argue that the axis has jerk anyways so 
it matches
the spindle close enough.

I am not an expert or have done the math on this - it just doesn't make sense 
to me.
I'd love to know the answer definitively!
It would be interesting to see the actual motion profile of a spindle tapping 
vrs
the actual motion profile of an axis following it vrs the commanded motion 
profile.

Interesting !

Chris M 

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

Re: [Emc-developers] jerk limited trajectory

2015-12-22 Thread Peter C. Wallace 
On Tue, 22 Dec 2015, Chris Morley wrote:

> Date: Tue, 22 Dec 2015 18:25:10 +
> From: Chris Morley <chrisinnana...@hotmail.com>
> Reply-To: EMC developers <emc-developers@lists.sourceforge.net>
> To: EMC DEV <emc-developers@lists.sourceforge.net>
> Subject: Re: [Emc-developers] jerk limited trajectory
> 
>
>
>> Date: Tue, 22 Dec 2015 11:18:20 -0600
>> From: el...@pico-systems.com
>> To: emc-developers@lists.sourceforge.net
>> Subject: Re: [Emc-developers] jerk limited trajectory
>>
>> On 12/21/2015 11:59 PM, Chris Morley wrote:
>>>
>>> That version of jerk-limited just didn't quite work right
>>> with spindle-synch. IIRC the person doing it didn't need
>>> spindle-synch and got little help - lost interest. Not
>>> that i blame him - it looks very difficult!
>> Yes, I think combining jerk limiting with spindle synch
>> REQUIRES a compromise.  There are probably a couple ways to
>> do it.  One is to just turn off jerk limiting when in
>> spindle synch.  The other is to warn users that there is
>> some initial part of the motion which will not be fully
>> synched to the spindle, until the jerk limit has been
>> integrated out.  This latter scheme will break taps on
>> spindle reversal, so doesn't seem like the right approach.
>> Maybe somebody else knows a better way?
>>
>> Jon
>>
>
> I've heard this argument before and it just doesn't make sense to me.
> I can't figure out why one would not want to have jerk limiting.
> jerk limiting allows one to define a machine command that the machine
> can actually physically perform. In fact it can allow you to raise 
> acceleration
> setting giving you more performance.
> If ignoring jerk allowed better performance then ignoring acceleration should 
> be
> even better? I don't think that would be very successful.
> I mean obviously if your jerk setting is out to lunch that could be just as 
> bad.
> but I bet jerk is such a small part of machine movement that it wouldn't 
> break the tap.
> I say this because all linuxcnc machines out there ignore jerk and they don't 
> break taps
> all the time. Though i guess one could argue that the axis has jerk anyways 
> so it matches
> the spindle close enough.
>
> I am not an expert or have done the math on this - it just doesn't make sense 
> to me.
> I'd love to know the answer definitively!
> It would be interesting to see the actual motion profile of a spindle tapping 
> vrs
> the actual motion profile of an axis following it vrs the commanded motion 
> profile.
>
> Interesting !
>
> Chris M

I suspect (but do not know for sure) that VFDs are slow enough at developing 
reverse torque (so are inherently low jerk) that this is not really an issue
as long as the synchronized axis jerk value is high enough to follow without 
bounding acceleration.

Of course, with a fancy spindle control (say closed loop), the spindle jerk 
could be limited.

Peter Wallace
Mesa Electronics


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

Re: [Emc-developers] jerk limited trajectory

2015-12-22 Thread Yishin Li 
On Tue, Dec 22, 2015 at 9:54 PM, TJoseph Powderly  wrote:

> Yishin hello
> Am I right to think you want to be able to turn spindle to any degree?
> like G01 C35.678   ?
>
> Yes, we use G33.2 to position spindle in any degree within 360. Because,
after M3S200 for a while, it's not easy to use G1 to position spindle at
any degree without modifying tpAddLine().

= G33.2, Absolute Spindle Positioning within 360 degree
* spindle positioning where spindle may be mapped as A/B/C axis
* Spindle must be on; and its speed must be 0 (M3S0)
* usage: G33.2 A[ABSOLUTE_ANGLE] K[RPM]
 move spindle to ABSOLUTE_ANGLE with RPM speed

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

Re: [Emc-developers] jerk limited trajectory

2015-12-22 Thread EBo 
On Dec 22 2015 10:18 AM, Jon Elson wrote:
> On 12/21/2015 11:59 PM, Chris Morley wrote:
>>
>> That version of jerk-limited just didn't quite work right
>> with spindle-synch. IIRC the person doing it didn't need
>> spindle-synch and got little help - lost interest. Not
>> that i blame him - it looks very difficult!
> Yes, I think combining jerk limiting with spindle synch
> REQUIRES a compromise.  There are probably a couple ways to
> do it.  One is to just turn off jerk limiting when in
> spindle synch.  The other is to warn users that there is
> some initial part of the motion which will not be fully
> synched to the spindle, until the jerk limit has been
> integrated out.  This latter scheme will break taps on
> spindle reversal, so doesn't seem like the right approach.
> Maybe somebody else knows a better way?

I think there are at least two issues here:

*) thread turning -- where the spindle is already in motion and you 
want to sync up to chase a thread.  Here you do not care about 
acceleration profiles of the tool (as long as you have enough room to 
sync them).

*) coordinating the spindle with full start/stop motion control.

In either case, once you get everything moving you can keep them 
synchronized to a stop and reverse.  One the other hand, if you are 
chasing threads, then you might want to back the threading tool out and 
leave the spindle running a full speed.

As a note, this discussion totally ignores large machines which can be 
broken or worn when moving without jerk limits.  I have never worked on 
a machine that big, but when a friend was working on one of the NRAO's 
VLA radio antennas .  Those thigns are three 
stories TALL!

   EBo --


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

Re: [Emc-developers] jerk limited trajectory

2015-12-22 Thread andy pugh 
On 23 December 2015 at 02:02, Jon Elson  wrote:
> So, the spindle's
> rotational inertia makes jerk MECHANICALLY impossible.

I don't think that there is a mechanical limit on jerk.

This is why you stumble when a tube train stops hard.

-- 
atp
If you can't fix it, you don't own it.
http://www.ifixit.com/Manifesto

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

Re: [Emc-developers] jerk limited trajectory

2015-12-22 Thread Jon Elson 
On 12/22/2015 09:33 PM, andy pugh wrote:
> On 23 December 2015 at 02:02, Jon Elson  wrote:
>> So, the spindle's
>> rotational inertia makes jerk MECHANICALLY impossible.
> I don't think that there is a mechanical limit on jerk.
>
> This is why you stumble when a tube train stops hard.
>
Ahh, well, that's why I am NOT a math major!

Jon

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

Re: [Emc-developers] jerk limited trajectory

2015-12-22 Thread EBo 
On Dec 22 2015 8:33 PM, andy pugh wrote:
> On 23 December 2015 at 02:02, Jon Elson  
> wrote:
>> So, the spindle's
>> rotational inertia makes jerk MECHANICALLY impossible.
>
> I don't think that there is a mechanical limit on jerk.
>
> This is why you stumble when a tube train stops hard.

I like to think of what happens when I apply the breaks on a car.  It 
slows down, and if I do not let up a little near the end it grabs...  I 
think that is technically jerk.  As for applying gas, if you pop the 
clutch...

Seriously though.  The VLA example, they installed two motors (each 
feeding the opposite way, and would feed them propositionally to control 
jerk, and possibly higher order derivatives).  They told me that when 
they originally had one motor on the system, the initial impulse would 
send a shock through the entire antenna.  I could have the story wrong, 
but that is what I remember.

Back to LCNC land...  I can see this being useful for most cases, but 
not critically necessary unless I was spinning something less than a 24" 
chuck.  I only had a chance to run a machine that large once, and that 
was decades ago.

   EBo --


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

Re: [Emc-developers] jerk limited trajectory

2015-12-22 Thread Yishin Li 
On Tue, Dec 22, 2015 at 1:59 PM, Chris Morley <chrisinnana...@hotmail.com>
wrote:

>
>
> > To: emc-developers@lists.sourceforge.net
> > From: marius.alks...@gmail.com
> > Date: Tue, 22 Dec 2015 06:11:23 +0200
> > Subject: Re: [Emc-developers] jerk limited trajectory
> >
> > 12/17/2015 05:40 PM, Viesturs Lācis rašė:
> > ...
> > > IIRC it has not been implemented in LinuxCNC, because it would not
> > > work for spindle-synchronised moves, but I might be totally wrong on
> > > that :))
> > >
> > >
> > > Viesturs
> >
> > I see jerk limitation as very nice and important feature to have.
> > And I would go with a workaround like disabling jerk limitation only
> > when doing spindle-synchronised move (or whatever else rarely used type
> > of move) to let it work for the mainstream.
> >
> > BTW, limit4 would be great too :)
> >
>
> That version of jerk-limited just didn't quite work right with
> spindle-synch.
> IIRC the person doing it didn't need spindle-synch and got little help -
> lost interest.
> Not that i blame him - it looks very difficult!
>
> Our Jerk limitation implementation is on-going at:
https://github.com/araisrobo/machinekit/tree/rpi2-spi

It is with spindle synchronizing for a wood lathe machine:
https://youtu.be/_3v9xDF-2nY

We are trying a new approach to apply trajectory planning for spindle, i.e.
treat spindle like an axis. Still lots of work to be done.

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

Re: [Emc-developers] jerk limited trajectory

2015-12-22 Thread TJoseph Powderly 
Yishin hello
Am I right to think you want to be able to turn spindle to any degree?
like G01 C35.678   ?

In sink Edm we do not spin the tool but use
C axis on end of Z to orient tool ( electrode) to workpiece (mold cavity).

Sometimes...
we do use as spindle, but for sink edm it is slow compared to
milling machine. IIRC the highest speeds are near 100rpm,
even with tiny diameter tools ( <.01 mm dia ), At higher rpm's
the spark does not form correctly.

Your work is always interesting, thank you.

TomP

On 12/22/2015 06:26 AM, Yishin Li wrote:
> On Tue, Dec 22, 2015 at 1:59 PM, Chris Morley <chrisinnana...@hotmail.com>
> wrote:
>
>>
>>> To: emc-developers@lists.sourceforge.net
>>> From: marius.alks...@gmail.com
>>> Date: Tue, 22 Dec 2015 06:11:23 +0200
>>> Subject: Re: [Emc-developers] jerk limited trajectory
>>>
>>> 12/17/2015 05:40 PM, Viesturs Lācis rašė:
>>> ...
>>>> IIRC it has not been implemented in LinuxCNC, because it would not
>>>> work for spindle-synchronised moves, but I might be totally wrong on
>>>> that :))
>>>>
>>>>
>>>> Viesturs
>>> I see jerk limitation as very nice and important feature to have.
>>> And I would go with a workaround like disabling jerk limitation only
>>> when doing spindle-synchronised move (or whatever else rarely used type
>>> of move) to let it work for the mainstream.
>>>
>>> BTW, limit4 would be great too :)
>>>
>> That version of jerk-limited just didn't quite work right with
>> spindle-synch.
>> IIRC the person doing it didn't need spindle-synch and got little help -
>> lost interest.
>> Not that i blame him - it looks very difficult!
>>
>> Our Jerk limitation implementation is on-going at:
> https://github.com/araisrobo/machinekit/tree/rpi2-spi
>
> It is with spindle synchronizing for a wood lathe machine:
> https://youtu.be/_3v9xDF-2nY
>
> We are trying a new approach to apply trajectory planning for spindle, i.e.
> treat spindle like an axis. Still lots of work to be done.
>
> -Yishin
> --
> ___
> 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] jerk limited trajectory

2015-12-22 Thread Jon Elson 
On 12/21/2015 11:59 PM, Chris Morley wrote:
>
> That version of jerk-limited just didn't quite work right 
> with spindle-synch. IIRC the person doing it didn't need 
> spindle-synch and got little help - lost interest. Not 
> that i blame him - it looks very difficult!
Yes, I think combining jerk limiting with spindle synch 
REQUIRES a compromise.  There are probably a couple ways to 
do it.  One is to just turn off jerk limiting when in 
spindle synch.  The other is to warn users that there is 
some initial part of the motion which will not be fully 
synched to the spindle, until the jerk limit has been 
integrated out.  This latter scheme will break taps on 
spindle reversal, so doesn't seem like the right approach.  
Maybe somebody else knows a better way?

Jon

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

Re: [Emc-developers] jerk limited trajectory

2015-12-22 Thread Viesturs Lācis 
2015-12-22 19:18 GMT+02:00 Jon Elson :
> One is to just turn off jerk limiting when in
> spindle synch.  The other is to warn users that there is
> some initial part of the motion which will not be fully
> synched to the spindle, until the jerk limit has been
> integrated out.

It seems to me that "turn off jerk limiting when in spindle synch
_and_ to warn users [about it]" is a good compromise :)

Viesturs

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

Re: [Emc-developers] jerk limited trajectory

2015-12-21 Thread Marius Alksnys 
12/17/2015 05:40 PM, Viesturs Lācis rašė:
...
> IIRC it has not been implemented in LinuxCNC, because it would not
> work for spindle-synchronised moves, but I might be totally wrong on
> that :))
>
>
> Viesturs

I see jerk limitation as very nice and important feature to have.
And I would go with a workaround like disabling jerk limitation only 
when doing spindle-synchronised move (or whatever else rarely used type 
of move) to let it work for the mainstream.

BTW, limit4 would be great too :)


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

Re: [Emc-developers] jerk limited trajectory

2015-12-20 Thread EBo 
On Dec 20 2015 11:48 AM, Gene Heskett wrote:
> On Sunday 20 December 2015 12:15:25 EBo wrote:
>
>> On Dec 17 2015 11:55 AM, Brian wrote:
>> > On Thursday, December 17, 2015, Gene Heskett 
>> >
>> > wrote:
>> >> On Thursday 17 December 2015 10:40:41 Viesturs Lācis wrote:
>> >> > AFAIK it has been few years since Araisrobo and Yishin Li have
>> >>
>> >> done
>> >>
>> >> > it; take a look here:
>> >>
>> >> 
>> https://github.com/araisrobo/linuxcnc/blob/master/src/emc/kinematic
>> >>s/t
>> >>
>> >> >p.c
>> >> >
>> >> > I found some threads from 2012 on developers mailing list, 
>> where
>> >> > Yishin discussed their work on that. This one seems even older,
>> >> > hopefully it would get you started on finding some more useful
>> >> > information:
>> >> > http://sourceforge.net/p/emc/mailman/message/27376772/
>> >> > IIRC it has not been implemented in LinuxCNC, because it would
>> >> > not work for spindle-synchronised moves, but I might be totally
>> >> > wrong
>> >>
>> >> on
>> >>
>> >> > that :))
>> >> >
>> >> >
>> >> > Viesturs
>> >>
>> >> Early on, in playing with G76, I found that the actual lockup 
>> phase
>> >> relationship was quite spindle-speed dependent, wrecking a few
>> >> threads
>> >> because I thought I could crank the speed up once the motion was
>> >> verified.
>> >>
>> >> And was advised that this was the Z accel lag, and that as long 
>> as
>> >> the
>> >> spindle speed was maintained, it would not be a problem.  Doing
>> >> that, it
>> >> hasn't been but I now restrict the spindle rpms to <300 also.  I
>> >> assume
>> >> the same caveat applies to G33.1, rigid tapping, so I don't crank
>> >> the
>> >> revs up there either.
>> >>
>> >> But I have wondered why, in the grand scheme of things, that 
>> delay,
>> >> which
>> >> can be obtained in degrees without a huge hassle, is not turned
>> >> into a
>> >> pre-start, that based on the rpms, puts the actual start z point
>> >> that
>> >> fraction of a turn ahead of the index, which would result in the
>> >> lock
>> >> being obtained such that the index to spindle phase was within an
>> >> encoder count (or closer) of zero.  Doing this on every Z restart
>> >> would
>> >> allow us to run it one or two cycles at 50 rpms to check 
>> clearances
>> >> etc,
>> >> then crank the spindle up to 500 revs and get the job done, 
>> without
>> >> wrecking the threads cut because the phase lag is a fixed time at
>> >> that
>> >> rpm. Obviously it would need stretching because of the higer 
>> speed
>> >> Z needs to accelerate to at a higher spindle rpm.
>> >>
>> >> I haven't tested recently, perhaps this is something that Robert
>> >> Ellenburg has addressed?
>> >>
>> >> Call me "Curious".
>> >>
>> >> Thanks.
>> >>
>> >> Cheers, Gene Heskett
>> >> --
>> >>
>> >> Theoretically, Z acceleration and jerk limits shouldn't be a 
>> major
>> >> concern
>> >
>> > in spindle sync moves, because the Z motion is being derived from 
>> a
>> > physical moving body (the spindle).  The natural occurring physics
>> > of the
>> > spindle motion should result in compatable motion for the Z axis.
>> >
>> > This breaks down if Z motion is to synchronize with an already
>> > moving spindle.  In this case, Z axis jerk and accel limits need 
>> to
>> > be observed.
>> > This shouldn't be an issue though because it is expected during 
>> the
>> > beginning of such a move that the Z axis will need a small amount 
>> of
>> > motion
>> > to lock phase.
>> >
>> > Another edge case is a spindle that can out accelerate the Z axis.
>> > IMO, The likelihood that the spindle is able to out accelerate the 
>> Z
>> > axis
>> > is so unlikely that I wouldn't make handling it a priority.
>> >
>> > Regarding Gene's statement regarding the phase relationship 
>> changing
>> > with
>> > spindle speed, that shouldn't be.  This is what the I term in a 
>> PID
>> > controller is there to do.  This may be a bug or a significant
>> > shortcoming
>> > of the code that should be looked at.
>>
>> Having any axis's acceleration or speed violate another's is 
>> something
>> we can check for.  The only time I have ever seen that to be 
>> possible
>> is on a machine that had a 5C collet head and would go from 0 to 
>> 6,000
>> RPM in almost an instant.  That would likely violate the z-axis
>> acceleration if you had it set to try to tap that fast.
>>
>> Do we have, or should we have, some code to verify that a given bit 
>> of
>> g-code does not violate any of the machine parameters?  I think the
>> most common will be you asked it to turn at 4,000RPM but the machine
>> can only do 1,400...
>>
>>EBo --
>>
>>
> I think thats already handled by common sense. I've never calculated 
> what
> my z axis, the slowest of the 3 on the new mill would need to follow 
> a
> 2500 rpm spindle, mainly because I haven't programmed the spindle for
> more than 300 revs while doing rigid tapping with fairly fine thread
> taps, in low gear.  Low gear spindle is about 1250-1300 wide open. So 
> it

Re: [Emc-developers] jerk limited trajectory

2015-12-20 Thread EBo 
On Dec 17 2015 11:55 AM, Brian wrote:
> On Thursday, December 17, 2015, Gene Heskett  
> wrote:
>
>> On Thursday 17 December 2015 10:40:41 Viesturs Lācis wrote:
>>
>> > AFAIK it has been few years since Araisrobo and Yishin Li have 
>> done
>> > it; take a look here:
>> > 
>> https://github.com/araisrobo/linuxcnc/blob/master/src/emc/kinematics/t
>> >p.c
>> >
>> > I found some threads from 2012 on developers mailing list, where
>> > Yishin discussed their work on that. This one seems even older,
>> > hopefully it would get you started on finding some more useful
>> > information:
>> > http://sourceforge.net/p/emc/mailman/message/27376772/
>> > IIRC it has not been implemented in LinuxCNC, because it would not
>> > work for spindle-synchronised moves, but I might be totally wrong 
>> on
>> > that :))
>> >
>> >
>> > Viesturs
>>
>> Early on, in playing with G76, I found that the actual lockup phase
>> relationship was quite spindle-speed dependent, wrecking a few 
>> threads
>> because I thought I could crank the speed up once the motion was
>> verified.
>>
>> And was advised that this was the Z accel lag, and that as long as 
>> the
>> spindle speed was maintained, it would not be a problem.  Doing 
>> that, it
>> hasn't been but I now restrict the spindle rpms to <300 also.  I 
>> assume
>> the same caveat applies to G33.1, rigid tapping, so I don't crank 
>> the
>> revs up there either.
>>
>> But I have wondered why, in the grand scheme of things, that delay, 
>> which
>> can be obtained in degrees without a huge hassle, is not turned into 
>> a
>> pre-start, that based on the rpms, puts the actual start z point 
>> that
>> fraction of a turn ahead of the index, which would result in the 
>> lock
>> being obtained such that the index to spindle phase was within an
>> encoder count (or closer) of zero.  Doing this on every Z restart 
>> would
>> allow us to run it one or two cycles at 50 rpms to check clearances 
>> etc,
>> then crank the spindle up to 500 revs and get the job done, without
>> wrecking the threads cut because the phase lag is a fixed time at 
>> that
>> rpm. Obviously it would need stretching because of the higer speed Z
>> needs to accelerate to at a higher spindle rpm.
>>
>> I haven't tested recently, perhaps this is something that Robert
>> Ellenburg has addressed?
>>
>> Call me "Curious".
>>
>> Thanks.
>>
>> Cheers, Gene Heskett
>> --
>>
>> Theoretically, Z acceleration and jerk limits shouldn't be a major 
>> concern
> in spindle sync moves, because the Z motion is being derived from a
> physical moving body (the spindle).  The natural occurring physics of 
> the
> spindle motion should result in compatable motion for the Z axis.
>
> This breaks down if Z motion is to synchronize with an already moving
> spindle.  In this case, Z axis jerk and accel limits need to be 
> observed.
> This shouldn't be an issue though because it is expected during the
> beginning of such a move that the Z axis will need a small amount of 
> motion
> to lock phase.
>
> Another edge case is a spindle that can out accelerate the Z axis.
> IMO, The likelihood that the spindle is able to out accelerate the Z 
> axis
> is so unlikely that I wouldn't make handling it a priority.
>
> Regarding Gene's statement regarding the phase relationship changing 
> with
> spindle speed, that shouldn't be.  This is what the I term in a PID
> controller is there to do.  This may be a bug or a significant 
> shortcoming
> of the code that should be looked at.

Having any axis's acceleration or speed violate another's is something 
we can check for.  The only time I have ever seen that to be possible is 
on a machine that had a 5C collet head and would go from 0 to 6,000 RPM 
in almost an instant.  That would likely violate the z-axis acceleration 
if you had it set to try to tap that fast.

Do we have, or should we have, some code to verify that a given bit of 
g-code does not violate any of the machine parameters?  I think the most 
common will be you asked it to turn at 4,000RPM but the machine can only 
do 1,400...

   EBo --


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

Re: [Emc-developers] jerk limited trajectory

2015-12-17 Thread Gene Heskett 
On Thursday 17 December 2015 10:40:41 Viesturs Lācis wrote:

> AFAIK it has been few years since Araisrobo and Yishin Li have done
> it; take a look here:
> https://github.com/araisrobo/linuxcnc/blob/master/src/emc/kinematics/t
>p.c
>
> I found some threads from 2012 on developers mailing list, where
> Yishin discussed their work on that. This one seems even older,
> hopefully it would get you started on finding some more useful
> information:
> http://sourceforge.net/p/emc/mailman/message/27376772/
> IIRC it has not been implemented in LinuxCNC, because it would not
> work for spindle-synchronised moves, but I might be totally wrong on
> that :))
>
>
> Viesturs

Early on, in playing with G76, I found that the actual lockup phase 
relationship was quite spindle-speed dependent, wrecking a few threads 
because I thought I could crank the speed up once the motion was 
verified.

And was advised that this was the Z accel lag, and that as long as the 
spindle speed was maintained, it would not be a problem.  Doing that, it 
hasn't been but I now restrict the spindle rpms to <300 also.  I assume 
the same caveat applies to G33.1, rigid tapping, so I don't crank the 
revs up there either.

But I have wondered why, in the grand scheme of things, that delay, which 
can be obtained in degrees without a huge hassle, is not turned into a 
pre-start, that based on the rpms, puts the actual start z point that 
fraction of a turn ahead of the index, which would result in the lock 
being obtained such that the index to spindle phase was within an 
encoder count (or closer) of zero.  Doing this on every Z restart would 
allow us to run it one or two cycles at 50 rpms to check clearances etc, 
then crank the spindle up to 500 revs and get the job done, without 
wrecking the threads cut because the phase lag is a fixed time at that 
rpm. Obviously it would need stretching because of the higer speed Z 
needs to accelerate to at a higher spindle rpm.

I haven't tested recently, perhaps this is something that Robert 
Ellenburg has addressed?

Call me "Curious".

Thanks.

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)
Some mill pix are at:
Genes Web page 

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

Re: [Emc-developers] jerk limited trajectory

2015-12-17 Thread Viesturs Lācis 
AFAIK it has been few years since Araisrobo and Yishin Li have done
it; take a look here:
https://github.com/araisrobo/linuxcnc/blob/master/src/emc/kinematics/tp.c

I found some threads from 2012 on developers mailing list, where
Yishin discussed their work on that. This one seems even older,
hopefully it would get you started on finding some more useful
information:
http://sourceforge.net/p/emc/mailman/message/27376772/
IIRC it has not been implemented in LinuxCNC, because it would not
work for spindle-synchronised moves, but I might be totally wrong on
that :))


Viesturs


2015-12-16 3:59 GMT+02:00 Rene Hopf :
> Hi,
> Are there any plans on jerk limitation? During my research I found this:
> https://github.com/cnc-club/linuxcnc/commit/c7f6861909a6e2e491d38059a1b7d26d91f4a8a0
>  
> 
> Has anyone ever seen or even tested this?
>
> Rene
> --
> ___
> 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] jerk limited trajectory

2015-12-17 Thread Brian 
On Thursday, December 17, 2015, Gene Heskett  wrote:

> On Thursday 17 December 2015 10:40:41 Viesturs Lācis wrote:
>
> > AFAIK it has been few years since Araisrobo and Yishin Li have done
> > it; take a look here:
> > https://github.com/araisrobo/linuxcnc/blob/master/src/emc/kinematics/t
> >p.c
> >
> > I found some threads from 2012 on developers mailing list, where
> > Yishin discussed their work on that. This one seems even older,
> > hopefully it would get you started on finding some more useful
> > information:
> > http://sourceforge.net/p/emc/mailman/message/27376772/
> > IIRC it has not been implemented in LinuxCNC, because it would not
> > work for spindle-synchronised moves, but I might be totally wrong on
> > that :))
> >
> >
> > Viesturs
>
> Early on, in playing with G76, I found that the actual lockup phase
> relationship was quite spindle-speed dependent, wrecking a few threads
> because I thought I could crank the speed up once the motion was
> verified.
>
> And was advised that this was the Z accel lag, and that as long as the
> spindle speed was maintained, it would not be a problem.  Doing that, it
> hasn't been but I now restrict the spindle rpms to <300 also.  I assume
> the same caveat applies to G33.1, rigid tapping, so I don't crank the
> revs up there either.
>
> But I have wondered why, in the grand scheme of things, that delay, which
> can be obtained in degrees without a huge hassle, is not turned into a
> pre-start, that based on the rpms, puts the actual start z point that
> fraction of a turn ahead of the index, which would result in the lock
> being obtained such that the index to spindle phase was within an
> encoder count (or closer) of zero.  Doing this on every Z restart would
> allow us to run it one or two cycles at 50 rpms to check clearances etc,
> then crank the spindle up to 500 revs and get the job done, without
> wrecking the threads cut because the phase lag is a fixed time at that
> rpm. Obviously it would need stretching because of the higer speed Z
> needs to accelerate to at a higher spindle rpm.
>
> I haven't tested recently, perhaps this is something that Robert
> Ellenburg has addressed?
>
> Call me "Curious".
>
> Thanks.
>
> Cheers, Gene Heskett
> --
>
> Theoretically, Z acceleration and jerk limits shouldn't be a major concern
in spindle sync moves, because the Z motion is being derived from a
physical moving body (the spindle).  The natural occurring physics of the
spindle motion should result in compatable motion for the Z axis.

This breaks down if Z motion is to synchronize with an already moving
spindle.  In this case, Z axis jerk and accel limits need to be observed.
This shouldn't be an issue though because it is expected during the
beginning of such a move that the Z axis will need a small amount of motion
to lock phase.

Another edge case is a spindle that can out accelerate the Z axis.
IMO, The likelihood that the spindle is able to out accelerate the Z axis
is so unlikely that I wouldn't make handling it a priority.

Regarding Gene's statement regarding the phase relationship changing with
spindle speed, that shouldn't be.  This is what the I term in a PID
controller is there to do.  This may be a bug or a significant shortcoming
of the code that should be looked at.

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

Re: [Emc-developers] jerk limited trajectory

2015-12-17 Thread Gene Heskett 
On Thursday 17 December 2015 13:55:53 Brian wrote:

> On Thursday, December 17, 2015, Gene Heskett  wrote:
> > On Thursday 17 December 2015 10:40:41 Viesturs Lācis wrote:
> > > AFAIK it has been few years since Araisrobo and Yishin Li have
> > > done it; take a look here:
> > > https://github.com/araisrobo/linuxcnc/blob/master/src/emc/kinemati
> > >cs/t p.c
> > >
> > > I found some threads from 2012 on developers mailing list, where
> > > Yishin discussed their work on that. This one seems even older,
> > > hopefully it would get you started on finding some more useful
> > > information:
> > > http://sourceforge.net/p/emc/mailman/message/27376772/
> > > IIRC it has not been implemented in LinuxCNC, because it would not
> > > work for spindle-synchronised moves, but I might be totally wrong
> > > on that :))
> > >
> > >
> > > Viesturs
> >
> > Early on, in playing with G76, I found that the actual lockup phase
> > relationship was quite spindle-speed dependent, wrecking a few
> > threads because I thought I could crank the speed up once the motion
> > was verified.
> >
> > And was advised that this was the Z accel lag, and that as long as
> > the spindle speed was maintained, it would not be a problem.  Doing
> > that, it hasn't been but I now restrict the spindle rpms to <300
> > also.  I assume the same caveat applies to G33.1, rigid tapping, so
> > I don't crank the revs up there either.
> >
> > But I have wondered why, in the grand scheme of things, that delay,
> > which can be obtained in degrees without a huge hassle, is not
> > turned into a pre-start, that based on the rpms, puts the actual
> > start z point that fraction of a turn ahead of the index, which
> > would result in the lock being obtained such that the index to
> > spindle phase was within an encoder count (or closer) of zero. 
> > Doing this on every Z restart would allow us to run it one or two
> > cycles at 50 rpms to check clearances etc, then crank the spindle up
> > to 500 revs and get the job done, without wrecking the threads cut
> > because the phase lag is a fixed time at that rpm. Obviously it
> > would need stretching because of the higer speed Z needs to
> > accelerate to at a higher spindle rpm.
> >
> > I haven't tested recently, perhaps this is something that Robert
> > Ellenburg has addressed?
> >
> > Call me "Curious".
> >
> > Thanks.
> >
> > Cheers, Gene Heskett
> > --
> >
> > Theoretically, Z acceleration and jerk limits shouldn't be a major
> > concern
>
> in spindle sync moves, because the Z motion is being derived from a
> physical moving body (the spindle).  The natural occurring physics of
> the spindle motion should result in compatable motion for the Z axis.
>
> This breaks down if Z motion is to synchronize with an already moving
> spindle.  In this case, Z axis jerk and accel limits need to be
> observed. This shouldn't be an issue though because it is expected
> during the beginning of such a move that the Z axis will need a small
> amount of motion to lock phase.
>
> Another edge case is a spindle that can out accelerate the Z axis.
> IMO, The likelihood that the spindle is able to out accelerate the Z
> axis is so unlikely that I wouldn't make handling it a priority.
>
> Regarding Gene's statement regarding the phase relationship changing
> with spindle speed, that shouldn't be.  This is what the I term in a
> PID controller is there to do.  This may be a bug or a significant
> shortcoming of the code that should be looked at.
>
> Brian

I don't know as I would label it a bug.  Its a known effect, 100%  
alleviated by maintaining a constant spindle rpms as the kick-in point 
is reached.  For this reason, particularly for rigid tapping, where the 
tapping load CAN slow the spindle if the tap is too big, it isn't a 
problem because Z remains locked to the spindle right thru the reversal 
at the end of the tap, and stays in sync until it reaches the synch 
point going back away.  At That point z stops and returns to the start 
point, while the spindle is doing its rev/fwd turnaround.

What I suggest would seem to be a quite desirable thing for LinuxCNC to 
do.

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)
Some mill pix are at:
Genes Web page 

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

[Emc-developers] jerk limited trajectory

2015-12-15 Thread Rene Hopf 
Hi,
Are there any plans on jerk limitation? During my research I found this:
https://github.com/cnc-club/linuxcnc/commit/c7f6861909a6e2e491d38059a1b7d26d91f4a8a0
 

Has anyone ever seen or even tested this?

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

Re: [Emc-developers] jerk limited trajectory

2015-12-15 Thread TJoseph Powderly 
the math jerk vs the actual jerk...
how the machine tool reacts rather than the velocity jerks that can be 
calculated...

maybe a test run could record the jerk and then
a filtered run could avoid those high speed, high mass, hair pin turns
or even hi speed pecking that actually hammers the bottom.

im not sure that position -error velocity-error accelleration-error
can show this. but maybe a cheap accellerometer could
(might double as an edge finder with a stylus)

tomp



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