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
general -
feed, movement bounds, spindle speeds, tool numbers, etc.
so commanded feedrates in a file are upper bounds, and within those bounds,
maximum feedrates are always possible.
--- On Fri, 4/20/12, Jon Elson wrote:
> From: Jon Elson
> Subject: Re: [Emc-users] Trajectory planni
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
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
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
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
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 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
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 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 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
>>>
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 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"
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
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
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
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 northerne
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 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 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 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
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 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
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 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
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
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
eff carrot carrot carrot
"mom! jonny went on the internet and typed a BAD word!"
"now jenny.. dont be upset. you know the censors keep the internet perfectly
bland."
--- On Sun, 4/22/12, Steve Blackmore wrote:
> From: Steve Blackmore
> Subject: Re: [Emc-user
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: "
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
"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
101 - 143 of 143 matches
Mail list logo
