terjeio / trinamic-library

Plain C library for Trinamic TMC2130 stepper drivers

Trinamic driver library

21-08-10: Refactored to support ganged motors, some API changes.

Supports TMC2130, TMC2209 and TMC5160 drivers.

Written in plain C, processor agnostic. Processor specific low-level communications layer has to be added by user.

This library is used by some grblHAL drivers and examples of low-level communications layers and a higher level configuration/reporting layer implementation can be found there.

A SPI <> I2C bridge implemented on a TI MSP430G2553 processor that may be used for systems with limited IO capabilities.

---

2021-08-10

trinamic-library's Issues

TMC2209 - $14x setting is being affected by VREF pot

I am trying out grblHAL on an STM32F4Discovery board with a BigTreeTech TMC2209 v1.3 driver board. I noticed a significant discrepancy in the current measurements I was getting from running motors when I used it in pure STEP/DIR mode with no UART control and setting current via potentiometer, versus using UART control and setting the current digitally using $140. The UART control mode was reading something like half of the current of the STEP/DIR mode.

After some investigating I discovered that changing the potentiometer still affects the current even when using $14x to configure the current. In other words, I actually played with the potentiometer while the motor was running and could see the current changing.

Looking at the source code, I can see in tmc2209.c in TMC2209_Init:

// Use default settings (from OTP) for these:
//  driver->gconf.reg.I_scale_analog = 1;
//  driver->gconf.reg.internal_Rsense = 0;
//  driver->gconf.reg.en_spreadcycle = 0;
//  driver->gconf.reg.multistep_filt = 1;

I admit it is not ultra clear in the datasheet, but it appears that when I_SCALE_ANALOG is left at 1, then the value on the TMC2209 VREF pin still modulates the actual output current, whereas if you set it to zero it uses an internal reference. After doing some digging it seems like Marlin explicitly sets this setting to 0 as does the Arduino TMC2209 library ( https://github.com/janelia-arduino/TMC2209 ).

I changed my TMC2209_Init setup to set I_SCALE_ANALOG to 0 in TMC2209_Init and it then made my readings insensitive to changing the VREF potentiometer, and gave me values about what I expect.

I do have some concerns that the straightforward fix could drastically change the current values people with existing machines will get after a firmware update. If they set their current limits based off of motor datasheets, I would guess they would mostly be OK, but if it they set this value empirically based on how hot the motors got or something it could be a nasty surprise.

Library uses unaligned access to structure members

This results in inability to execute the code with PIC32MZ series.
Removing the #pragma pack() directives enables the execution, however, the results are incorrect.
Reordering all the members in all structures may be required to avoid the need to use packing

#include "grbl/hal.h" in tmc2209hal.h (on line 46)

motor_map_t in tmc2209hal.c and tmc2209hal.h defined nowhere

Traces of merge conflicts in the code

The current master branch has a ton of traces from merge conflicts checked in.

% egrep '<<<<<<<|=======|>>>>>>>' * |head -n20
common.c:<<<<<<< HEAD
common.c:=======
common.c:>>>>>>> b687cda0f174c908cc9421b42af9b442f3fa6112
common.h:<<<<<<< HEAD
common.h:=======
common.h:>>>>>>> b687cda0f174c908cc9421b42af9b442f3fa6112
common.h:<<<<<<< HEAD
common.h:=======
common.h:>>>>>>> b687cda0f174c908cc9421b42af9b442f3fa6112
common.h:<<<<<<< HEAD
common.h:=======
common.h:>>>>>>> b687cda0f174c908cc9421b42af9b442f3fa6112
tmc2130.c:<<<<<<< HEAD
tmc2130.c:=======
tmc2130.c:>>>>>>> b687cda0f174c908cc9421b42af9b442f3fa6112
tmc2130.c:<<<<<<< HEAD
tmc2130.c:=======
tmc2130.c:>>>>>>> b687cda0f174c908cc9421b42af9b442f3fa6112
tmc2130.c:<<<<<<< HEAD
tmc2130.c:=======

This makes it impossible to compile the code.

% gcc common.c 
In file included from common.c:39:
./common.h:44:1: error: version control conflict marker in file
<<<<<<< HEAD
^
./common.h:54:1: error: version control conflict marker in file
<<<<<<< HEAD
^
./common.h:139:1: error: version control conflict marker in file
<<<<<<< HEAD
^
common.c:78:1: error: version control conflict marker in file
<<<<<<< HEAD
^
4 errors generated.

At least some of them were introduced with commit cdc4fda.

Possible bug. Stallguard not functioning without pwm_autoscale on tmc2209

Stallguard does not function properly (or as expected?) on a 2209 driver. The following line is relevant, and setting autoscale to true recovers proper stallguard behaviour on my system:

Trinamic-library/tmc2209hal.c

Line 162 in 9eae92b

driver->pwmconf.reg.pwm_autoscale = false;

I'm not sure how this works in other driver modules, but I can't find any reference on stallguard requiring disabling pwm_autoscaling. Just tcoolthrs < tstep < tpwmthres

tmc2209hal.h not #included anywhere

Found a typo in trinamic.c

Hi
I was struggling to get the XYZA to show up in ioSender as the screenshot shows
I know I could just set it via the interface but I will be offering the firmware as a free download to the CNC foam-cutting community and I'm sure I would get some users who would struggle. So the aim is to make all the defaults in the eeprom.

and after a few hours of head scratching and searching the code I found at line 424 in trinamic.c
trinamic.driver_enable.z = TMC_A_ENABLE;
changed it to
trinamic.driver_enable.a = TMC_A_ENABLE;

All working fine now, thanks for a great library. This going to power a 4-axis foam cutter using the SKR Pico. I had great success with the grbl Mega 5X but it is time to move on now. Should have some videos out soon.
Keith

TMC2209 support for ganged axis

Currently the library is unaware of ganged X/Y/Z axis so tinkering with them and changing their settings is not possible. I think that due to this the initialization fails too due to the amount of successful writes that happen which are checked here

grblhal expects axis X2/Y2/Z2 but this lib sets up A, B and C