I see, so may this be a bug rather than a config error? Back to Andy's post, yes all the conditions are true. Also if you were to build a Joints_Axes branch wouldn't you use gentrivkins rather than gantrykins?
For anyone interested in trying a recent joints_axes9 branch,
the attached tar file (g.tgz) has a simplified sim config with:
X --> Joint0
Y --> Joint1 AND Joint2
Z --> Joint3
W --> Joint4
Important notes:
Code:
[TRAJ]
COORDINATES = XYZW
# The [TRAJ]COORDINATES item names the letters for gcode
# XYYZW or YYXZW or WXYYYYYYYYYYYZW work the same
[KINS]
JOINTS = 5
KINEMATICS = gentrivkins coordinates=xyyzw kinstype=BOTH
AUTO_TELEOP=20
# The coordinates=xyyzw for gentrivkins assigns to joints
# in sequence: 0,1,2,3,4
# so here the order and axis names are important
The AUTO_TELEOP option causes a switch to teleop (world)
after homing (wait 20 seconds at most)
In the axis gui, the '$' character toggles joint and teleop modes
Thanks for that, I'll have a go with JA9 tomorrow and report back. I think a working gentrivkins is preferable to gantrykins, ignoring soft limits scares the hell out of me!
In joints_axes9, gentrivkins has a (new) module parameter
kinstype for testing. It makes it possible to test a simple
kinematics module as if it were a more complex
(non-identiry) kinematics type.
I used it in the example to illustrate switching between
joint and teleop mode so that you can see the pos-cmds for
both modes in the included halshow gui.
Some guis (axis for example) suppress joint/world switching
for identity kins. In the g.tgz example, remove the text
'kinstype=BOTH' to see the gui behavior for kinematics that
are strictly identity.
