Discussion: Control methods for multi-axis devices: T-Code axis control vs high-level motion commands

Hello everyone,

We are currently developing a 3-DOF nipple toy called CDR01, and we would like to ask for the community’s thoughts on control methods for multi-axis devices.

CDR01 currently supports two types of control.

The first one is a custom high-level command system.

Examples:

POINT x y z motion_ms
LINE x y z motion_ms
CIRCLE cx cy cz r motion_ms
REPEAT_LINE x1 y1 z1 x2 y2 z2 move_ms
LISSAJOUS …

With this method, trajectories such as circles, repeated lines, and curves are generated on the device side. This keeps communication bandwidth low and makes predefined motions easy to use. However, if we want a motion that is not already implemented, we need to add a new command.

The second one is T-Code control.

At the moment, the mapping is:

L0 → X
L1 → Z
L2 → Y
V0 → vibration

T-Code is very flexible. If the host software generates the trajectory, almost any motion can be represented. On the other hand, even a simple circular motion requires the host to continuously calculate and send points along the circle, which may require high-frequency communication.

We would like to ask:

  • Has the community already discussed best practices or reached any consensus on control methods for multi-axis devices?
  • Does a hybrid approach make sense, where T-Code is used as the low-level common control layer, while the device also supports high-level motion primitives?

If there are existing discussions, similar device implementations, design pitfalls, or thoughts about future standardization, we would really appreciate your input.

Thank you!

1 Like