High speed interpolation for micro-line trajectory and adaptive
real-time look-ahead scheme in CNC machining
http://www.mmrc.iss.ac.cn/~xgao/papernc/2011-scichina-1.pdf
Joachim
--
Live Security Virtual Conference
] Trajectory planning and other topics from a
EMC(LinuxCNC) newbie (TheNewbie)
To: EMC2-Users-List emc-users@lists.sourceforge.net
Date: Sunday, April 22, 2012, 11:51 PM
On Sun, 22 Apr 2012 20:43:05 -0400,
you wrote:
What does f^^^ mean? That's not the level of discourse
we expect from
http://hal.archives-ouvertes.fr/docs/00/67/91/18/PDF/2012_beudaert_lavernhe_tournier_Feedrate_interpolation_with_axis_jerk_constraints_on_5_axis_NURBS_and_G1_tool_path.pdf
Joachim
--
Live Security Virtual Conference
On 24 April 2012 03:19, Chris Morley chrisinnana...@hotmail.com wrote:
And on the side of that who would/could document the
innards of linuxcnc so some less skilled programmers
could contribute.
I think somebody is already looking at this.
I think HAL as a whole would be pretty much just
An easily customizable GUI would be nice. You very often need to be able
to add or remove GUI features depending on the machine. This and jog
while paused are the main reasons why I still use Mach on my mill.
Les
Of course I'm thinking on the developers side, what do integrators
wish for? I
On 24 April 2012 11:30, Les Newell les.new...@fastmail.co.uk wrote:
An easily customizable GUI would be nice.
Have a look at gscreen, which is a UI written by Chris Morley entirely in Glade
Hi,
Time to give my point of view (really interesting threat).
IMHO, stopping inside the next code block is absolutely not needed. What
is needed, is that all processed lookahead line are stocked inside the
real-time part (EMC) and not in Axis or any other application. (EMC will
eat as many
S curve accels are very important on fast machines and very desirable on
high inertia machines at lower speeds.
Are people happy with the GUI/ screen options that are starting
to open up?
Yes, Extremely happy! :-)
GladeVCP, Gscreen, and Touchy are a huge steps forward.
Dave
On 4/23/2012
Strictly from an outside observer.. I would thing that modularizing (is
that even a word) linuxcnc so like hal (that can run by itself) each
'module' could be replaced with a different one. So - say someone
writes a different g-code parser.. or a different TP.. or whatever.
These could be
2012/4/23 Steve Blackmore st...@pilotltd.net:
What is ja3?
Joints_axes3 branch in master git repository.
Is it any wonder that Joe Public has such a poor
opinion of EMC/LinuxCNC!! - I've been here 4 years and you've yet to
convince me it's not a closed shop speaking in a secret language.
let's discuss terminology for a minute (paths vs gcode segments)
we have:
1. linear G-code programs (no oword control structures)
2. G-code with arbitrary control structures
3. Some other yet-to-be-invented language for machine control.
execution of any such program generates a path (sequence of
On Sun, 22 Apr 2012 20:43:05 -0400, you wrote:
What does f^^^ mean? That's not the level of discourse we expect from
our colleagues. I'd suggest that if you can't be civil, you should be gone.
Please.
Apologies - no offense meant, just an everyday expression from a plain
speaking northerner.
On Mon, 23 Apr 2012 09:05:17 +0300, you wrote:
2012/4/23 Steve Blackmore st...@pilotltd.net:
What is ja3?
Joints_axes3 branch in master git repository.
Is it any wonder that Joe Public has such a poor
opinion of EMC/LinuxCNC!! - I've been here 4 years and you've yet to
convince me it's not
On 23 April 2012 01:31, Steve Blackmore st...@pilotltd.net wrote:
What the f^^^ is ja3?
It isn't really of much relevance to the general user at the moment,
but it is a development branch in which there is no longer an explicit
link between axes and joints. There are places in the current
On 4/23/2012 2:24 AM, Michael Haberler wrote:
let's discuss terminology for a minute (paths vs gcode segments)
we have:
1. linear G-code programs (no oword control structures)
2. G-code with arbitrary control structures
3. Some other yet-to-be-invented language for machine control.
I was searching the web and came across this paper:
about nurbs planning including s curve acceleration.
www.cadanda.com/CAD_4_1-4__34.PDF
Above my pay grade but interesting.
I was also thinking it would be interesting to discuss
the frame work of a linuxcnc3.
Is it useful to start clean on
On 21.04.12 23:23, Jon Elson wrote:
Viesturs Lācis wrote:
What I see the big issue for solving this in trajectory planner or
whatever _inside_ LinuxCNC is that I do not see, how to determine by
some hard facts, what is the best way to determine the lookup amount.
The number of blocks
gents, you are busily inventing path queueing mechanism number 3. The existing
ones are: CRC offset curve aka queued_canon, and NCD aka chained_points.
Other ideas have been floating around like a circular buffer in front of motion
so motions can be stepped back.
If this goes on like
On 4/22/2012 11:07 AM, Michael Haberler wrote:
gents, you are busily inventing path queueing mechanism number 3. The
existing ones are: CRC offset curve aka queued_canon, and NCD aka
chained_points.
Michael:
I'm trying to get up to speed on the issues discussed in this thread.
Not being an
On 22 April 2012 16:07, Michael Haberler mai...@mah.priv.at wrote:
gents, you are busily inventing path queueing mechanism number 3. The
existing ones are: CRC offset curve aka queued_canon, and NCD aka
chained_points.
I think CRC is Cutter Radius Compensation and NCD os Naive CAM detection?
On Sun, 22 Apr 2012 20:48:56 +0100, you wrote:
On 22 April 2012 16:07, Michael Haberler mai...@mah.priv.at wrote:
gents, you are busily inventing path queueing mechanism number 3. The
existing ones are: CRC offset curve aka queued_canon, and NCD aka
chained_points.
I think CRC is Cutter
On 04/22/2012 08:31 PM, Steve Blackmore wrote:
On Sun, 22 Apr 2012 20:48:56 +0100, you wrote:
On 22 April 2012 16:07, Michael Haberlermai...@mah.priv.at wrote:
gents, you are busily inventing path queueing mechanism number 3. The
existing ones are: CRC offset curve aka queued_canon, and NCD
John Q. Public has no idea what Emc2/LinuxCNC is. Their opinion is
absolutely meaningless. The individuals searching for a control for a
machine tool will have some understanding and ask some questions. The level
of the question will reveal the level understanding of any certain area.
The list
On 4/22/2012 3:48 PM, andy pugh wrote:
On 22 April 2012 16:07, Michael Haberlermai...@mah.priv.at wrote:
gents, you are busily inventing path queueing mechanism number 3. The
existing ones are: CRC offset curve aka queued_canon, and NCD aka
chained_points.
I think CRC is Cutter Radius
Erik Christiansen wrote:
Jon, there's probably no need to do this backwards. Look-ahead only
needs to be simple look-ahead, nothing more, AIUI. The current velocity
(feedrate) is known, and the stopping distance for the machine at that
velocity is fixed.
So, by summing immediately upcoming
Michael Haberler wrote:
I would also think the effort is considerable, and would not necessarily
recommend grafting this onto the current code. But then it's time to start
collecting ideas for Linuxcnc3.
Wow, a lot of details. Well, certainly this is not something to be
patched-on in a
2012/4/21 Jon Elson el...@pico-systems.com:
Stuart Stevenson wrote:
Would a read ahead of 1000 lines be more time consuming than the NURB
calculation?
A modest NURBS surface could be scanned pretty quickly to find the sharp
edges,
if any. 1000 block lookahead may not be necessary, even 100
On 4/20/2012 6:29 PM, Scott Hasse wrote:
Unfortunately, this approach doesn't work well for things like plastic
extrusion where it can be difficult to control the extrusion rate precisely.
Repraps, etc are able to succeed in part because they take a very naive
approach to trajectory
: Re: [Emc-users] Trajectory planning and other topics from a
EMC(LinuxCNC) newbie (TheNewbie)
To: Enhanced Machine Controller (EMC) emc-users@lists.sourceforge.net
Date: Friday, April 20, 2012, 9:54 AM
andy pugh wrote:
As I said earlier, I don't think this is a Lookahead
problem
On 20.04.12 12:25, Jon Elson wrote:
Stuart Stevenson wrote:
Doesn't even G02/G03 result in a series of very small linear moves sent to
the servo motors? Wouldn't a NURB conversion do the same thing
Yes, in a way. But, the G02/G03 is known to be a single move, so
there is no velocity
Viesturs Lācis wrote:
2012/4/21 Jon Elson el...@pico-systems.com:
Stuart Stevenson wrote:
Would a read ahead of 1000 lines be more time consuming than the NURB
calculation?
A modest NURBS surface could be scanned pretty quickly to find the sharp
edges,
if any. 1000 block
2012/4/21 Jon Elson el...@pico-systems.com:
The real problem I see is that RATIONAL G-code that was correctly written to
perform a particular operation cannot be executed as fast as the machine and
drives COULD allow it to go, due to the stop on next block requirement.
I agree.
What I see the
Gentlemen,
Since we have discussed this so long I have remembered a project that
would be similar and maybe be completed at the same time. I want to
implement 5 axis cutter compensation. Currently, LinuxCNC's cutter
compensation takes the cutter radius into consideration. This makes the
the texture advantage of nice
feedrate smoothness.
--- On Sat, 4/21/12, Viesturs Lācis viesturs.la...@gmail.com wrote:
From: Viesturs Lācis viesturs.la...@gmail.com
Subject: Re: [Emc-users] Trajectory planning and other topics from a
EMC(LinuxCNC) newbie (TheNewbie)
To: Enhanced Machine
Viesturs Lācis wrote:
What I see the big issue for solving this in trajectory planner or
whatever _inside_ LinuxCNC is that I do not see, how to determine by
some hard facts, what is the best way to determine the lookup amount.
The number of blocks you need to look ahead is variable. The
2012/4/20 Scott Hasse scott.ha...@gmail.com:
It seems to me that the likelihood of fixing all of the methods of gcode
generation such that they don't generate short line segments is
approximately zero. Also, it seems that even if a proprietary LinuxCNC
gcode extension allowed arbitrary plane
another (think of moulding trim, or
extrusions)..
--- On Thu, 4/19/12, Viesturs Lācis viesturs.la...@gmail.com wrote:
From: Viesturs Lācis viesturs.la...@gmail.com
Subject: Re: [Emc-users] Trajectory planning and other topics from a
EMC(LinuxCNC) newbie (TheNewbie)
To: Enhanced Machine
On 20 April 2012 07:53, Viesturs Lācis viesturs.la...@gmail.com wrote:
The only thing I do not get, is how to do the reverse math - describe
a line, if (a lot of) points on it are provided. It does not seem to
be problem finding formulas on the web to calculate a coordinates of a
point on a
On 20 April 2012 06:42, Scott Hasse scott.ha...@gmail.com wrote:
Rather than trying to solve this problem in a million places not under our
control, doesn't it make sense to try and solve it properly in one place
and look more closely at using more than one line for look ahead?
As I said
On 20.04.12 09:53, Viesturs Lācis wrote:
I was thinking about Kenneth's idea:
2012/4/19 Kenneth Lerman kenneth.ler...@se-ltd.com:
Is anyone here interested in writing a filter that takes as input a
tolerance (error band) and a sequence of motions (arcs and line
segments) and generates a
On 20 April 2012 09:52, Erik Christiansen dva...@internode.on.net wrote:
But isn't the LinuxCNC dictum Must be able to come to a dead stop
within the current line segment unnecessary and unhelpful when
following a piecewise linear approximation of a smooth curve?
Actually, I am unclear if this
if speed is an issue, consider the solution of being a doctor: have patience.
--- On Thu, 4/19/12, Stephen Dubovsky smdubov...@gmail.com wrote:
From: Stephen Dubovsky smdubov...@gmail.com
Subject: Re: [Emc-users] Trajectory planning and other topics from a
EMC(LinuxCNC) newbie (TheNewbie
...@internode.on.net
Subject: Re: [Emc-users] Trajectory planning and other topics from a
EMC(LinuxCNC) newbie (TheNewbie)
To: emc-users@lists.sourceforge.net
Date: Friday, April 20, 2012, 1:52 AM
On 20.04.12 09:53, Viesturs Lācis
wrote:
I was thinking about Kenneth's idea:
2012/4/19 Kenneth Lerman
that makes the problem four dimensional: for each considered point, there is
also an axis of relevance to the consideration.
--- On Fri, 4/20/12, andy pugh bodge...@gmail.com wrote:
From: andy pugh bodge...@gmail.com
Subject: Re: [Emc-users] Trajectory planning and other topics from a
EMC
2012/4/20 Erik Christiansen dva...@internode.on.net:
Curve fitting to an arbitrary bunch of points is an approximate art,
AIUI, with tolerance calculation at all points probably taking a bit of
time. Admittedly, I don't know whether nurbs make that faster/slower or
easier/harder to achieve
let me point out that the underlying issue is the current line-by-line G-code
interpretation model (aka 'limited lookahead')
any view or optimization beyond that scope necessarily involves some path
history which has been addressed by introducing 'queues' at considerable extra
complexity; for
wikipedia puts a somewhat different spin on nurbs. see the use section of
the article, first paragraph.
--- On Fri, 4/20/12, Viesturs Lācis viesturs.la...@gmail.com wrote:
From: Viesturs Lācis viesturs.la...@gmail.com
Subject: Re: [Emc-users] Trajectory planning and other topics from
On 20 April 2012 11:51, Michael Haberler mai...@mah.priv.at wrote:
'queue' is a bit of a misnomer - these are basically ad-hoc polylines
extending beyond a single gcode line to retain history,
It seems I might have been misunderstanding how LinuxCNC works. I
thought that the G-code was
2012/4/20 Michael Haberler mai...@mah.priv.at:
to stay within that model, for instance the polyline-to-NURBS conversion
would require yet another ad-hoce path 'queue'. The other option is to go the
preprocessor route as Ken proposed.
some problems cannot be addressed with a deeper
Am 20.04.2012 um 13:40 schrieb Viesturs Lācis:
Michael, all the things You listed to be changed makes me think that
filter is much easier to do (except the math part).
For a single purpose-tool: probably yes, but then this fixes exactly your
current problem and nothing else.
I hinted at a
somewhere beyond three orthogonal
screws?
--- On Fri, 4/20/12, Viesturs Lācis viesturs.la...@gmail.com wrote:
From: Viesturs Lācis viesturs.la...@gmail.com
Subject: Re: [Emc-users] Trajectory planning and other topics from a
EMC(LinuxCNC) newbie (TheNewbie)
To: Enhanced Machine Controller (EMC
2012/4/20 charles green xxzzb...@yahoo.com:
i dont have a good idea of what a nurbs nc file might be like,
http://wiki.linuxcnc.org/cgi-bin/wiki.pl?NURBS
See the pdf (there is a link at the bottom) for the velocity
difference, when the same toolpath is machined either by small G1
moves or by
...@gmail.com wrote:
From: Viesturs Lācis viesturs.la...@gmail.com
Subject: Re: [Emc-users] Trajectory planning and other topics from a
EMC(LinuxCNC) newbie (TheNewbie)
To: Enhanced Machine Controller (EMC) emc-users@lists.sourceforge.net
Date: Friday, April 20, 2012, 4:40 AM
2012/4/20
On 4/20/2012 4:52 AM, Erik Christiansen wrote:
On 20.04.12 09:53, Viesturs Lācis wrote:
I was thinking about Kenneth's idea:
2012/4/19 Kenneth Lermankenneth.ler...@se-ltd.com:
Is anyone here interested in writing a filter that takes as input a
tolerance (error band) and a sequence of motions
Subject: Re: [Emc-users] Trajectory planning and other topics from a
EMC(LinuxCNC) newbie (TheNewbie)
To: Enhanced Machine Controller (EMC) emc-users@lists.sourceforge.net
Date: Friday, April 20, 2012, 5:25 AM
Am 20.04.2012 um 13:40 schrieb Viesturs Lācis:
Michael, all the things You listed
Subject: Re: [Emc-users] Trajectory planning and other topics from a
EMC(LinuxCNC) newbie (TheNewbie)
To: Enhanced Machine Controller (EMC) emc-users@lists.sourceforge.net
Date: Friday, April 20, 2012, 4:07 AM
On 20 April 2012 11:51, Michael
Haberler mai...@mah.priv.at
wrote:
'queue
#3 - facebook style like
--- On Fri, 4/20/12, Kenneth Lerman kenneth.ler...@se-ltd.com wrote:
From: Kenneth Lerman kenneth.ler...@se-ltd.com
Subject: Re: [Emc-users] Trajectory planning and other topics from a
EMC(LinuxCNC) newbie (TheNewbie)
To: emc-users@lists.sourceforge.net
Date
2012/4/20 Kenneth Lerman kenneth.ler...@se-ltd.com:
Let's consider the alternatives:
1 -- Change the CAM system so that it generates better code. Since there
are multiple CAM systems over which we have little control, this us not
feasible.
Yupp, unless somebody has might and resources to
aye, lad. read on a couple more lines.
--- On Fri, 4/20/12, Stuart Stevenson stus...@gmail.com wrote:
From: Stuart Stevenson stus...@gmail.com
Subject: Re: [Emc-users] Trajectory planning and other topics from a
EMC(LinuxCNC) newbie (TheNewbie)
To: Enhanced Machine Controller (EMC) emc
/20/12, Stuart Stevenson stus...@gmail.com wrote:
From: Stuart Stevenson stus...@gmail.com
Subject: Re: [Emc-users] Trajectory planning and other topics from a
EMC(LinuxCNC) newbie (TheNewbie)
To: Enhanced Machine Controller (EMC) emc-users@lists.sourceforge.net
Date: Friday, April 20
:
From: Viesturs Lācis viesturs.la...@gmail.com
Subject: Re: [Emc-users] Trajectory planning and
other topics from a
EMC(LinuxCNC) newbie (TheNewbie)
To: Enhanced Machine Controller (EMC)
emc-users@lists.sourceforge.net
Date: Friday, April 20, 2012, 4:40 AM
2012/4/20
No, I was actually working with an OEM who sold a sign software package
that generated Gcode (very expensive). The problem was that their
software generated way too many short segments for no good reason which
caused problems on the machine controls (it wasn't LinuxCNC or Mach3). They
On 20 April 2012 14:57, Stuart Stevenson stus...@gmail.com wrote:
Why cannot the control handle the code without the need to filter the short
lines into a more usable form?
Because _those_ straight lines are a list of moment-by-moment axis
positions, incorporating acceleration and velocity
S/buy/but
On Apr 20, 2012 10:18 AM, Stuart Stevenson stus...@gmail.com wrote:
I was making a comparison between the short lines generated by G02/G03
being processed rapidly and a program generating the exact same geometry
buy with short linear moves. Cam packages can output the code either
I was making a comparison between the short lines generated by G02/G03
being processed rapidly and a program generating the exact same geometry
buy with short linear moves. Cam packages can output the code either way.
On Apr 20, 2012 10:08 AM, andy pugh bodge...@gmail.com wrote:
On 20 April 2012
On Fri, Apr 20, 2012 at 9:55 AM, Stuart Stevenson stus...@gmail.com wrote:
Well, then, if G02/G03 and NURBS use an approximation based on a set of
many short straight lines - why is this not implemented in a control to
handle the gcode file as is?
Doesn't this conflict with the often
2012/4/20 Stuart Stevenson stus...@gmail.com:
I was making a comparison between the short lines generated by G02/G03
being processed rapidly and a program generating the exact same geometry
buy with short linear moves. Cam packages can output the code either way.
Yes, but the difference is
++On Fri, 20 Apr 2012 09:53:05 +0300
Viesturs Lācis viesturs.la...@gmail.com wrote:
2012/4/20 Scott Hasse scott.ha...@gmail.com:
It seems to me that the likelihood of fixing all of the methods of
gcode generation such that they don't generate short line segments
is approximately zero.
2012/4/20 dave dengv...@charter.net:
c. add a polynomial of nth-order.
How would You tell the trajectory planner, which exactly section of
the plynomial's graph to use between 2 given points?
Viesturs
--
For
Unfortunately, this approach doesn't work well for things like plastic
extrusion where it can be difficult to control the extrusion rate precisely.
Repraps, etc are able to succeed in part because they take a very naive
approach to trajectory planning and can get away with it because of the
Viesturs Lācis wrote:
Is there a way to create a filter that would convert those small, tiny
G1s into a 3D Nurbs lines?
snip
The only thing I do not get, is how to do the reverse math - describe
a line, if (a lot of) points on it are provided. It does not seem to
be problem finding formulas
andy pugh wrote:
As I said earlier, I don't think this is a Lookahead problem, it is
a must be able to stop inside the next code block problem.
And I am not convinced that being able to stop the machine within the
next code block is necessarily a sensible requirement.
Exactly! It is a
When we first used our Haas machines we discovered they would cut a program
of short linear moves very rapidly. A long shallow arc (imagine an 80 inch
arc length of a 300 inch radius) roughed to leave .150 to finish was
undercut past the finished dimension. We quickly learned to handle the
Erik Christiansen wrote:
Curve fitting to an arbitrary bunch of points is an approximate art,
AIUI, with tolerance calculation at all points probably taking a bit of
time. Admittedly, I don't know whether nurbs make that faster/slower or
easier/harder to achieve algorithmically. But it does
Stuart Stevenson wrote:
Doesn't even G02/G03 result in a series of very small linear moves sent to
the servo motors? Wouldn't a NURB conversion do the same thing
Yes, in a way. But, the G02/G03 is known to be a single move, so there
is no velocity
change until the end of that move. NURBS
Viesturs Lācis wrote:
I also agree that separate filter would be better. Because the problem
is solely in the g-code, so the filter to sort out the code is needed.
With proper code the existing LinuxCNC can completely handle the job.
Not completely. Some very correct G-code cannot be fixed
Would a read ahead of 1000 lines be more time consuming than the NURB
calculation? My post has the ability to restrict output if a move is less
than a certain distance. A .001 minimum and a 1000 block look ahead would
yield a 1 inch minimum distance to slow down as necessary.
On Apr 20, 2012 12:28
Jon
On Fri, Apr 20, 2012 at 12:33 PM, Jon Elson el...@pico-systems.com wrote:
Viesturs Lācis wrote:
I also agree that separate filter would be better. Because the problem
is solely in the g-code, so the filter to sort out the code is needed.
With proper code the existing LinuxCNC can
Here is something that just popped into my head. Could we:
1. Tag each segment with the maximum velocity at the end of the
segment. The current scheme always sets it to zero. For the first
segment, this will still be zero. For subsequent segments it will be
the maximum velocity at
On Fri, 20 Apr 2012 12:12:54 -0500
Jon Elson el...@pico-systems.com wrote:
Erik Christiansen wrote:
Curve fitting to an arbitrary bunch of points is an approximate art,
( no pun intended, of course! )
AIUI, with tolerance calculation at all points probably taking a
bit of time. Admittedly,
Thomas Powderly wrote:
here's how one group worked with the fast turn around at edge of work
the machine tool was like the emc2-bipod and the software built
huge arcs into the endmotions to keep velocity up and dampen the bipod swing
Certainly fixing this in the CAM is the best approach,
Kenneth Lerman wrote:
It seems too simple. What am I missing?
It needs to look ahead an arbitrary number of blocks to see if a big
slowdown
is required some time ahead. When this stuff is interpreted, and that big
slowdown is spotted, you have to go backwards through the blocks
some amount
On 19 March 2012 02:17, Steve Blackmore st...@pilotltd.net wrote:
Effectively LinuxCNC only looks ahead one line.
This rather depends on what you mean by Look Ahead.
One decision that I think might adversely affect LinuxCNC is that as
far as I know LinuxCNC will always move in such a way as to
I don't think that would work well. Think about the situation where you
have several (mostly straight) short line segments, the last being the
shortest, and then a 90deg turn. I think many would find it unacceptable
to overshoot the last segment 10thou if you were doing something like
inside
On 19 April 2012 14:04, Stephen Dubovsky smdubov...@gmail.com wrote:
But I see how it might be a limiting factor for a modern Hass class speed
machine w/ massive spindle hp and feed rates possible when profiling.
It shouldn't be a limit on any machine with decent G-code. I am
describing a
2012/4/19 andy pugh bodge...@gmail.com:
On 19 April 2012 14:04, Stephen Dubovsky smdubov...@gmail.com wrote:
But I see how it might be a limiting factor for a modern Hass class speed
machine w/ massive spindle hp and feed rates possible when profiling.
It shouldn't be a limit on any machine
On 19 April 2012 16:13, Stephen Dubovsky smdubov...@gmail.com wrote:
For 3d profiling CAM usually writes the g-code. I don't know anyone who
would hand calculate tens of thousands of little segments:) As such, I
don't know that its necessarily poor quality. It has to generate as many
Well, generating an arc as tiny G1 moves seems a poorer solution than
G2 or G3 moves...
There are a number of reasons for doing this:
Many CAM packages don't use arcs internally. Breaking arcs into line
segments can greatly simplify the maths.
When doing 3D work you can quite often get arcs
2012/4/19 Stephen Dubovsky smdubov...@gmail.com:
Around tight curves, that requires lots of short sections w/
high changes in velocity. But you have to go slow within the limits of the
machine around those anyway.
Just like Andy said - if there is curve in the part, then that is why
there
I think this is a fairly common problem. There are a number Gcode
generators out there that take curvy cutting patterns and turn
them into huge files full of short G1 moves. The Gcode generator people
expect the machine controller to gobble up the crappy G code and create
smooth motions at
-Original Message-
From: Viesturs Lacis [mailto:viesturs.la...@gmail.com]
Sent: Thursday, April 19, 2012 11:08 AM
To: Enhanced Machine Controller (EMC)
Subject: Re: [Emc-users] Trajectory planning and other topics
from a EMC(LinuxCNC) newbie (TheNewbie)
snip
Just like Andy
The big problem is that very often the curves in the drawing are not
true arcs. This is especially common in artistic and sign work. The
quality of the CAM output is directly dependent on the quality of the
input drawing. Drawings that contains just arcs and lines will generate
nice clean
On 19 April 2012 18:44, Steve Stallings steve...@newsguy.com wrote:
There are many cases where short segments are currently the
only workable solution. Among these:
...
2) The path is curved, but not a true arc. It could be
an oval, an ellipse, or even a spline or nurbs path.
I _think_
2012/4/19 Les Newell les.new...@fastmail.co.uk:
The big problem is that very often the curves in the drawing are not
true arcs. This is especially common in artistic and sign work. The
quality of the CAM output is directly dependent on the quality of the
input drawing. Drawings that contains
Viesturs Lācis wrote:
I think that this issue is fighting the consequence instead of fixing
the real cause.
People want to change the look ahead behavior, but I am completely
sure that fixing the cause - getting normal g-code is much easier. At
least for those things that my machines are
I agree that there are always cases where curve fitting simply doesn't
work. But I have seen some large curvy lines in a single plane that
could have been curve fitted, that spanned over several feet of distance
that were described as G1 segments that were no more than .005 inches long.
That
On 4/19/2012 1:53 PM, Jon Elson wrote:
Viesturs Lācis wrote:
2012/4/19 Stephen Dubovskysmdubov...@gmail.com:
Around tight curves, that requires lots of short sections w/
high changes in velocity. But you have to go slow within the limits of the
machine around those anyway.
Just like
SheetCam does not support NURBS curves internally. When it imports a
drawing, all non-circular curves are broken down into lots of very small
line segments. It then does arc matching on those line segments and any
other line segments in the drawing before finally merging any
ludicrously short
On 4/19/2012 9:02 PM, Kenneth Lerman wrote:
Is anyone here interested in writing a filter that takes as input a
tolerance (error band) and a sequence of motions (arcs and line
segments) and generates a new sequence of motions that duplicates the
original within the error band? It sounds like
2012/4/19 Les Newell les.new...@fastmail.co.uk:
SheetCam does not support NURBS curves internally. When it imports a
drawing, all non-circular curves are broken down into lots of very small
line segments. It then does arc matching on those line segments and any
other line segments in the
1 - 100 of 120 matches
Mail list logo
