What are the requirements to support ganged motors with Trinamic drivers

[jevermeister]

I am currently porting grblHAL to a BTT Rumba32 board with UART mode for the TMC2209 I'll be using.

I read in the SKR 2.0 driver file

if TRINAMIC_ENABLE && N_GANGED > 0

error "BTT SKR-2 does not support ganged motors with Trinamic drivers."

endif

however the SKR 1.1 driver doesn't have such a limitation although both boards support UART mode.

Could you tell the reason that the SKR 2.0 doesn't support ganged motors with Trinamic drivers so I know before trying this on my Rumba32 port?

[terjeio]

Could you tell the reason that the SKR 2.0 doesn't support ganged motors with Trinamic drivers so I know before trying this on my Rumba32 port?

Most likely th reason is that the test was not removed when ganged support was added to the motors plugin. Try with the lines removed.

[WellDone2094]

Hi @jevermeister, did you manage to get ganged motors working on skr 2?

[jevermeister]

Hi @jevermeister, did you manage to get ganged motors working on skr 2?

Hi,

I don't have a SKR 2 but a Rumba32. As both use UART mode for the trinamic drivers I assume that in case it works, it will work for both boards. However currently I am still building my MPCNC and did not switch to grblHAL yet. Therefore I don't know, sorry.

[terjeio]

@WellDone2094 Did it fail for you after removing the lines I mentioned?

[WellDone2094]

@terjeio compilation was fine without those line, but i'm still waiting for the board to be delivered to test it. i used N_GANGED=2 and N_ABC_MOTORS=2, is that correct if i want to have 2 X motors and 2 Y motor and a limit switch for each? i would like to have auto squaring on both axis.

[terjeio]

i used N_GANGED=2 and N_ABC_MOTORS=2, is that correct if i want to have 2 X motors and 2 Y motor and a limit switch for each?

No - do not change those symbols - configuration should be done in my_machine.h, the preprocessor sorts out the rest.

[WellDone2094]

oh, i didn't see that file, that's much easier, i'll try it. Thanks

[WellDone2094]

i can confirm it compiles, i should be able to test it on the board this weekend.

[WellDone2094]

hi @terjeio, i commented the line -D OVERRIDE_MY_MACHINE inside platformio.ini and set #define TRINAMIC_ENABLE 2209 // Trinamic TMC2209 stepper driver support. NOTE: work in progress. inside my_machine.h

i then built the frimware with the command `pio run --environment btt_skr_2_tmc2130. The firmware build without issues and it get flashed succesfully, but after flashing it my pc doesn't see the board anymore.

Any suggestions?

[terjeio]

You flash with a SD card (bootloader)? If so check this comment.

[WellDone2094]

thanks that worked! and the ganged + auto-squaring worked!

[WellDone2094]

everything seems to be working but iosender/grblhal freeze quite often, i think there is some problem with the firmware because restarting ioSender doesn't help but resetting the board fixes the issue

[WellDone2094]

after flashing it again, it seems way more stable. The only problem now is that setting the correct microstep and set/mm seems to move too much (about two times). I have a gt2 belt, 1.8 stepper driver, 16 microsteps, 16T pulley. the correct value should be 100 but i have to set 50 if i want to move the correct distance

[terjeio]

everything seems to be working but iosender/grblhal freeze quite often, i think there is some problem with the firmware because restarting ioSender doesn't help but resetting the board fixes the issue

When this happens can you connect with a terminal program such as PuTTY? Any response from a real-time report request by typing ?.

The only problem now is that setting the correct microstep and set/mm seems to move too much (about two times).

I have checked with two unmarked steppers that I believe are 1.8 deg/step and rotation agrees with the settings. I set steps/mm to 200 and sent commands to move one rotation when checking.

[WellDone2094]

i tired to connect to the board using putty after iosender freezed but it doesn't connect. I also tried to unplug and replug the board to make sure nothing was using the port but when i plug it in the pc doesn't recognize it. After a reset everything works again and i can connect to it with putty without issues. is there something i can do to debug it? debug mode, connect in a different way than usb or anything else?

[WellDone2094]

about the step/mm i'm using a 1.8 deg motor, with a 16T pully and a gt2 belt, this shoud have a 100 step/mm but i need to use 50 if i want to move correctly. skr 2.0 with tmc 2209

[terjeio]

I also tried to unplug and replug the board to make sure nothing was using the port but when i plug it in the pc doesn't recognize it.

OK, then it is likely the controller has crashed for some reason, a bug or electrical interference? FYI I ran a 3hr test yesterday with a F446 board without issues - will run a longer one later today.

is there something i can do to debug it? debug mode, connect in a different way than usb or anything else?

Without a debugger your options is to try a different USB cable, bypass any USB hub or bypass board USB by connecting via a UART <> breakout board. Does it take long for the hang to happen? Does it happen when sitting idle? When the spindle starts? ...?

about the step/mm i'm using a 1.8 deg motor, with a 16T pully and a gt2 belt, this shoud have a 100 step/mm but i need to use 50 if i want to move correctly. skr 2.0 with tmc 2209

Set steps/mm to 200, microstepping to 16 and move the axis 16mm - does the motor turn one revolution? I did for me.

[WellDone2094]

Set steps/mm to 200, microstepping to 16 and move the axis 16mm - does the motor turn one revolution? I did for me.

i tried and the stepper turn two revolutions here you can see my grblahl settings

Does it take long for the hang to happen? Does it happen when sitting idle? When the spindle starts? ...?

it seems to be random, sometimes it take 2 minutes to crash sometime after 30 minute it's still working. often it happens when i try to move it, or while changing settings. I don't have a spindle attached yet

Today i will use a different cable and see if that helps.

Thanks for your support

[terjeio]

Does M122 respond with driver details or an error message?

[WellDone2094]

M122
[MSG:Warning: Could not communicate with stepper driver!]
ok

That's the M122 output.

Without a debugger your options is to try a different USB cable, bypass any USB hub or bypass board USB by connecting via a UART <> breakout board. Does it take long for the hang to happen? Does it happen when sitting idle? When the spindle starts? ...?

i think it was a cable problem, i have changed to a short cable and it hasn't crashed since. sorry for the false alarm

[terjeio]

I have just committed refactored TMC soft UART code that hopefully now works. Since I do not own a SKR 2.0 board I am not able to verify the code with that, but have partially tested it with a F446 Nucleo board and two Watterot TMC2209 modules.

[WellDone2094]

i will test it later today, i got an st-link v2 if that can help identifying the problem

[WellDone2094]

i flashe the new version and run M122 again, this time it worked and i got this output

M122
[TRINAMIC]
                      X       Y       Z      X2      Y2
Driver          TMC2209 TMC2209 TMC2209 TMC2209 TMC2209
Set current         700     700     500     700     700
RMS current         673     673     489     673     673
Peak current        951     951     691     951     951
Run current       21/31   21/31   15/31   21/31   21/31
Hold current      10/31   10/31    7/31   10/31   10/31
CS actual         10/31   10/31   10/31   10/31   10/31
PWM scale            10      10      10      10      10
vsense          1=0.180 1=0.180 1=0.180 1=0.180 1=0.180
stealthChop        true    true    true    true    true
msteps               16      16      16      16      16
tstep           1048575 1048575 1048575 1048575 1048575
pwm
threshold             0       0       0       0       0
[mm/s]                0       0       0       0       0
OT prewarn        false   false   false   false   false
OT prewarn has
been triggered    false   false   false   false   false
off time              3       3       3       3       3
blank time            1       1       1       1       1
hysteresis
-end                 -1      -1      -1      -1      -1
-start                1       1       1       1       1
Stallguard thrs       0       0       0       0       0
DRIVER STATUS:
stallguard     
sg_result             0       0       0       0       0
fsactive                                               
stst                  *       *       *       *       *
olb                                                    
ola                                                    
s2gb                                                   
s2ga                                                   
otpw                                                   
ot                                                     
STATUS REGISTERS:
 X = 0xC0:0A:00:00
 Y = 0xC0:0A:00:00
 Z = 0xC0:0A:00:00
 X2 = 0xC0:0A:00:00
 Y2 = 0xC0:0A:00:00
ok

i tried to set step/mm=200 and move 16mm but the stepper still turn 2 revolution

[acaballero6270]

Make sure you remove the jumpers on MS1 and MS2. There should be only one on the UART pin of the TMC2209.

[WellDone2094]

under the driver there is only one jumper like this

[terjeio]

i tried to set step/mm=200 and move 16mm but the stepper still turn 2 revolution

What happens if you change the microsteps setting? I can see that the Z driver has a different current setting from the other drivers in the report above, can you try to set each differently and see if reported correctly?

[WellDone2094]

I set each axis to a different current and that seems to be working, but when i set Y-axis to 8 microsteps all the driers got changed to 8. Moving 16mm with 8 or 16 microstpes keeping 50 steps/mm produced the same results. The stepper rotated the same amount.

M122
[TRINAMIC]
                      X       Y       Z      X2      Y2
Driver          TMC2209 TMC2209 TMC2209 TMC2209 TMC2209
Set current         700     600     500     700     600
RMS current         673     581     489     673     581
Peak current        951     821     691     951     821
Run current       21/31   18/31   15/31   21/31   18/31
Hold current      10/31    9/31    7/31   10/31    9/31
CS actual         10/31   10/31   10/31   10/31   10/31
PWM scale            10      10      10      10      10
vsense          1=0.180 1=0.180 1=0.180 1=0.180 1=0.180
stealthChop        true    true    true    true    true
msteps                8       8       8       8       8
tstep           1048575 1048575 1048575 1048575 1048575
pwm
threshold             0       0       0       0       0
[mm/s]                0       0       0       0       0
OT prewarn        false   false   false   false   false
OT prewarn has
been triggered    false   false   false   false   false
blank time            1       1       1       1       1
hysteresis
-end                 -1      -1      -1      -1      -1
-start                1       1       1       1       1
Stallguard thrs       0       0       0       0       0
DRIVER STATUS:
stallguard     
sg_result             0       0       0       0       0
fsactive                                               
stst                  *       *       *       *       *
s2gb                                                   
s2ga                                                   
STATUS REGISTERS:
 X = 0xC0:0A:00:00
 Y = 0xC0:0A:00:00
 Z = 0xC0:0A:00:00
 X2 = 0xC0:0A:00:00
 Y2 = 0xC0:0A:00:00

After resetting the board all driver go back to 16 microsteps even if grblhal shows 8 for the Y axis

[terjeio]

Do you have an oscilloscope? I wonder if this somehow is related to the motor power circuitry on this board. If I remove motor power from the stepper driver and reconnect it msteps goes to 8 which I assume is the default value in the driver. Some data presented in the M122 report are read from the driver and some from "shadow registers" kept in MCU RAM only - since some changes and others not suggests that the drivers somehow are reset when they should not be.

In my test setup a M122I restores msteps to the configured value after reconnecting motor power.

[WellDone2094]

unfortunately I don't have an oscilloscope, from my tests I can see two issues

• changing microsteps doesn't seem to change the stepper/driver behavior
• changing the microstep on one of the axes affects all the drivers, I also noticed that after the reset all the drivers have the same microstep settings as the X-axis, this lead me to think that the X-axis is the last one to be confgured and since the microsteps settings is applied to all the driver this affect all other axis as well

[terjeio]

This is likely a hardware/software compatibility issue with this board - when I test with my Nucleo board and hardware UART everything works as it should. When I compile with soft UART enabled, comment out a bunch of code and set breakpoints to check the step resolution data transferred (in the chopconf register) everything looks ok. Without the actual hardware to check the code on there is not much more I can do unless somebody donate a board to me (Bigtreetech?) to work with. I can support attempts to resolve this by debugging but I am afraid that a logic analyzer or a scope is required to verify data transfers.

I find it odd that the drivers seemingly revert to default values - the initialization function checks that intial configuration sequence has been acceped by the driver by comparing the accepted transaction count with the expected count. If this fails driver initialization is aborted for the remaining drivers - which is not the case since there is no error reported on a M122 anymore.

[WellDone2094]

I have never worked with stm32 and i don't have much experience with microcontrollers, I'll see if I manage to understand the code and debug it. Could you point me to the part of the code that manages all this?

[terjeio]

There are basically four layers of code:

trinamic.c - which extends the grblHAL core with Trinamic specific settings, M-codes, orchestrates driver initialization etc. Most of this code is not Trinamic driver specific.

tmc2209_hal.c which is a relatively thin layer abstracting the different Trinamic driver implementations into an common API for use by trinamic.c. This is the TMC2209 version of that API.

tmc_2209.c which is contains data structures and code that matches the TMC2209 registers, handles driver initialization and calls the low level code that performs the actual data transfers.

tmc_uart.c is the low level code which handles the data transfers for UART mode drivers when using separate software UARTs for each driver. st_morpho.c is an alternative low level implementation for hardware UART communication where the driver is addressed in the message itself. This is not used by the SKR 2.0 board and is a lot simpler...

Only the low level code differs between the different boards and processors there are grblHAL drivers for. The top three layers are shared between them.

[terjeio]

@WellDone2094 Did you pull the submodules (recurse-submodules) when updating, if unsure check the header of your tmc2209hal.c file - does the date match?

[WellDone2094]

I did not, I'm going to update it and test it again, thanks you for pointing it out

[WellDone2094]

after the update everything seems to be working as expected, ioSender crashed a few times today but it may be due to other things. I will test this for a few more days. if nothing weird happens I think we can close this issue since the ganged motors with trinamic drivers is now supported.

Thanks for your time and patience @terjeio

[WellDone2094]

I have been testing it for the last two days and i have had quite few crashes where the board is not recognized by the pc anymore, before the last update it looked more stable, i will have to figure out how to connet the st-link to the board to get some debug info. Do i need to use STMcube to debug it?

[WellDone2094]

the crashes seems quite ranom, i run the same program 2 times an it crashed in at different moments, it usually takes 1/2 minutes before it crashes. Sometimes it stop responding while i'm joinging aroun to setup the machine

[terjeio]

Do i need to use STMcube to debug it?

It looks like PlatformIO can be used - but I have not used that. I use the STM32CubeIDE.

Sometimes it stop responding while i'm joinging aroun to setup the machine

A crash always happens during motion? Never when left idle?

[WellDone2094]

A crash always happens during motion? Never when left idle?

i test this and it crash also in idle, i turn it on, didn't move and after a few minutes it was not responding

[terjeio]

i test this and it crash also in idle, i turn it on, didn't move and after a few minutes it was not responding

Can you try with a different computer? Assuming the MCU not is powered by USB, can you connect after disconnecting/reconnecting the USB cable?

@acaballero6270 Is the connection stable for you?

[WellDone2094]

I tried to use a different pc and I get the same behavior, I tried to unplug and replug after the crash and the USB device doesn't get recognized, but as soon as I reset the board the pc recognize the device. I also tried to change pc after the crash but it didn't help. The new pc doesn't recognize the device until I reset it

[terjeio]

I only have a F411 Blackpill with native USB to test with, it has now run for 24 hours in idle mode with the console displaying the real time reports. Do you have any plugins enabled other than the Trinamic enabled? Do you have a (FTDI) UART <> USB breakout so we can test without having the MCU USB stack involved?

[WellDone2094]

yes i ave an FTDI and i just got a logic analyzer if that can help

[terjeio]

Ok, comment out this line, rebuild an reflash and connect the FTDI breakout to the TFT header (P1), Rx <> Tx and vice versa.

I am now 9 hours into a test program (185000+ lines) with the F411 Blackpill so still looking good here.

[WellDone2094]

i think it's working find for you, on my board it takes less than 10 minutes from boot to crash, i'll try to debug as you suggested and get back to you

[WellDone2094]

after a quick test I was able to complete a program successfully using the FTDI. I then went back to the USB_SERIAL_CDC=1 and tried the same program and I crashed.

Do you think it's worth testing with a new cable or do you suspect the issue it's something else? this cable seems fine before the last pull. but if you think it may be the reason i will buy another cable just to be sure

[WellDone2094]

meanwhile i will run a longer program with FTDI

[WellDone2094]

after a longer test it crashed using FTDI too, I tried to send commands using putty but it's not responding, as soon as I rest the board it starts working again.

[acaballero6270]

Connection is stable for me

[terjeio]

Connection is stable for me @acaballero6270 Thanks for this info.

Do we have some kind of wiring issue at hand? Ground loops? Interference? Bad board? Bad power supply? Is Marlin stable?