> Il giorno lun, 12/12/2011 alle 12.02 +0100, Spiderdab ha scritto: >> Hi, there's one thing isn't clear for me with speed. >> I have an inverted tetrapod. >> I've set [AXIS_n]MAX_VELOCITY to 1000.0 (in my case mm/s) >> when i jog in teleop mode in X or Y or Z axis, i have this speed. >> but when i jog in XY direction jog velocity is the sum-vector between X >> and Y speed, so 1.4* resulting in something like 1400 mm/s. >> if then i jog to XYZ direction (all 3 dir together..) again the >> resulting speed is the sum-vector, so something near 1,8*, and the >> resulting speed is 1800 mm/s. >> Said that, what i see in [TRAJ]MAX_VELOCITY or MAX_LINEAR_VELOCITY >> should set the max speed independently of jog direction, but it doesn't >> change anything. >> As a result, when i jog at max speed to a diagonal direction, i have a >> following error, because jogging speed exceeds what the machine can do. >> What do you think about it? > To be precise, i just discovered that [TRAJ]MAX_LINEAR_VELOCITY works as > a general vel_limit if i write manual MDI command. But doesn't work as a > limiter for manual jogging speed. > I have to solve this, because i think that if you jog in teleop mode you > should have the same speed apart from the direction you're jogging. the > machine shouldn't go faster in diagonal movements!!
Yes, it should (kinda)! Remember we are talking about tooltip velocity here, not the velocity of the individual motors. The problem with the original emc2 code was that there was no difference between motor velocity and axis velocity. [AXIS_n]MAX_VELOCITY - limited both motor and carthesian velocity That is certainly wrong (it is correct only for trivial kinematics where motor 0 = X, motor 1 = Y, etc). In order to fix that we started ja3 a while ago, but it isn't finished. The idea is to have separate [AXIS_n]MAX_VELOCITY - to limit carthesian velocity, e.g. tooltip velocity and [JOINT_n]MAX_VELOCITY - to limit motor velocity. When doing a move (doesn't matter if coordinated, e.g. G1 ..Fxx, or MDI or by jogging) the planner should take all velocities into considerations. The problem with this is the functions are not linear. That means that during the move, one of the joints might need to go faster than it's limit. That need can be for a very small portion of the move, that's why it's hard to implement this. There are basicly 2 approaches: 1. simulate the move (before actually doing it), and look for max vels for each joint. Then scale the move accordingly, so that none of the joint vels is exceeded. 2. start the move with a certain speed, and when approaching a joint vel limit, reduce the speed accordingly. #1 will move the entire path slower #2 will move as fast as possible, and only slow down on trouble locations. That said, afaik, currently none of them are implemented in ja3, and the planner gladly violates joint vel limits if asked to. JA3 is still the place to be for nontrivkins, because those fixes (#1 or #2) are quite possible, opposed to the regular code where it's impossible to implement any of them. Regards, Alex ------------------------------------------------------------------------------ Learn Windows Azure Live! Tuesday, Dec 13, 2011 Microsoft is holding a special Learn Windows Azure training event for developers. It will provide a great way to learn Windows Azure and what it provides. You can attend the event by watching it streamed LIVE online. Learn more at http://p.sf.net/sfu/ms-windowsazure _______________________________________________ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
