Exceeding JOINT_N.MAX_VELOCITY limits with genserkins kinematics

Yeah that is a bit complicated for some use cases, but in robots one axis is one joint, and in world mode the Axis setting appear to be used as they should, so setting them to the same value would also limit them in world mode.
To tired, can not think properly, later.

Thanks for your fast anwser.

I followed your suggestion from your previous post: all joints and all axis set on 10mm/s max velocity. But the result is the same: The TCP-Velocity is limited to the values from the axis-sections, and the limits of the max_velocities of the joints seem not to be considered...

I don't want to keep you from your rest, maybe you can share a document or link, that explains this context in particular for linuxcnc because I thought (till now) I'm sort of familiar with this axis/joint topic since I implemented the transformations for several kinematics in matlab that implicate this joint/axis item

Cheers and have a good rest

It's me again

one additional note: according to the linuxcnc 2.8.1 documentation the demand on "axis value must be the same as joint value" is only necessary for idendity-kinematics like "trivkins"...

I am confused

Cheers, Do

Do the individual joints violate their limits?

Think about this. If you are moving the X & Y axis to traverse at 45 degrees, and both axes are travelling at their max velocity, the actual velocity of the milling cutter will be higher.

Hi Rod,

yes, the individual Joints violate their limits, even if I am only moving along one axis. Of course, the axis is then exactly on its limit and the cutter driving with max_velocity of this axis, but the joints are way over their limits...

Unfortunately I don't think that joint limits are honoured in non-trivial kinematics in World mode.
This is a long-standing issue. The (unsatisfactory) workaround is to set the Axis limits artificially low, ie for worst-case geometry.

I think that the problem is that the trajectory planner, where the limit checking takes place, happens in cartesian space.

It's actually a harder problem than it might appear, as the same G-code could be running anywhere in the machine envelope so there isn't a simple mapping.

I have contemplated schemes where the kinematics is called twice at small distances along the path to get a finite differential to calculate speed from (or 3 times to get acceleration too)

There is probably scope for a clunky fix in HAL. A component could monitor joint velocity in real-time and adjust the adaptive feed pin to slow the whole motion.