Re: [Emc-users] jerk control

[Chris Albertson]

On Sun, Aug 22, 2021 at 5:15 PM John Dammeyer 
wrote:

>
>
> What's the goal?  To traverse the path as accurately as possible or to
> reduce the shaking from sudden speed changes (the jerk)?
>

"jerk" is not a chance in speed.  Jerk is change in acceleration.
 Planning an optimum jerk limited curved path in n-dimension has no closed
form solution.  I think you only option is to do a simulation out to some
future time horizon.   Actually for a machine tool, why not run the
simulation off-line and use as much time and computer power as it takes.

What is the goal?  Usually it is a complex compromise of time and accuracy.
  It could even be a different compromise at different locations on the part


> Mostly just confused.
> John
>
>
>
>
>
> > -Original Message-
> > From: Curtis Dutton [mailto:curtd...@gmail.com]
> > Sent: August-22-21 11:48 AM
> > To: Enhanced Machine Controller (EMC)
> > Subject: Re: [Emc-users] jerk control
> >
> > I have a desire to implement this.
> >
> >  My business is in need of another cnc router and I will be building as
> > high speed of a machine as I can afford. It is going to be a dual table
> but
> > a horizontal spindle. 1m x 1m working envelope. I plan on using linear
> > motors.
> >
> > It will require jerk limiting to really get the value out of the machine.
> >
> > I have been working on bits and pieces in my spare time but I have very
> > little time right now.
> >
> >
> > My main approach so far is
> >
> >
> >  The realtime motion component will be enhanced so as to interpolate
> nurbs
> > curves. Those curves need be in a specific form of parameterization.
> (coord
> > length parameterized)
> >
> >
> > The other part is in user space and it is the hard part. To perform
> > blending of line segments it converts segments to nurbs curves, and
> blends
> > them together by fitting a segment of a clothoid (euler spirals) in
> between
> > them. It must do all of this while fitting within all of the velocity,
> > accel, jerk and limit constraints. Then it reparameterizes these curves
> for
> > consumption by the motion component.
> >
> > This is essentially plotting a reasonable driving path on an N
> dimensional
> > race track.
> >
> >  From some of the papers that I have read it looks like it will involve
> > numerical integration and/or linear programming. Adding jerk equations
> into
> > standard physics makes it very much harder to solve. Closed form
> equations
> > don't really seem to exist. (If you have experience with this I could
> > sorely use pointers, links, papers)
> >
> >
> > Ultimately this is a very difficult task. Building a stripped down
> version
> > of a jerk controlled motion planner is what many people have done to
> earn a
> > PHD.
> >
> >
> > I would be happy to join up with anyone else that is interested in
> working
> > on this. Even ideas, papers, demos is very helpful. Timeline for this...
> > sadly a few years at best before completion.
> >
> >
> > Thanks,
> > Curt
> >
> > On Tue, Aug 17, 2021, 10:10 PM andrew beck 
> wrote:
> >
> > > Here is the text from your link sam
> > >
> > >
> > > Ramped velocity in this case just means constant acceleration over the
> > > whole segment. This is less optimal than a trapezoidal velocity
> profile,
> > > since the acceleration is not maximized. However, if the segment is
> short
> > > enough, there isn�t enough time to accelerate much before we hit the
> next
> > > segment. Recall the short line segments from the previous example.
> Since
> > > they�re lines, there�s no cornering acceleration, so we�re free to
> > > accelerate up to the requested speed. However, if this line is between
> two
> > > arcs, then it will have to quickly decelerate again to be within the
> > > maximum speed of the next segment. This means that we have a spike of
> > > acceleration, then a spike of deceleration, causing a large jerk, for
> very
> > > little performance gain. This setting is a way to eliminate this jerk
> for
> > > short segments.
> > >
> > > Basically, if a segment will complete in less time than 1 /
> > > ARC_BLEND_RAMP_FREQ, we don�t bother with a trapezoidal velocity
> profile on
> > > that segment, and use constant acceleration. (Setting
> ARC_BLEND_RAMP_FREQ =
> > > 1000 is equivalent to always using trapezoidal acceleration, if the
> servo
> > > loop is 1kHz).
> > >
> > > You can characterize the worst-case loss of performance by comparing
> the
> > > velocity that a trapezoidal profile reaches vs. the ramp:
> > >
> > > # v_ripple = a_max / (4.0 * f) # where: # v_ripple = average velocity
> > > "loss" due to ramping # a_max = max axis acceleration # f = cutoff
> > > frequency from INI
> > >
> > > For the aforementioned machine, the ripple for a 20Hz cutoff frequency
> is
> > > 100 / (4 * 20) = 1.25 IPS. This seems high, but keep in mind that it is
> > > only a worst-case estimate. In reality , the trapezoidal motion
> profile is
> > > limited by other factors, such as normal acceleration or 

Re: [Emc-users] jerk control

[andrew beck]

and I will be a happy man once some wonderful person works it out:)

On Mon, Aug 23, 2021 at 1:49 PM Curtis Dutton  wrote:

> The goal is allow both accuracy and speed. However there is a tradeoff
> between those two just as there is now.
>
>  During any move all vel, acc, jerk values must be coordinated to follow a
> given path. For a coordinated move any limiting constraints will limit the
> other related joints to prevent violations.
>
>
> To perform multiple move through a sequence of lines the motion planner has
> to blend moves and cut corners. The blend is also shaped to avoid violating
> any limits but go as fast as possible. The distance the corner can be cut
> by will be user specified. G64 just like now.
>
> Ultimatly the gcode program combined with your machine and its capabilities
> are still going to limit the upper feed rates that can be accomplished.
>
> With jerk limiting the max acceleration values for any given machine will
> be able to be increased while still having less following error. This
> should lead to decreased cycle times for any given g-code program.
>
>
>
>
> On Sun, Aug 22, 2021, 8:15 PM John Dammeyer 
> wrote:
>
> > This jerk control raises some questions for me.  They probably have
> simple
> > answers rather than as complex as jerk control but perhaps it's related.
> >
> > Each axis has a MAX_ACCELERATION value.  Simple math says that if X and Y
> > are moving at an identical velocity then the path of the tool is 45
> > degrees.
> >
> > I suspect that the MAX_ACCELERATION is exactly that: maximum.  If we want
> > that 45 degree line to remain straight then both axis have to accelerate
> at
> > the same rate and end up at the same velocity at the same time so the
> > acceleration that’s used is the lowest of the MAX_ACCELERATION value?
> >
> > From a feed rate perspective we want to get up to the target feed as
> > quickly as possible since chip load, tool rubbing etc. can have adverse
> > effects if the speed is too slow?
> >
> > By the same token the speed along that 45 degree path is the F parameter
> > so each axis speed isn't the F value but the amount required to create
> the
> > speed on that path?
> >
> > Finally if the combination of acceleration and distance is such that the
> F
> > parameter isn't reached before it's time to decelerate then the tool
> > reaches 0 before ever hitting the requested speed?
> >
> > This is all for a simple move that starts and stops.  And clearly would
> > cause a jerk like motion but it's precise from point A to point B.  As I
> > understand the jerk side of things the requirement is to look ahead at
> the
> > next move and only accelerate or decelerate as required to reach the new
> > velocity for each axis and change the rate of acceleration within that
> > envelope.
> >
> > But now the two axis are no longer following the target path right?
> >  There is one that has to slow down to half the speed while the other
> > accelerates up to twice the speed (for example).  The path followed now
> is
> > more complex?  And which acceleration is used and is it changed as the
> path
> > is followed?
> >
> > What's the goal?  To traverse the path as accurately as possible or to
> > reduce the shaking from sudden speed changes (the jerk)?
> >
> > Mostly just confused.
> > John
> >
> >
> >
> >
> >
> > > -Original Message-
> > > From: Curtis Dutton [mailto:curtd...@gmail.com]
> > > Sent: August-22-21 11:48 AM
> > > To: Enhanced Machine Controller (EMC)
> > > Subject: Re: [Emc-users] jerk control
> > >
> > > I have a desire to implement this.
> > >
> > >  My business is in need of another cnc router and I will be building as
> > > high speed of a machine as I can afford. It is going to be a dual table
> > but
> > > a horizontal spindle. 1m x 1m working envelope. I plan on using linear
> > > motors.
> > >
> > > It will require jerk limiting to really get the value out of the
> machine.
> > >
> > > I have been working on bits and pieces in my spare time but I have very
> > > little time right now.
> > >
> > >
> > > My main approach so far is
> > >
> > >
> > >  The realtime motion component will be enhanced so as to interpolate
> > nurbs
> > > curves. Those curves need be in a specific form of parameterization.
> > (coord
> > > length parameterized)
> > >
> > >
> > > The other part is in user space and it is the hard part. To perform
> > > blending of line segments it converts segments to nurbs curves, and
> > blends
> > > them together by fitting a segment of a clothoid (euler spirals) in
> > between
> > > them. It must do all of this while fitting within all of the velocity,
> > > accel, jerk and limit constraints. Then it reparameterizes these curves
> > for
> > > consumption by the motion component.
> > >
> > > This is essentially plotting a reasonable driving path on an N
> > dimensional
> > > race track.
> > >
> > >  From some of the papers that I have read it looks like it will involve
> > > numerical integration and/or 

Re: [Emc-users] jerk control

[Chris Albertson]

No closed form solution.   The develop a cost function and use
numeric optimization to find lowest cost.   This is what Boston Dynamics
does now and they do it in real time.

The idea was first used for process control in oil refineries but it works
in any case where the forward comutions is "easy" but the backward one is
very hard.  Sy you have an "n" dimensional problem, you first write a
simulation and then put some guessed values for all n parameters and
compute the state at some small "t", typically milliseconds ahead.  Then do
it again and again for all reasonablevalies ofparameters for several
seconds out.  You are searching a HUGE space using the forward equations.
and doing a MANY step look ahead.  The goal is minimum cost at some distant
time (like a few seconds.YOu recompute this every cycle.Yes it
requires a trillion computations per second, but so what, multi teraflop
machines cost only a few hundred dollars today.   The magic Google search
term is "MPC"

In you case the parameters are the speed of the motors and the cost is has
close the cut is to the desired shape + how long it takes to cut the metal.
  "jerk" will just take care if itself.  All the smarts is in (1) youe cost
funtion and (2) your forward kinetics model.

This was developed by chemical plants by today we see Boston Dynamics using
it to make robots molve like animalsand we see SpaceX use it to mke falling
rockets hit the landing pad.  It basicallyturns a very hard inverse problem
into a very big search and numerical otimization.   It works because
optimization is well understood.

Tht said, I'd expect machinists would be afraid of this because it does not
give an exact solution but only the "best that can be found, given the time
limit and compute power available".  This is very good if you are a rocket
falling from the sky, It does no good to be "perfect" if you are a
millisecond late.  So a machinest might take some inperation from MPC and
turn a a hard inverse case into a large but "easy" search.

https://en.wikipedia.org/wiki/Model_predictive_control

On Sun, Aug 22, 2021 at 11:51 AM Curtis Dutton  wrote:

> I have a desire to implement this.
>
>  My business is in need of another cnc router and I will be building as
> high speed of a machine as I can afford. It is going to be a dual table but
> a horizontal spindle. 1m x 1m working envelope. I plan on using linear
> motors.
>
> It will require jerk limiting to really get the value out of the machine.
>
> I have been working on bits and pieces in my spare time but I have very
> little time right now.
>
>
> My main approach so far is
>
>
>  The realtime motion component will be enhanced so as to interpolate nurbs
> curves. Those curves need be in a specific form of parameterization. (coord
> length parameterized)
>
>
> The other part is in user space and it is the hard part. To perform
> blending of line segments it converts segments to nurbs curves, and blends
> them together by fitting a segment of a clothoid (euler spirals) in between
> them. It must do all of this while fitting within all of the velocity,
> accel, jerk and limit constraints. Then it reparameterizes these curves for
> consumption by the motion component.
>
> This is essentially plotting a reasonable driving path on an N dimensional
> race track.
>
>  From some of the papers that I have read it looks like it will involve
> numerical integration and/or linear programming. Adding jerk equations into
> standard physics makes it very much harder to solve. Closed form equations
> don't really seem to exist. (If you have experience with this I could
> sorely use pointers, links, papers)
>
>
> Ultimately this is a very difficult task. Building a stripped down version
> of a jerk controlled motion planner is what many people have done to earn a
> PHD.
>
>
> I would be happy to join up with anyone else that is interested in working
> on this. Even ideas, papers, demos is very helpful. Timeline for this...
> sadly a few years at best before completion.
>
>
> Thanks,
> Curt
>
> On Tue, Aug 17, 2021, 10:10 PM andrew beck 
> wrote:
>
> > Here is the text from your link sam
> >
> >
> > Ramped velocity in this case just means constant acceleration over the
> > whole segment. This is less optimal than a trapezoidal velocity profile,
> > since the acceleration is not maximized. However, if the segment is short
> > enough, there isn’t enough time to accelerate much before we hit the next
> > segment. Recall the short line segments from the previous example. Since
> > they’re lines, there’s no cornering acceleration, so we’re free to
> > accelerate up to the requested speed. However, if this line is between
> two
> > arcs, then it will have to quickly decelerate again to be within the
> > maximum speed of the next segment. This means that we have a spike of
> > acceleration, then a spike of deceleration, causing a large jerk, for
> very
> > little performance gain. This setting is a way to eliminate this 

Re: [Emc-users] jerk control

[Curtis Dutton]

The goal is allow both accuracy and speed. However there is a tradeoff
between those two just as there is now.

 During any move all vel, acc, jerk values must be coordinated to follow a
given path. For a coordinated move any limiting constraints will limit the
other related joints to prevent violations.


To perform multiple move through a sequence of lines the motion planner has
to blend moves and cut corners. The blend is also shaped to avoid violating
any limits but go as fast as possible. The distance the corner can be cut
by will be user specified. G64 just like now.

Ultimatly the gcode program combined with your machine and its capabilities
are still going to limit the upper feed rates that can be accomplished.

With jerk limiting the max acceleration values for any given machine will
be able to be increased while still having less following error. This
should lead to decreased cycle times for any given g-code program.




On Sun, Aug 22, 2021, 8:15 PM John Dammeyer  wrote:

> This jerk control raises some questions for me.  They probably have simple
> answers rather than as complex as jerk control but perhaps it's related.
>
> Each axis has a MAX_ACCELERATION value.  Simple math says that if X and Y
> are moving at an identical velocity then the path of the tool is 45
> degrees.
>
> I suspect that the MAX_ACCELERATION is exactly that: maximum.  If we want
> that 45 degree line to remain straight then both axis have to accelerate at
> the same rate and end up at the same velocity at the same time so the
> acceleration that’s used is the lowest of the MAX_ACCELERATION value?
>
> From a feed rate perspective we want to get up to the target feed as
> quickly as possible since chip load, tool rubbing etc. can have adverse
> effects if the speed is too slow?
>
> By the same token the speed along that 45 degree path is the F parameter
> so each axis speed isn't the F value but the amount required to create the
> speed on that path?
>
> Finally if the combination of acceleration and distance is such that the F
> parameter isn't reached before it's time to decelerate then the tool
> reaches 0 before ever hitting the requested speed?
>
> This is all for a simple move that starts and stops.  And clearly would
> cause a jerk like motion but it's precise from point A to point B.  As I
> understand the jerk side of things the requirement is to look ahead at the
> next move and only accelerate or decelerate as required to reach the new
> velocity for each axis and change the rate of acceleration within that
> envelope.
>
> But now the two axis are no longer following the target path right?
>  There is one that has to slow down to half the speed while the other
> accelerates up to twice the speed (for example).  The path followed now is
> more complex?  And which acceleration is used and is it changed as the path
> is followed?
>
> What's the goal?  To traverse the path as accurately as possible or to
> reduce the shaking from sudden speed changes (the jerk)?
>
> Mostly just confused.
> John
>
>
>
>
>
> > -Original Message-
> > From: Curtis Dutton [mailto:curtd...@gmail.com]
> > Sent: August-22-21 11:48 AM
> > To: Enhanced Machine Controller (EMC)
> > Subject: Re: [Emc-users] jerk control
> >
> > I have a desire to implement this.
> >
> >  My business is in need of another cnc router and I will be building as
> > high speed of a machine as I can afford. It is going to be a dual table
> but
> > a horizontal spindle. 1m x 1m working envelope. I plan on using linear
> > motors.
> >
> > It will require jerk limiting to really get the value out of the machine.
> >
> > I have been working on bits and pieces in my spare time but I have very
> > little time right now.
> >
> >
> > My main approach so far is
> >
> >
> >  The realtime motion component will be enhanced so as to interpolate
> nurbs
> > curves. Those curves need be in a specific form of parameterization.
> (coord
> > length parameterized)
> >
> >
> > The other part is in user space and it is the hard part. To perform
> > blending of line segments it converts segments to nurbs curves, and
> blends
> > them together by fitting a segment of a clothoid (euler spirals) in
> between
> > them. It must do all of this while fitting within all of the velocity,
> > accel, jerk and limit constraints. Then it reparameterizes these curves
> for
> > consumption by the motion component.
> >
> > This is essentially plotting a reasonable driving path on an N
> dimensional
> > race track.
> >
> >  From some of the papers that I have read it looks like it will involve
> > numerical integration and/or linear programming. Adding jerk equations
> into
> > standard physics makes it very much harder to solve. Closed form
> equations
> > don't really seem to exist. (If you have experience with this I could
> > sorely use pointers, links, papers)
> >
> >
> > Ultimately this is a very difficult task. Building a stripped down
> version
> > of a jerk controlled motion planner 

Re: [Emc-users] jerk control

[John Dammeyer]

This jerk control raises some questions for me.  They probably have simple 
answers rather than as complex as jerk control but perhaps it's related.

Each axis has a MAX_ACCELERATION value.  Simple math says that if X and Y are 
moving at an identical velocity then the path of the tool is 45 degrees.  

I suspect that the MAX_ACCELERATION is exactly that: maximum.  If we want that 
45 degree line to remain straight then both axis have to accelerate at the same 
rate and end up at the same velocity at the same time so the acceleration 
that’s used is the lowest of the MAX_ACCELERATION value?

From a feed rate perspective we want to get up to the target feed as quickly as 
possible since chip load, tool rubbing etc. can have adverse effects if the 
speed is too slow?

By the same token the speed along that 45 degree path is the F parameter so 
each axis speed isn't the F value but the amount required to create the speed 
on that path?

Finally if the combination of acceleration and distance is such that the F 
parameter isn't reached before it's time to decelerate then the tool reaches 0 
before ever hitting the requested speed?

This is all for a simple move that starts and stops.  And clearly would cause a 
jerk like motion but it's precise from point A to point B.  As I understand the 
jerk side of things the requirement is to look ahead at the next move and only 
accelerate or decelerate as required to reach the new velocity for each axis 
and change the rate of acceleration within that envelope. 

But now the two axis are no longer following the target path right?   There is 
one that has to slow down to half the speed while the other accelerates up to 
twice the speed (for example).  The path followed now is more complex?  And 
which acceleration is used and is it changed as the path is followed?

What's the goal?  To traverse the path as accurately as possible or to reduce 
the shaking from sudden speed changes (the jerk)?

Mostly just confused.
John





> -Original Message-
> From: Curtis Dutton [mailto:curtd...@gmail.com]
> Sent: August-22-21 11:48 AM
> To: Enhanced Machine Controller (EMC)
> Subject: Re: [Emc-users] jerk control
> 
> I have a desire to implement this.
> 
>  My business is in need of another cnc router and I will be building as
> high speed of a machine as I can afford. It is going to be a dual table but
> a horizontal spindle. 1m x 1m working envelope. I plan on using linear
> motors.
> 
> It will require jerk limiting to really get the value out of the machine.
> 
> I have been working on bits and pieces in my spare time but I have very
> little time right now.
> 
> 
> My main approach so far is
> 
> 
>  The realtime motion component will be enhanced so as to interpolate nurbs
> curves. Those curves need be in a specific form of parameterization. (coord
> length parameterized)
> 
> 
> The other part is in user space and it is the hard part. To perform
> blending of line segments it converts segments to nurbs curves, and blends
> them together by fitting a segment of a clothoid (euler spirals) in between
> them. It must do all of this while fitting within all of the velocity,
> accel, jerk and limit constraints. Then it reparameterizes these curves for
> consumption by the motion component.
> 
> This is essentially plotting a reasonable driving path on an N dimensional
> race track.
> 
>  From some of the papers that I have read it looks like it will involve
> numerical integration and/or linear programming. Adding jerk equations into
> standard physics makes it very much harder to solve. Closed form equations
> don't really seem to exist. (If you have experience with this I could
> sorely use pointers, links, papers)
> 
> 
> Ultimately this is a very difficult task. Building a stripped down version
> of a jerk controlled motion planner is what many people have done to earn a
> PHD.
> 
> 
> I would be happy to join up with anyone else that is interested in working
> on this. Even ideas, papers, demos is very helpful. Timeline for this...
> sadly a few years at best before completion.
> 
> 
> Thanks,
> Curt
> 
> On Tue, Aug 17, 2021, 10:10 PM andrew beck  wrote:
> 
> > Here is the text from your link sam
> >
> >
> > Ramped velocity in this case just means constant acceleration over the
> > whole segment. This is less optimal than a trapezoidal velocity profile,
> > since the acceleration is not maximized. However, if the segment is short
> > enough, there isn�t enough time to accelerate much before we hit the next
> > segment. Recall the short line segments from the previous example. Since
> > they�re lines, there�s no cornering acceleration, so we�re free to
> > accelerate up to the requested speed. However, if this line is between two
> > arcs, then it will have to quickly decelerate again to be within the
> > maximum speed of the next segment. This means that we have a spike of
> > acceleration, then a spike of deceleration, causing a large jerk, for very
> > 

Re: [Emc-users] jerk control

[Curtis Dutton]

I have a desire to implement this.

 My business is in need of another cnc router and I will be building as
high speed of a machine as I can afford. It is going to be a dual table but
a horizontal spindle. 1m x 1m working envelope. I plan on using linear
motors.

It will require jerk limiting to really get the value out of the machine.

I have been working on bits and pieces in my spare time but I have very
little time right now.


My main approach so far is


 The realtime motion component will be enhanced so as to interpolate nurbs
curves. Those curves need be in a specific form of parameterization. (coord
length parameterized)


The other part is in user space and it is the hard part. To perform
blending of line segments it converts segments to nurbs curves, and blends
them together by fitting a segment of a clothoid (euler spirals) in between
them. It must do all of this while fitting within all of the velocity,
accel, jerk and limit constraints. Then it reparameterizes these curves for
consumption by the motion component.

This is essentially plotting a reasonable driving path on an N dimensional
race track.

 From some of the papers that I have read it looks like it will involve
numerical integration and/or linear programming. Adding jerk equations into
standard physics makes it very much harder to solve. Closed form equations
don't really seem to exist. (If you have experience with this I could
sorely use pointers, links, papers)


Ultimately this is a very difficult task. Building a stripped down version
of a jerk controlled motion planner is what many people have done to earn a
PHD.


I would be happy to join up with anyone else that is interested in working
on this. Even ideas, papers, demos is very helpful. Timeline for this...
sadly a few years at best before completion.


Thanks,
Curt

On Tue, Aug 17, 2021, 10:10 PM andrew beck  wrote:

> Here is the text from your link sam
>
>
> Ramped velocity in this case just means constant acceleration over the
> whole segment. This is less optimal than a trapezoidal velocity profile,
> since the acceleration is not maximized. However, if the segment is short
> enough, there isn’t enough time to accelerate much before we hit the next
> segment. Recall the short line segments from the previous example. Since
> they’re lines, there’s no cornering acceleration, so we’re free to
> accelerate up to the requested speed. However, if this line is between two
> arcs, then it will have to quickly decelerate again to be within the
> maximum speed of the next segment. This means that we have a spike of
> acceleration, then a spike of deceleration, causing a large jerk, for very
> little performance gain. This setting is a way to eliminate this jerk for
> short segments.
>
> Basically, if a segment will complete in less time than 1 /
> ARC_BLEND_RAMP_FREQ, we don’t bother with a trapezoidal velocity profile on
> that segment, and use constant acceleration. (Setting ARC_BLEND_RAMP_FREQ =
> 1000 is equivalent to always using trapezoidal acceleration, if the servo
> loop is 1kHz).
>
> You can characterize the worst-case loss of performance by comparing the
> velocity that a trapezoidal profile reaches vs. the ramp:
>
> # v_ripple = a_max / (4.0 * f) # where: # v_ripple = average velocity
> "loss" due to ramping # a_max = max axis acceleration # f = cutoff
> frequency from INI
>
> For the aforementioned machine, the ripple for a 20Hz cutoff frequency is
> 100 / (4 * 20) = 1.25 IPS. This seems high, but keep in mind that it is
> only a worst-case estimate. In reality , the trapezoidal motion profile is
> limited by other factors, such as normal acceleration or requested
> velocity, and so the actual performance loss should be much smaller.
> Increasing the cutoff frequency can squeeze out more performance, but make
> the motion rougher due to acceleration discontinuities. A value in the
> range 20Hz to 200Hz should be reasonable to start.
>
> Finally, no amount of tweaking will speed up a toolpath with lots of small,
> tight corners, since you’re limited by cornering acceleration.
>
> On Wed, Aug 18, 2021, 2:06 PM John Dammeyer 
> wrote:
>
> > This is what we're talking about right?
> > Ramping acceleration?
> > https://www.mmsonline.com/articles/understanding-jerk-control
> >
> > John
> >
> >
> > > -Original Message-
> > > From: Feral Engineer [mailto:theferalengin...@gmail.com]
> > > Sent: August-17-21 6:46 PM
> > > To: Enhanced Machine Controller (EMC)
> > > Subject: Re: [Emc-users] jerk control
> > >
> > > I'm curious what the current level of block lookahead is on lcnc
> compared
> > > to commercial controls. Anyone know the amount of data buffering that
> it
> > > can handle?
> > >
> > > Phil T.
> > > The Feral Engineer
> > >
> > > Check out my LinuxCNC tutorials, machine builds and other antics at
> > > www.youtube.com/c/theferalengineer
> > >
> > > Help support my channel efforts and coffee addiction:
> > > www.patreon.com/theferalengineer
> > >
> 

Re: [Emc-users] It took nearly 2 years, but I found it!

[Gene Heskett]

On Sunday 22 August 2021 01:06:24 dva...@internode.on.net wrote:

>  On 21.08.21 08:50, Gene Heskett wrote:
>   > The default desktop, xfce4, of our buster installer, steals the
> F10 key
>   > to bring up the terminals menu pulldown. But for an old hand
> that's a
>   > pain in the ass because it nakes you hunt up the mouse and click
> on the
>   > F10 button to quit mc. And it is not in the /etc/xfce4 keyboard
> related
>   > menu's anyplace so is not easily found and turned off.
>   >
>   > Its actually in the terminal preferences, with a default of on
> and you
>   > have to checkmark it to turn it off. So now I can use mc from the
>   > command line.
>
>   Many thanks, Gene, for the pointer. I've just used that to clobber
> its
>   hijacking of F1 as well, as I use that in Vim, and Mutt uses it for
> its
>   manual. Not that I've been using xfce-terminal until
> (coincidentally)
>   trying it out half an hour ago. The old-fashioned xterms I use
> don't
>   hijack function keys, so I haven't had the problem. However, even
> using:
>   XTERM="/usr/bin/xterm -u8" doesn't ensure it displays all utf8
> characters,
>   which is distinctly annoying. (Recently, `'` and `-` in list posts
> have
>   been rendering as small squares when arriving as two-byte
> characters for
>   some reason.)
>   
>
>   Now I'm tossing up whether to invest time in finding an xterm utf8
> fix,
>   or fixing the other problem with xfce-term; --color-text=yellow
> shows as
>   orange, which contrasts poorly with --color-bg=darkslategrey . Add
> that
>   the colours in xfce-term are washed-out, and I'm wondering if it's
>   worth pursuing. (Having used those xterm colours since SunOS
> 4.1.3,  back in the 1990s, I'm disinclined to change for no good
> reason.)
>
>   Ah, uxterm is better; it handles `'` and `-`better ... but not
> everything.It also handles the classical options: uxterm -bg
> darkslategrey -fg yellow
>  
>
> Erik
>
I am rather a rabid fan of two terminal proggy's.

Old kde, now tde's "konsole", and xfce4's default terminal. Except for 
the key stealing in xfce4, which is enough to upset the Pope, both have 
decent color choices and don't go out of their way to miss-treat utf-8 
charsets. My guess is that neither one, treat other languages full of 
chars only available from the alt + keystrokes well.

A native english speaker's (me) alphabet does not use the alt keys except 
for the old DEC's using them as alternate control keys, I once had some 
fun making a coco3 talk like it was a VT-220. I re-wrote a VT-100 
program to do it because the only VT-220 in the whole station ate its 
h.o.t. and DEC didn't have the h.o.t. and wanted around 3 thou for a new 
VT-540 terminal.  Dec went w/o that sale, and the PDP-11/23a it ran self 
destructed the whole CBS affiliate Satellite controls by crashing 
multiple times a day.  And DEC couldn't fix it. Changed everything it it 
except the frame rail bearing its serial number. So it got replaced by 
an IBM, on CBS's dime, which sat there and ran for the next decade.

Anyway, I'm glad I finally found it, and that its helped somebody else 
now.

Take care Erik.

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


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