Am 09.10.2013 um 14:32 schrieb sam sokolik :
> Sorry I missed this email. I am probably not the one to ask this -
> maybe one of the developers can say. ja3 I think is being worked on
> right now to be put into master but is going to take time. Maybe master?
I guess it's not that much missi
Sorry I missed this email. I am probably not the one to ask this -
maybe one of the developers can say. ja3 I think is being worked on
right now to be put into master but is going to take time. Maybe master?
sam
On 10/3/2013 10:59 AM, Robert Ellenberg wrote:
> Hi Sam,
> What's the status of
Hi Sam,
What's the status of the ja3 branch? I'd like to start from a stable branch
to make debugging easier. If ja3 is under active development, I'd need to
discuss the plans with the developers.
Thanks,
Rob
On Sep 29, 2013 9:58 AM, "sam sokolik" wrote:
> very neat - (I can't be much help ither
Hi Anders,
Thanks for your feedback! I'll try to address your comments here:
*NURBS Planner:* I took a quick look at their code. It looks like have have
both a NURBS implementation and a limited-jerk planner. I just sent them an
email to see what their status is. Maybe they can give this effort
> Date: Sun, 29 Sep 2013 08:57:03 -0500
> From: sa...@empirescreen.com
> To: emc-developers@lists.sourceforge.net
> Subject: Re: [Emc-developers] Proposing a Lookahead implementation for the
> EMC2 module
>
> very neat - (I can't be much help ither than testing)
>
very neat - (I can't be much help ither than testing)
I think though that if you do any developing - it should be in the JA3
branch.
Also - the worry with larger look ahead - things like feedrate over or
feed hold still need to be instantanious.
(I also think this is a high priority)
Thanks f
On Sat, Sep 28, 2013 at 10:31 PM, Robert Ellenberg wrote:
> 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
> k
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
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
> 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
21 matches
Mail list logo
