Welcome to another Tinymovr Update! Work on Tinymovr in the past month focused mainly on fixing various small issues, as well as improving performance and safety!
Sometimes breaking changes may occur in either firmware or client software. This is inevitable in the early stage of product development, but may occur even in the mature development stage. To ensure API compatibility, a mechanism to ensure compatibility between firmware and client side is necessary. Even more so in mission critical systems such as motion control, where API incompatibility may result in undesired behavior, property damage or even injury!
With this in mind Tinymovr is introducing a new system of compatibility “self-verification” for Tinymovr Firmware and Studio, starting from v0.8.7 and v0.3.7, respectively. The system is simple: The firmware holds, together with its own version, a flag that denotes the minimum supported Tinymovr Studio version. This can be obtained through a standard CAN Bus endpoint, and is also user-readable. In parallel, Studio has its own flag that denotes the minimum supported Firmware version. At Studio startup, two comparisons are made: min studio version requirement with actual studio version, and min firmware version requirement with actual firmware version. If one of them fails, Studio exits with an error message.
In this way, it is possible to manage compatibility separately for Firmware and Studio, and always ensure that versions working together are compatible. This also allows for the least number of upgrades to be performed by the user: If a new firmware upgrade is available that does not break API, the user can continue with the same version of Studio if they wish, and vice versa.
The second feature addition allows user-defined rotor zero-point and direction. It is now possible through Tinymovr studio (and CAN Bus API of course) to set a user-defined zero point for the rotor, also known as offset, as well as set the direction of the rotor to be either positive, i.e. electrical phase same as encoder, or negative, i.e. electrical phase opposite to encoder. The settings are persisted in Non-Volatile Memory.
Besides, several minor issues have been addressed, both in firmware as well as studio. Indicatively, writing to NVM has been simplified, better fault handler debugging features have been added, and the CAN Bus module in Tinymovr Studio has seen a cleanup and renaming to better distinguish it from the Python CAN module. All these changes may break some programs using the Tinymovr Python API, but overall disturbances should be minimal.
The latest firmware is available now and goes together with Tinymovr studio, which you can easily install with
pip3 install tinymovr
And since this month’s update is mostly text-text-text, here’s a Tinymovr-powered jumping robot video to cheer things up a bit! :
Till next month!