Here’s a short followup tview feature in the same vein as the recently announced fault monitoring. For various not-too-important technical reasons, the diagnostic method moteus uses to report faults in servo_stats.fault does not include a text shorthand like most other enumerations do. That means that users are constantly confronted with things like fault=33, or fault=39. Unless they are lucky and know to look in the relevant section of the reference, this doesn’t do a whole lot of good.

When using tview to monitor and control moteus controllers, there have been a fair number of limitations and “gotchas”. One of the biggest for newcomers is the distinction between error checking in the d pos command, and faults that can occur during position mode itself. When using the diagnostic protocol and issuing a command, for those commands which direct moteus to perform some control action, the controller will respond with an “OK” as long as the command itself is syntactically correct. Only then is it submitted to the online control loop, after which faults resulting from the command will manifest as the controller reporting a mode of kFault or 1, with a corresponding fault code. In the diagnostic tree view, those are shown as servo_stats.mode and servo_stats.fault.

So, what many newcomers do is take a moteus board fresh from the factory, which starts with servopos.position_min=-0.01 and servopos.position_max=0.01, and do the following in order:

1. Issue a totally reasonable command like d pos nan 0 nan to command the motor to hold position
2. Observe an OK come back
3. Don’t see the motor do anything

What those users don’t realize is that in order to see why moteus doesn’t move, you need to look at the current reported mode and fault, not at the response over the diagnostic channel.

Here I’d like to describe a solution to this problem that hopefully makes tview much easier in general with fewer instances of confusion resulting.

I’m excited to announce a significant usability improvement for all moteus controllers, command line tools and the python library! If your moteus controllers are on firmware version 2025-09-20 or newer and your moteus client tools are at 0.3.91 or newer, (and if you are using a pi3hat, it is on firmware 2025-09-20 or newer) there are some big improvements that you transparently get:

1. You no longer need to assign unique CAN IDs before daisy chaining controllers
2. The python transport lets client programs transparently operate across multiple CAN-FD interfaces simultaneously
3. tview will automatically open all controllers attached to all CAN-FD interfaces on the computer

Let’s dig into what this looks like from the command line, tview and what the practical constraints are.

As of pypi 0.3.68, tview has gained the ability to delay execution of a compound command until the currently executing trajectory is complete. This can be useful for developing more complex motions that consist of multiple steps.

To use it, just issue a '?[optional_id]' in your command sequence. For instance, to move to position 1 and come to a stop, then move to position 0 when that has completed, you could do: