On Wed, Nov 11, 2009 at 3:59 AM, Alex Joni <[email protected]> wrote:
> Hi,
> you are correct it's not right in this case. (I didn't follow the exact
> calls, but if it's like you did, then you're right).
> It should probably be defined in the ini, at least as sane velocities for
> TRAJ.
>
> I am not sure how to limit the velocities based on joints - that depends on
> kinematics _and_ on the position/move of the joint(s).
> If you have a suggestion how to do this, I'm all ears.
>
>
My draft approach would be:
1. In emccanon.cc, bypass the getStraightAcceleration() function.
2. In emccanon.cc, simplify the calculation of getStraightVelocity(); it
returns either canon.LinearFeedRate or canon.AngularFeedRate.
3. In emc/kinematics/tp.c:tpAddLine(), tpAddCircle(), and
tpAddRigidTap(), calculate linear/helix velocity and acceleration based on
InverseKinematics() and corresponding joint limitations(MAX_VELOCITY, and
MAX_ACCELERATION).
Open issues:
- In "3.", how many samples along the trajectory should be taken for
evaluating corresponding joint velocity and acceleration?
- Would "3." be expensive?
- Any better suggestion for evaluating linear/helix velocity and
acceleration for non-trivial-kinematics?
Thanks,
Yishin
------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
Emc-developers mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/emc-developers
