On Sun, Apr 29, 2012 at 1:56 AM, Chris Radek <ch...@timeguy.com> wrote:
> 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. > In my experience, the "target positioning" is the most complicate part of the whole S-Curve algorithm. It has to meet 4 constrains, thus it's a 3-order-equation: dist_to_go == 0 accel == 0 vel == 0 jerk = constant Currently, I choose to make dist_to_go correct by sacrificing accel. I will working on this issue first. 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. > It is implemented as 0>1>2>3>4>5>6 3: must stay 1 base period for state transitioning. This is one of the error source for target positioning. > > Some will be > > +j -j c -j +j (no constant accel) > > and some will be > > +j -j +j > It has to be 0>2>4>6. We need to separate the state for "-j w/ +a" and "-j w/ -a" for altering feed rate at run time. > > 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.) > It has been take cared. Though, it is not fully verified. Is there a test script to altering feed_override while running program in auto_mode? > 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. > > Totally agree. > 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. > > Thanks for your help. Yishin ------------------------------------------------------------------------------ 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/ _______________________________________________ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
