Trinamic plugin not supported?

[wakass]

Hey,

I wanted to experiment a little bit using the pico and tmc2209 drivers, in combination with homing/bed scanning. Setting "#define TRINAMIC_ENABLE 2209" throws me an error in pico_cnc_map.h, but seems to not be a problem when manually editing the code to remove it.

Is this still not supported, what is the exact technical problem for compatibility?

Cheers,

waka

[terjeio]

Is this still not supported, what is the exact technical problem for compatibility?

Wiring? The pico_cnc_map.h is for a board with connection to external drivers so not well suited for (on board) Polulu style drivers. However, it can be wired for external TMC2209 drivers in UART mode by modifying the map file. See the btt_skr_pico_10_map.h for how to do that. Note that a single (soft) UART per driver is not supported, only a common UART for all. This limits max drivers/motors to 4.

[wakass]

Hi @terjeio,

Thanks for the tip. I'll just hi-jack this issue now that I'm a little more familiar with the codebase, and have a somewhat working picocnc board. I've current populated it with a single tmc2209 (fysetc 3.1) mapped to the z-axis. I'm also trying to use gpio0 (tx), and gpio1 (rx) to get comms going. There's a 1K resistor between TX and UART_PDN, and RX(pico)), as per the tmc2209 datasheet.

So far i'm not having any luck. I'm receiving the "Could not communicate with driver" for all values of $338.
One of my suspicions was that the address is mapped using the motor id (which i'm guessing is 2 for the z-axis, although i'm having a hard time finding any documentation on mappings internal to grbl(core) - pins, id, ports etc.) So i played around modifying the address, as below:

Right now i'm using a simple

#undef TRINAMIC_ENABLE
#undef TRINAMIC_UART_ENABLE
#define TRINAMIC_ENABLE 2209
#define TRINAMIC_UART_ENABLE 1

while I found some pre_init magic from a similar-ish issue on the ESP32 board.

#if TRINAMIC_UART_ENABLE == 1
static void driver_preinit (motor_map_t motor, trinamic_driver_config_t *config)
{
    config->address = 0;
}
#endif

void tmc_uart_init (void)
{
    #if TRINAMIC_UART_ENABLE == 1
        static trinamic_driver_if_t driver_if = {
            .on_driver_preinit = driver_preinit
        };

        trinamic_if_init(&driver_if);
    #endif


    memcpy(&tmc_uart, serialInit(230400), sizeof(io_stream_t)); //initialize uart0

    tmc_uart.disable_rx(true);
    tmc_uart.set_enqueue_rt_handler(stream_buffer_all);
}

The board_init is calling this function. I've modified serialxInit to use uart0, which I'm assuming is not a problem.

Anyway, any help is appreciated.

All the best,

WakA

[wakass]

Happy tidings for the new year. It appears the motor supply (V_s) is required before it responds to commands. 🎇

[terjeio]

Pin mappings are mostly done in the MCU specific driver.c via #defines in a board map file. The core communicate pin state changes of the pins via functions (function pointers) set in the HAL structure by driver.c at startup - so the core has not idea about how the actual hardware is working.

One of my suspicions was that the address is mapped using the motor id (which i'm guessing is 2 for the z-axis,

Correct - when a single UART is used for communicate with all (up to 4) the TMC2209 drivers. The slave address set for the driver has of course to match that. Separate (soft) UARTs, one per driver, can also be used - this typically use slave address 0 for all and then the driver_preinit() function has to be added to override the default motor id -> slave address mapping. Motor ids start at 0 for X, 1 for Y etc.

Techincal documentation is a sore point, I have started using doxygen to create it from the source but there is a lot more work to do before that is finished.

[wakass]

Thanks, the structure of the HAL abstraction layer is becoming a little more clear as I go a long. Still, yes, more documentation is more better :) Keep up the good work! My UART is working great now.

I'm now in the process of trying to get sensorless homing going, and hope you have some advice.

My general approach is xlimit and ylimit pin mapping to the DIAG pin of the tmc2209. Which I'm hoping is the correct approach.

I'm finding that the motor moves just fine with some basic settings ($10x - steps/mm, $110- max rate, etc), a relative move G91 works just fine.
Enabling Stallguard however leads to immediate problems (M122 X S1). sg_result's range ends up pretty quickly in the range of <10 for most step-resolutions. I've also found that enabling pwm_autoscale (disabled in stallGuardEnable (driver->pwmconf.reg.pwm_autoscale = false;)) recovers full behaviour, and I'm curious why this setting is disabled. I'm surmising the pwm_scale is way too low to drive the motor. I can't find any reference in the datasheet with regards to stallguard on this settings.

Here's a list of events, attempting to debug this issue:

--> G91 G1 X5 F500
** X-axis moves normally


--> M122 X S1
M122
[TRINAMIC]
                      X       Y       Z
Driver          TMC2209 TMC2209 TMC2209
Set current         900     900     500
RMS current         887     887     489
Peak current       1254    1254     691
Run current       28/31   28/31   15/31
Hold current      14/31   14/31    7/31
CS actual         14/31   14/31    7/31
PWM scale            16     167     201
vsense          1=0.180 1=0.180 1=0.180
stealthChop       false    true    true
msteps               16      16      16
tstep           1048575 1048575 1048575
pwm
threshold             0       0       0
[mm/s]                0       0       0
OT prewarn        false   false   false
OT prewarn has
been triggered    false   false   false
off time              3       3       3
blank time            1       1       1
hysteresis
-end                 -1      -1      -1
-start                1       1       1
Stallguard thrs      50       0       0
DRIVER STATUS:
stallguard     
sg_result            64       0       0
fsactive                               
stst                  *       *       *
olb                                    
ola                   *                
s2gb                                   
s2ga                                   
otpw                                   
ot                                     
STATUS REGISTERS:
 X = 0xC0:0E:00:40
 Y = 0xC0:0E:00:00
 Z = 0xC0:07:00:00
ok
--> G91 G1 X5 F400
ok
[SG:64]
[SG:90]
[SG:2]
[SG:2]
[SG:68]
[SG:68]
[SG:224]
[SG:154]
[SG:4]
[SG:4]
[SG:68]
[SG:68]
[SG:228]
[SG:38]
[SG:4]
[SG:4]
[SG:30]
[SG:30]
[SG:34]
[SG:34]
[SG:6]
[SG:30]
[SG:30]
[SG:226]
[SG:28]
[SG:28]
[SG:2]
[SG:32]
[SG:32]
[SG:226]
[SG:30]
[SG:2]
[SG:2]
[SG:30]
[SG:30]
[SG:226]
[SG:138]
*** Note low sg values

I'm also curious the usual approach to tuning StallGuard within grblHAL, if indeed there is one. Is it the intention to have M122 X S1 enabled during $HX homing sequence for example, and are these results then e.g. reliable. I'd be happy to make a little document describing any steps when I've eeked out my machine.

WakA

[terjeio]

I've also found that enabling pwm_autoscale (disabled in stallGuardEnable (driver->pwmconf.reg.pwm_autoscale = false;)) recovers full behaviour, and I'm curious why this setting is disabled.

Cannot answer that as I do not remember. I will have to go back to the datasheet myself...

recovers full behaviour

Meaning that sensorless homing is working?

Is it the intention to have M122 X S1 enabled during $HX homing sequence

No, currently I use the output for the Trinamic tuning tab in ioSender. There motion commands (G1) can be sent and a graph is plotted using the reported values.

I'd be happy to make a little document describing any steps when I've eeked out my machine.

That would be nice. Not that some parameters are hardcoded in trinamic.h.
I will add toff to the chopper_timing constants in an upcoming commit, with different default values for TMC2209 and the TMC2130/TMC5160 drivers, to allow even more fine grained tuning.

and are these results then e.g. reliable.

Well, I find the whole tuning process quite complicated, motor characteristics, feed rate, acceleration, load and what not affects the results.

[wakass]

OK, I think i figured some stuff out. I've raised some issues

terjeio/Trinamic-library#6
grblHAL/Plugins_motor#9
grblHAL/Plugins_motor#10

I'll try to do a nice write-up on the tuning-process in the near future.

Cheers

[terjeio]

Thanks for digging into this, I'll come back to this after finishing a core update and clearing most of the issue backlog.