Thanks for your responses.
It seems I have to give LinuxCNC a closer look.
There is a low cost commercial alternative in MACH 3.
I guess you have an opinions on that system too?
I know it's based on Windows with some kind of realtime extension who
doesn't sound too good in ears.
My impression is
On Sat, 17 Mar 2012, Roger Holmquist wrote:
> Date: Sat, 17 Mar 2012 17:28:05 +0100
> From: Roger Holmquist
> Reply-To: "Enhanced Machine Controller (EMC)"
>
> To: emc-users@lists.sourceforge.net
> Subject: Re: [Emc-users] Trajectory planning and other topi
On Sat, 2012-03-17 at 17:28 +0100, Roger Holmquist wrote:
> Thanks for your responses.
> It seems I have to give LinuxCNC a closer look.
>
> There is a low cost commercial alternative in MACH 3.
> I guess you have an opinions on that system too?
> I know it's based on Windows with some kind of rea
Roger Holmquist wrote:
> Thanks for your responses.
> It seems I have to give LinuxCNC a closer look.
>
> There is a low cost commercial alternative in MACH 3.
> I guess you have an opinions on that system too?
> I know it's based on Windows with some kind of realtime extension who
> doesn't soun
2012/3/17 Roger Holmquist :
> Thanks for your responses.
> It seems I have to give LinuxCNC a closer look.
>
> There is a low cost commercial alternative in MACH 3.
> I guess you have an opinions on that system too?
That is pretty much provocative question :))
Here is my thoughts, why Mach _is not
On Sat, 17 Mar 2012 17:28:05 +0100, you wrote:
>My assumption about Tarjectory planning was based on Anders Wallins
>message as he mentioned some problem with limited look-ahead,
>I suppose this affects the shape of the calculated path in some cases?
Effectively LinuxCNC only looks ahead one l
This is very interesting, we are planning to.start using linuxcnc some time
in near future. We mainly mill organic shapes, such as 3DProcessing scanned
head models, the models start as mesh stl models with million a of small
triangles we would like to mill at fastest possible speed and can tolerate
On Mon, Mar 19, 2012 at 11:30 AM, Youda He wrote:
> This is very interesting, we are planning to.start using linuxcnc some time
> in near future. We mainly mill organic shapes, such as 3DProcessing scanned
> head models, the models start as mesh stl models with million a of small
> triangles we w
I went though this exercise on a vinyl cutter application doing a lot of
fine cutting details a few years ago. What I found is that if you want
to do a lot of fine work quickly you really need to work on your 3D cam
software to do curve fitting on the output.
The only alternative to that is to
Is the one-line lookahead statement also true blended paths?
And how does it apply to splines?
I find all this quite surprising, even grbl does lookahead over all the
lines in the buffer (and hence has a latency while trying to pause or stop)
Does somebody know if this diagram is whats linuxcnc d
From: Viesturs L?cis Subject: Re: [Emc-users]
> This will run in a little off-topic by me...
> You can run heavy duty machines with steppers, but then the
> performance will suffer - You will have to leave big safety margin in
> terms of load to motors (either move slower or use way much larger
>
2012/3/31 cogoman :
> From: Viesturs L?cis Subject: Re: [Emc-users]
>> This will run in a little off-topic by me...
>> You can run heavy duty machines with steppers, but then the
>> performance will suffer - You will have to leave big safety margin in
>> terms of load to motors (either move slower
On 3/31/2012 12:09 PM, Viesturs Lācis wrote:
> 2012/3/31 cogoman:
>
>> From: Viesturs L?cis Subject: Re: [Emc-users]
>>
>>> This will run in a little off-topic by me...
>>> You can run heavy duty machines with steppers, but then the
>>> performance will suffer - You will have to leave bi
On Sat, 31 Mar 2012, Dave wrote:
> Date: Sat, 31 Mar 2012 14:20:19 -0500
> From: Dave
> Reply-To: "Enhanced Machine Controller (EMC)"
>
> To: "Enhanced Machine Controller (EMC)"
> Subject: Re: [Emc-users] Trajectory planning and other topics from a,
)"
>> Subject: Re: [Emc-users] Trajectory planning and other topics from a,
>> EMC(LinuxCNC) newbie (TheNewbie)
>>
>> My experience with steppers is that once you lose sync with the rotor at
>> speed, you have to slow down tremendously to regain sync with the r
I am a bit behind due to trying to get my EMAIL machine upgraded to a
newer model I received as a hand me down. The on board video stymied
every distribution except puppy! I eventually was given an older PCI-X
video card that allowed me to install main stream distros, and now I've
pretty much
On 19 March 2012 02:17, Steve Blackmore 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 be able to
stop
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 corn
On 19 April 2012 14:04, Stephen Dubovsky 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 problem with poor-quali
2012/4/19 andy pugh :
> On 19 April 2012 14:04, Stephen Dubovsky 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
> desc
Im aware the 90deg case is currently covered. I was commenting to the OP
who thought about allowing the trajectory planner to run a little faster
than it can see could end badly even with such a common case.
For 3d profiling CAM usually writes the g-code. I don't know anyone who
would hand calcu
On 19 April 2012 16:13, Stephen Dubovsky 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
> segments as necessar
> 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 :
>
> 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 are G2 and G3 comma
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 hig
> -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)
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 code.
On 19 April 2012 18:44, Steve Stallings 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_ there is a 3D NURBS
2012/4/19 Les Newell :
> 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 wil
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 ar
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,
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
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
--
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
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
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.
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
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
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
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
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
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
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
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)"
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
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.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 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
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
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:
> >
>
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 (
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
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
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
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
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
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 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
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
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)&
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
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
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
#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,
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
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:
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,
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
> 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 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
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
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
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
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, 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 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, 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
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
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
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
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
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 doe
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
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 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
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
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
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
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
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
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
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
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 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
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 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
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
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
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
1 - 100 of 130 matches
Mail list logo
