Home
Reading
Searching
Subscribe
Sponsors
Statistics
Posting
Contact
Spam
Lists
Links
About
Hosting
Filtering
Features Download
Marketing
Archives
FAQ
Blog
 
Gmane
From: Chris Radek <chris-Q5EQ/OVxsytBDgjK7y7TUQ <at> public.gmane.org>
Subject: Re: Compare of motion blending for master(T-Curve) and ja3(S-Curve)
Newsgroups: gmane.linux.distributions.emc.devel
Date: Saturday 28th April 2012 17:56:41 UTC (over 6 years ago)
On Sat, Apr 28, 2012 at 11:18:34PM +0800, Yishin Li wrote:
> Compare of motion blending for master(T-Curve) and ja3(S-Curve):
> 
> http://en.araisrobo.com/linuxcnc/g64-max-blending

Yishin,

Thanks for posting these results.

Have you had any luck tracking down the bug with end position?  When
I saw this caused a jerk constraint violation and sometimes an
acceleration constraint violation on each move (depending on
settings and the move length) I stopped testing and did not study
any of the behavior in more complex situations.

I have some ideas for further tests we should perform after the single
move case is working properly:

The most general move has stages

 +j +a -j c -j -a +j

(j = jerk, a = accel, c = cruise)

I think your code calls these states 0..6 respectively

Some moves, depending on constraint settings and move lengths, will
be 

 +j +a -j -a +j (no cruise)

I don't know if your code will consider this 0 1 2 5 6 or 0 1 4 5 6
or maybe it will be 0 1 2 4 5 6 with the 2->4 transition not
changing the jerk when crossing zero accel.

Some will be

 +j -j c -j +j (no constant accel)

and some will be

 +j -j +j

I think each of these cases probably needs to be studied and verified
for the single move case.

After those are working, we need to add in the complication that the
requested feed can change during any part of the move.  This may
cause a jump to other states, possibly earlier ones and possibly
cause skipping of states.  So you might have a move

 +j +a -j c (feed increases) +j +a -j c -j -a +j

or as you can see there are many other possibilities.  I think a feed
increase and decrease at each state should be tested.  In your
existing code I see a little bit of support for state jumping but I
suspect most of these cases are not yet handled.  (I have not tested
them.)

Once these cases are handled then blending can be examined and we
will be finally ready for testing for constraint violations during
complex runs like tort.ngc.

We also need to verify the behaviors for waiting for spindle-at-speed,
waiting for index, and spindle-synch motion.

It is OK for the planner to have better blending behavior in the cases
where all axes have the same constraint settings, but it also must
work acceptably in the cases where this is not true.

Thanks again for your work and I will continue to do what I can to
help you test and validate your planner as your work continues.

Chris

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
 
CD: 27ms