"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
Excl
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
Excl
exaggerated mechanism contraption 3? i am stoked for more lowgrade cable movie
series.
--- On Sun, 4/22/12, Steve Blackmore wrote:
> From: Steve Blackmore
> Subject: Re: [Emc-users] Trajectory planning and other topics from a
> EMC(LinuxCNC) newbie (TheNewbie)
> To: "
s] Trajectory planning and other topics from a
> EMC(LinuxCNC) newbie (TheNewbie)
> To: "EMC2-Users-List"
> 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 discours
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
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
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 li
On 24 April 2012 11:30, Les Newell wrote:
> An easily customizable GUI would be nice.
Have a look at gscreen, which is a UI written by Chris Morley entirely in Glade
http://www.linuxcnc.org/index.php/english/component/kunena/?func=view&catid=41&id=17806&limit=6&start=24#17895
I haven't tried it
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?
On 24 April 2012 03:19, Chris Morley 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 used
> as is. I'm sure so
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 e
On Mon, 23 Apr 2012 17:01:30 +0100, you wrote:
>On 23 April 2012 01:31, Steve Blackmore 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 "joint
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.
>
>
On 23 April 2012 01:31, Steve Blackmore 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
software where ther
On Mon, 23 Apr 2012 09:05:17 +0300, you wrote:
>2012/4/23 Steve Blackmore :
>>
>> 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 cl
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 northerne
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
2012/4/23 Steve Blackmore :
>
> 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.
Steve, no offen
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
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 upcom
On 4/22/2012 3:48 PM, andy pugh wrote:
> On 22 April 2012 16:07, 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.
> I think CRC is "Cutter Radius Compensation"
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 answ
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 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
>>>
On Sun, 22 Apr 2012 20:48:56 +0100, you wrote:
>On 22 April 2012 16:07, 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.
>
>I think CRC is "Cutter Radius Compe
On 22 April 2012 16:07, 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.
I think CRC is "Cutter Radius Compensation" and NCD os "Naive CAM detection"?
I suspect t
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 a
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 discussed
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 o
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
routine mode wouldnt have the texture advantage of nice
feedrate smoothness.
--- On Sat, 4/21/12, Viesturs Lācis wrote:
> From: Viesturs Lācis
> Subject: Re: [Emc-users] Trajectory planning and other topics from a
> EMC(LinuxCNC) newbie (TheNewbie)
> To: "Enhanced Machin
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
implemen
2012/4/21 Jon Elson :
>
> 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 big issue for solv
Viesturs Lācis wrote:
> 2012/4/21 Jon Elson :
>
>> 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 lo
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 velocit
ng and other topics from a
> EMC(LinuxCNC) newbie (TheNewbie)
> To: "Enhanced Machine Controller (EMC)"
> Date: Friday, April 20, 2012, 9:54 AM
> andy pugh wrote:
> > As I said earlier, I don't think this is a "Lookahead"
> problem, it is
> > a &
On Fri, 20 Apr 2012 09:47:44 +0100, you wrote:
>On 20 April 2012 06:42, Scott Hasse 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
eping within machinetool's
acceleration limits.
--- On Fri, 4/20/12, Jon Elson wrote:
> From: Jon Elson
> Subject: Re: [Emc-users] Trajectory planning and other topics from a
> EMC(LinuxCNC) newbie (TheNewbie)
> To: "Enhanced Machine Controller (EMC)"
> Date: Frida
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 pla
2012/4/21 Jon Elson :
> 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 block would
> p
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
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 approac
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 block would
probably
suffice in most machines
On Fri, 20 Apr 2012 12:12:54 -0500
Jon Elson 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, I don't know wh
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 the
Jon
On Fri, Apr 20, 2012 at 12:33 PM, Jon Elson 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 completely handle the jo
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
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 fix
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 doe
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
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
limitati
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
Viesturs Lācis wrote:
> Is there a way to create a filter that would convert those small, tiny
> G1s into a 3D Nurbs lines?
>
> 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
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 low
On Fri, Apr 20, 2012 at 11:34 AM, dave wrote:
>
> Unfortunately, I can conceptualize things that I don't have the brain
> power to program. Darned!
>
> You probably do have the brainpower to program, but you do have to
remember a lot of things at once. I can't remember where I put my keys,
not s
2012/4/20 dave :
>
> 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 Developers, A Lot Can Happ
++On Fri, 20 Apr 2012 09:53:05 +0300
Viesturs Lācis wrote:
> 2012/4/20 Scott Hasse :
> > 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
2012/4/20 Stuart Stevenson :
> 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 that motion contro
On Fri, Apr 20, 2012 at 9:55 AM, Stuart Stevenson 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 expressed desire to st
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" wrote:
> On 20 April 2012 14:57, Stuart S
S/buy/but
On Apr 20, 2012 10:18 AM, "Stuart Stevenson" 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 way.
> On Apr 20
On 20 April 2012 14:57, Stuart Stevenson 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 limits and tool
offs
> 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
o making each physical
>> > machine axis into a
>> > > couple of circular movements, one going along R from 0
>> > to 360 degrees while
>> > > the other rotates around 2R to make the motion
>> > linear? ..a rotary
>> > > differential movemen
n Fri, 4/20/12, Stuart Stevenson wrote:
>
> > From: Stuart Stevenson
> > Subject: Re: [Emc-users] Trajectory planning and other topics from a
> EMC(LinuxCNC) newbie (TheNewbie)
> > To: "Enhanced Machine Controller (EMC)" >
> > Date: Friday, April 20,
aye, lad. read on a couple more lines.
--- On Fri, 4/20/12, Stuart Stevenson wrote:
> From: Stuart Stevenson
> Subject: Re: [Emc-users] Trajectory planning and other topics from a
> EMC(LinuxCNC) newbie (TheNewbie)
> To: "Enhanced Machine Controller (EMC)"
> Date:
2012/4/20 Kenneth Lerman :
>
> 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 develop one...
> 2 -- M
#3 <- facebook style "like"
--- On Fri, 4/20/12, Kenneth Lerman wrote:
> From: Kenneth Lerman
> 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,
bject: Re: [Emc-users] Trajectory planning and other topics from a
> EMC(LinuxCNC) newbie (TheNewbie)
> To: "Enhanced Machine Controller (EMC)"
> Date: Friday, April 20, 2012, 4:07 AM
> On 20 April 2012 11:51, Michael
> Haberler
> wrote:
> > 'queue' is a bit
ectory planning and other topics from a
> EMC(LinuxCNC) newbie (TheNewbie)
> To: "Enhanced Machine Controller (EMC)"
> 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 to be changed
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 Lerman:
>>> Is anyone here interested in writing a filter that takes as input a
>>> tolerance (error band) and a sequence of motions (arcs and li
re beyond three orthogonal screws?
>
>
> --- On Fri, 4/20/12, Viesturs Lācis wrote:
>
> > From: Viesturs Lācis
> > 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 :
>
> 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 Nurbs splines.
Vi
somewhere beyond three orthogonal
screws?
--- On Fri, 4/20/12, Viesturs Lācis wrote:
> From: Viesturs Lācis
> Subject: Re: [Emc-users] Trajectory planning and other topics from a
> EMC(LinuxCNC) newbie (TheNewbie)
> To: "Enhanced Machine Controller (EMC)"
> Date: Friday
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
2012/4/20 Michael Haberler :
>
> 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 interpretation-time p
On 20 April 2012 11:51, Michael Haberler 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 interpreted into a queu
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 wrote:
> From: Viesturs Lācis
> Subject: Re: [Emc-users] Trajectory planning and other topics from a
> EMC(LinuxCNC) newbie (T
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 i
2012/4/20 Erik Christiansen :
>
> 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
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 wrote:
> From: andy pugh
> Subject: Re: [Emc-users] Trajectory planning and other topics from a
> EMC(LinuxCNC) newbie (
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:
> >
>
if speed is an issue, consider the solution of being a doctor: have patience.
--- On Thu, 4/19/12, Stephen Dubovsky wrote:
> From: Stephen Dubovsky
> Subject: Re: [Emc-users] Trajectory planning and other topics from a
> EMC(LinuxCNC) newbie (TheNewbie)
> To: "Enhanced M
On 20 April 2012 09:52, Erik Christiansen 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 refers to the abil
On 20.04.12 09:53, Viesturs Lācis wrote:
> I was thinking about Kenneth's idea:
>
> 2012/4/19 Kenneth Lerman :
> > 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 m
On 20 April 2012 06:42, Scott Hasse 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 earlier, I don't think t
On 20 April 2012 07:53, Viesturs Lācis 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 described line. But rev
along another (think of moulding trim, or
extrusions)..
--- On Thu, 4/19/12, Viesturs Lācis wrote:
> From: Viesturs Lācis
> Subject: Re: [Emc-users] Trajectory planning and other topics from a
> EMC(LinuxCNC) newbie (TheNewbie)
> To: "Enhanced Machine Controller (EMC)"
2012/4/20 Scott Hasse :
> 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 arcs, splines, etc
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 arcs, splines, etc. that the
likelihood of CAM pac
Kenneth Lerman wrote:
> Others have stated that arcs must be in one of three orthogonal planes.
> Since linuxcnc can do helices, that isn't precisely true.
>
A helix is a special case, where an arc in one of the 3 defined planes
adds a
coordinated linear movement of one axis not involved in th
Viesturs Lācis wrote:
> 2012/4/19 Jon Elson :
>
>> But, LinuxCNC does not do arbitrary arcs, but only arcs in one of the three
>> orthogonal planes.
>>
>
> How hard would it be to add that? It would require 3 coordinates for
> each of start, end and center point.
>
The first problem is t
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 simply
2012/4/19 Les Newell :
> 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 merg
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 lik
Dave,
Is it possible the CAM package had been set up for ridiculously close
tolerances? Maybe it was simply a case of changing a parameter somewhere
to increase the tolerance.
Les
On 19/04/2012 19:01, Dave wrote:
> I agree that there are always cases where curve fitting simply doesn't
> work.
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 l
On 4/19/2012 1:53 PM, Jon Elson wrote:
> Viesturs Lācis wrote:
>> 2012/4/19 Stephen Dubovsky:
>>
>>> 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
2012/4/19 Jon Elson :
>
> But, LinuxCNC does not do arbitrary arcs, but only arcs in one of the three
> orthogonal planes.
How hard would it be to add that? It would require 3 coordinates for
each of start, end and center point.
Viesturs
--
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 is
Viesturs Lācis wrote:
> 2012/4/19 Stephen Dubovsky :
>
>> 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,
1 - 100 of 130 matches
Mail list logo
