On 09/28/2013 09:09 PM, Robert Ellenberg wrote:
> Thanks for the explanation! if we're lucky, such a feature wouldn't take a
> separate optimization, since the forward and reverse trajectories have the
> same speed and acceleration bounds. Once lookahead is implemented, It
> sounds like a good feat
www.sites.mech.ubc.ca/~caris/Publications/sonja.pdf
--
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and mo
Chris Morley wrote:
> In a normal configuration the trajectory calculations are done at the servo
> thread
> speed, but this can actually be set to something else, previously it was
> often set
> to run ten times faster then the servo thread but that was found unnecessary.
>
>
No, I believe t
Thanks for the explanation! if we're lucky, such a feature wouldn't take a
separate optimization, since the forward and reverse trajectories have the
same speed and acceleration bounds. Once lookahead is implemented, It
sounds like a good feature to attack.
-Rob
On Sat, Sep 28, 2013 at 9:24 PM,
On 09/28/2013 07:33 PM, Robert Ellenberg wrote:
> That sounds like a good simplification. I like the idea of limiting the
> horizon to the stopping distance, though unfortunately it's not a
> straightforward calculation as of now. The big complication is that the
> blends are constant speed, so onl
On 29 September 2013 01:33, Robert Ellenberg wrote:
> For reversing a given motion, how far back would you need to go? A few
> segments or the whole path?
I am not sure. I have never needed it. I think some controls allow you
to run the whole program backwards under jog-wheel control, but I
don'
That sounds like a good simplification. I like the idea of limiting the
horizon to the stopping distance, though unfortunately it's not a
straightforward calculation as of now. The big complication is that the
blends are constant speed, so only a portion of each move can have
acceleration / deceler
Based on what I saw in tp.c, the current method looks like trapezoidal
motion with linear velocity blends (parabolic in position). Using splines
is one angle I looked into, though there are significant mathematical
hurdles. For example, it's not generally possible to parameterize a spline
by arc le
On 29 September 2013 01:07, Chris Radek wrote:
> Robert, thanks for your interest; I am working on digesting your
> paper.
The idea of basically building the current trajectory then iteratively
improving it seems interesting.
It may be worth considering working only on a "patch" of moves that
en
On Sat, Sep 28, 2013 at 06:20:41PM -0400, Robert Ellenberg wrote:
> Thanks for the link to the documentation! I do plan to code this myself,
> though I would welcome any input from other developers. I'm sure many
> people have thought about this issue in the past and would have valuable
> input, es
Robert,
I thought LCNC already used s-curves for acceleration. If not, try a
simple Bezier spline (unless someone has either a better spline for
motion or a reason why Bezier's are bad. I would prefer they all be
NURBS, but THAT would be a lot of work).
On Sep 28 2013 5:00 PM, Robert Ellenbe
Hi Andy,
I agree, a finite jerk profile would be a nice feature. That would be a
good 2nd pass to take after lookahead is working. At that point, the
machine will be able to pass quickly through small segments, which means
hitting a lot of blends in a short time. Right now, the blends are not
a
On 28 September 2013 23:20, Robert Ellenberg wrote:
> Thanks for the link to the documentation! I do plan to code this myself,
> though I would welcome any input from other developers.
I don't think many of us really understand that part of the code. But
I think you can rely on our goodwill.
Not
Thanks for the link to the documentation! I do plan to code this myself,
though I would welcome any input from other developers. I'm sure many
people have thought about this issue in the past and would have valuable
input, especially on the implementation side.
Also, apologies in advance if this e
Before this change, Interp::_setup would be destroyed after the program exited,
which is generally after Py_Finalize is called. But the (synthesized)
destructor of Interp::setup would call the destructor of a boost::python::
object pythis, leading to Python API calls including to subtype_dealloc,
> From: rwe...@gmail.com
> Date: Sat, 28 Sep 2013 15:31:41 -0400
> To: emc-developers@lists.sourceforge.net
> Subject: [Emc-developers] Proposing a Lookahead implementation for the EMC2
> module
>
> Hi All,
>I'm a grad student working on trajectory planning for robots. While
> doing some
Hi All,
I'm a grad student working on trajectory planning for robots. While
doing some fine-detail work using LinuxCNC on a mini-mill, I've bumped up
against the feed rate limitations due to small G-Code segments. Since this
kind of thing is my area, I wrote up a proposal to improve speed throug
We just finished our monthly IRC meeting.
Meeting agenda & vote results are included in this email, and on our
wiki here: http://wiki.linuxcnc.org/cgi-bin/wiki.pl?Meeting201309
Meeting log: http://meetlog.archivist.info/meeting.php?id=201309
moderator: Dave Caroline
secretary: Dave Caroline
Age
2013. gada 28. sept. 17:31 "T. Raykoff" rakstīja:
>
> My base assumption is that it works with
> infinite look-ahead
LinuxCNC is looking one single g-code line ahead.
Viesturs
--
October Webinars: Code for Performance
Fr
With the current trajectory planner it is far better to use arcs and
not small line segments.
It is due to the amount of look ahead.
Dave Caroline
On Sat, Sep 28, 2013 at 3:30 PM, T. Raykoff wrote:
> I am putting together some software that will generate toolpaths. It works
> with piecewise lin
i would like to see this done also i brought it up quite afew years back
but had no way of knowing how to fix it etc.
i wanted to bring it in line with how all our other big name contorls do
it.
Rapid should do rapid as you say,
feed is for feed rate %
feed rate can still do what ever you progr
I am putting together some software that will generate toolpaths. It works
with piecewise linear polygons.
1.) When running an arc, is there any pro- or con- to feeding LinuxCNC
either a series of a few dozen straight moves to approximate the arc, or a
single G2/G3 arc? As I mentioned, I am work
22 matches
Mail list logo
