Marlin: TMC2130 Problem with Steps/s

[ss89]

• Description: I did install a TMC2130 driver in my printer lately and configured the firmware to use it. At first i notices that it moved much more (in terms of length) than my TMC2100 that was installed before. i then just put the steps/mm down to 1/4th which worked then in my testing movements via USB. When i was ready to print (which i do via SD card) on my ramps board via LCD Full Graphics controller it did move again much too much. When printing via PC it moved the correct amount of mm (even though i had to reduce the steps/mm in firmware to 1/4th). I thought it was used as a 1/16th microstep stepper driver.
  Someone should really try to write something together on how to get these beasts working, also a troubleshoot guide would be awesome. The information on the internet about this thing is quite rare.
• Expected behaviour: Stepper motor moving the same amount of steps via SD Card Gcode command and via PC-USB Gcode command.
• Actual behaviour: TMC2130 driver moves 4 times as much via SDCard print.
• Steps to reproduce:
  
  
  
  • Replace a working TMC2100 with a TMC2130
  
  
  • Wire the TMC2130 to SPI (CS is Pin 40 for me)
  
  
  • Start an SD Card print.
  
  
  • See that it moves more than expected.
  
  

Archiv.zip

[teemuatlut]

There really shouldn't be any difference between USB and SD printing. But let me recap a bit.
Please set the correct steps per mm and tell me this:
How far will a 10mm command through USB move?
How far will a 10mm command through SD move?
What is your start gcode in your slicer?

I'll first suggest you dial back on any relevant changes you've made thus far. Try to first get the basic functionality working. So disable SENSORLESS_HOMING, restore interpolation and remove what you have in TMC2310_ADV. These really shouldn't affect the situation in any way but it's just something to cross over.

Create a basic gcode file for testing. For example:

G28 Y
G1 Y10

Also you seem to be running with really low current values (~336mA), but that doesn't cause additional steps to be taken.

[psavva]

With such a low current, is very possible that steps are being skipped. Hence the inconsistency in distance. Try increasing and see if the problem goes away. My steppers drivers are set to about 70% of the rated current of the motors

[ss89]

@teemuatlut
Without any changes to my current setting in TMC2130_ADV:
10mm via USB with 100steps/mm (default for 1/16µstep on 16t pulleys) it moves 40mm.
10mm via SD-Card with 100steps/mm (default for 1/16µstep on 16t pulleys) it moves 80mm.
Btw. when printing via USB with 25steps/mm i do not see any quality issues, there is no step loss.
When printing via SD-Card i also had to provide more movement commands to fill up the command buffer i guess, otherwise it wouldn't move at all after homing.

It seems to me that the current isnt set anyway, because it doesnt make any difference in sound or print quality.

Without any changes to the original setting in TMC2130_ADV (empty):
10mm via USB with 100steps/mm (default for 1/16µstep on 16t pulleys) it moves 10mm.
10mm via SD-Card with 100steps/mm (default for 1/16µstep on 16t pulleys) it moves 20mm.

What the heck ^^ Any tips are welcome.

Sensorless homing doesn't work for me anyway btw. There is no signal on the pin that should supply me with my endstop signal. I just let it skip until its software endstop stops the motor.

[teemuatlut]

Have you tried changing the TMC2100 back?
Do you see this same behavior with both X and Y axis?

I do have an idea that we can test. My prime suspect is that the microsteps get configured wrong for some reason. But to verify that I need to expand the M122 to give a read out from the correct register.
In the mean time, you can try my TMC development branch if you're not using it already. It'll give you the configured microsteps but I'd like to take a look at the actual HEX value of the register. Also make sure you are using the latest v2.0.1 version of the library.

Not that any of it would explain the difference between USB and SD...

[ss89]

@teemuatlut
I have tried putting it back and the TMC2100 moved much less now (have not reuploaded the firmware, just the driver switch).
I do only see that behaviour on the Y-Axis, so i guess enabling the TMC2130 for a specific axis changes something in the firmwares behaviour.
Also please note that i do currently use Version 2.0.0, but will try 2.0.1.
I do not know why the steps should be configured differently for sdcard print vs. usb print/commands.
M122 does not give any feedback but "ok" :-/
Will try your Version of Marlin now.

[ss89]

This is what your branch says on M122 (Stepper is enabled, though output looks like it says otherwise. Also the Stepper is moving much too fast => Skipping. And it seems to go in one direction, on the next try for the same direction goes into the other direction.

EDIT: Removed Quote of M122, as i forgot to edit the ramps pins.h

[ss89]

Wait, i totally forgot something: updating the pins for ramps :-(

[ss89]

@teemuatlut
Output of M122:

< 19:53:43: Y
< 19:53:43: Enabled     false
< 19:53:43: Set current 200
< 19:53:43: RMS current 331
< 19:53:43: MAX current 467
< 19:53:43: Run current 5/31
< 19:53:43: Hold current    5/31
< 19:53:43: CS actual       0/31
< 19:53:43: PWM scale   0
< 19:53:43: vsense      0=.325
< 19:53:43: stealthChop false
< 19:53:43: msteps      256
< 19:53:43: tstep       0
< 19:53:43: pwm
< 19:53:43: threshold       0
< 19:53:43: [mm/s]      -
< 19:53:43: OT prewarn  false
< 19:53:43: OT prewarn has
< 19:53:43: been triggered  false
< 19:53:43: off time        0
< 19:53:43: blank time  16
< 19:53:43: hysterisis
< 19:53:43: -end        -2
< 19:53:43: -start      1
< 19:53:43: Stallguard thrs 1
< 19:53:43: DRVSTATUS   Y
< 19:53:43: stallguard      
< 19:53:43: sg_result       0
< 19:53:43: fsactive        
< 19:53:43: stst        
< 19:53:43: olb     
< 19:53:43: ola     
< 19:53:43: s2gb        
< 19:53:43: s2ga        
< 19:53:43: otpw        
< 19:53:43: ot      
< 19:53:43: Driver registers:
< 19:53:43: Y = 0x00:00:80:80

[ss89]

The Stepper is still skipping btw.

EDIT: I used the latest 2.0.1 Version of your lib in the M122 test.

[teemuatlut]

That msteps value is really weird but much else is at least suggesting that the communication is working alright.
If the driver thinks it's in 256 microsteps mode, then Marlin with 16 microsteps configured, your axis should move only 1/16th as much as was instructed. However, the 256 steps setting is register value 0b0000 so it's possible that the library received bad data. So I'll be writing an extension to the M122 command that will give us the HEX value of the register.
Do you happen to have another TMC2130 driver? Just to rule out a faulty component.

[teemuatlut]

I've pushed an update to my Marlin fork and it should give you the CHOPCONF register value so we can see what's happening. Either all 1 or all 0 would be suspicious.

[ss89]

I had a TMC2130 before that also behaved very wierd.
Maybe it could also be a batch problem.
It's one of these fystech tmc2130 v1.0 from aliexpress.
Should i buy one from watterott or somewhere else instead?
@teemuatlut Can you possibly write a test command for testing whether communication with the driver works correctly?

[teemuatlut]

I'd always recommend a genuine one by Watterott, whether it's from them directly or from a reseller. As I don't have experience with the Aliexpress ones, I can't tell where the problem might be.

Basically my M122 debugging command would serve that function but I could add a simple test to it to give the user a clear ok.

[fabriciomoeller]

I am having the same behavior on the TMC2130 driver.
Compare with the TMC2100 that works normally.

I'm using Marlin 1.1.5

[ss89]

@teemuatlut that would be great. Thanks for making that clear, will buy one of these instead then.

@fabriciomoeller did you use drivers from aliexpress aswell? I do use Marlin 1.1.5 aswell

[leanid-raichonak]

When i was ready to print (which i do via SD card) on my ramps board via LCD Full Graphics controller it did move again much too much.

Hi. Just a question: how you connected TMC2130 and LCD/SD reader simultaneously if they both must to use SCK/MISO/MOSI which are single on the RAMPS board?

[teemuatlut]

You can try to extend the pins like I did but it's a bit dirty. Or you could get taller pin headers. The SPI pins are also exposed on the ICSP header on the Mega.
It might be nice to have the option for software SPI so I might do that for the next evolution of the library.

@ss89 I'm in no way saying that it would be a definitive solution but it's the only difference I can think of right now.

[fabriciomoeller]

@ss89 Yes, I'm using aliexpress driver.

I am using a RUMBA board.

Firstly I did not activate the driver via SPI using it as if it were a TMC2100

Then I activated the TMC2130 as follows:

#define HAVE_TMC2130

#define X_IS_TMC2130
#define Y_IS_TMC2130

#define R_SENSE 0.11
#define INTERPOLATE 1 // Interpolate X / Y / Z_MICROSTEPS to 256

#define X_CURRENT 1000
#define X_MICROSTEPS 16 // 0..256

#define Y_CURRENT 1000
#define Y_MICROSTEPS 16

#define STEALTHCHOP

In the arcade pins_RUMBA.h

#define X_CS_PIN 53
#define Y_CS_PIN 49

Note: These pins are used as default below:

#define SDSS 53
#define SD_DETECT_PIN 49

But this does not seem to be the reason for the behavior sited polo @ss89

[Bob-the-Kuhn]

As long as each device driver controls its chip select properly then they can all share the same SCK, MISO & MOSI. This assumes you can find a speed that's acceptable to all.

As stated earlier, software SPIs are also an alternative but consume I/O pins.

One way of gaining physical access to the signals is to make a custom cable for the LCD. Most LCDs use a 10 pin cable to get those signals from the controller. Just add more 10 pin IDC connectors in the middle of the cable. If you don't like individual jumpers then, for $4, you can get a 10 pin breakout cable from Adafruit. It has the correct header to mate to the connectors that were added and each color coded wire is terminated in a single pin socket.

[ss89]

I am really bad at soldering BUT:

For me it was the bad drivers from china. Watterotts chip worked well on first try AND they don't wine as much as the aliexpress chips. Amazing! Thanks for your great work @teemuatlut
Will now experiment with having them for the X axis as well and then get this printer a job ;-)

[ss89]

@teemuatlut i did just want to make everything working in the original marlin which behaved differently than yours.
In yours everything moved correctly, while the original marlin has this 1/4th movement problem (still with the new drivers).
When will you PR the changes that are missing? Can't wait to make everything work, which i currently can not do in your marlin because there are issues with my bed probe.

[teemuatlut]

Yea I really should make a PR so I can stop telling people to use a development fork. Although I can't think of anything that might cause the problem you're seeing.
I will be rebasing my fork anyway.

[ss89]

@teemuatlut i can't imagine anything either, especially because Thomas Sanladerer posted a YouTube video with it working and not mentioning any problem with it. He also uses an inductive sensor and so should have had the same problem. OR i should just branch the 1.1.6 tag and put my config into it and then look whats happening. Thank you for your great support :-)

[ss89]

Never mind, clean Marlin with my config and it works ... weird. Possibly some merging problem on my side.

[VIPer2322]

Hi guys,

i used the guide from TOM for my X&Y axis.
But after homing (homing worked fine) i had also massive cracking on x&y when i tried to move like it goes on an mechanical collision. Step Loss

I tried almost everything to solve it. No luck.

But i found this fork, i just installed it and everything works fine.

Is it possible to implement this to the next release or at least in the development branches from the original Marlin Branch?

Thanks for your effort, i thought already for three days that i killed my board or my Stepper drivers.

Cheers Matt

[teemuatlut]

Which fork are you talking about?
If you're referring to my development branch, that was merged a couple days ago and is included in the v1.1.7 release. Even if it wasn't mentioned in the change log.

[VIPer2322]

Yea I meant your development branch.
Great thanks for the great news!
I will update the findige from 1.1.7 then.
Was looking dort he change logs.
Great work ;-)

[edism]

I'm having exactly the same problem. I've installed 2x TMC2130 on X-Y-Z axis and it moves 4x the distance i set.
What was the resolution on this? I do see some changed the drivers to OEM, instead of chinese from aliexpress.
Can anyone provide some guidance? I'm using the latest official 1.1.7 marlin

[thinkyhead]

I'll add the last-minute PRs to the 1.1.7 changelog forthwith.

[kibogaoka]

For anyone finding this through google that's also trying to get FYSETC TMC2130's to work: these boards are hardwired for standalone (no-SPI) mode, so connecting them to an SPI bus will do nothing but send random values to the CFG pins and cause weird behavior.

Pin 10 on the TMC2130-LA controls this. It should be left open for SPI mode, and pulled to ground for standalone mode. It is at the bottom-left of the package when viewed with the text right-side up. There is a small resistor directly to the left of this pin which connects it to ground, to enable SPI mode you must remove this resistor. I ripped it off with an iron and tweezers and can confirm M122 actually shows non-garbage data now, and I'm able to successfully set the current with M906.

[buliwyf42]

The fysetc driver have a small soldering bridge right beside the package. This is normally soldered to run them in standalone mode. On the watterott board the bridge is open. Removing the solder on the fystec does the trick as well. After that I also could set the current with M906

[edism]

I have tried this, de-soldered the bridge but still no luck. Driver moves 4x the distance and INCREDIBLY loud....

I've seen similar info here: https://github.com/MarlinFirmware/Marlin/issues/8480 which tells to solder other 2 terminals, but i was not able to do that.

[ss89]

@edism i wasn't either, in doubt: spend money and buy the watterott version - it works and is the one that @teemuatlut is using (the guy who wrote the library for arduino that marlin uses to set the tmc2130 config up).

[szymonrychu]

Hi!
I have the same problem- I replaced DRV drivers with TMC2130, set everything up correctly.
Several prints were pretty ok, thus there were overheating issues I overcome.

But now I cannot get them working properly!
No matter what I'm doing (adjusting microstepping in configuration_adv.h or adjusting steps_per_unit, the printer randomly at start sets up weird microstepping and sometimes printer scales down steps per mm twice, sometimes this gets scaled up twice as much).
I'm using latest 1.1.8.

[mindgy]

Hi
I have the same problem. I'm using genuine drivers from watterott, with marlin 1.1.8. + ramps 1.4 + lcd FULL_GRAPHIC_SMART_CONTROLLER.
The first time i tried, i had twice the movement, then i reduced the DEFAULT_AXIS_STEPS_PER_UNIT from 200, to 100. After the first print i noticed that the printer was skipping steps, (y axis, probably because of the high speed of the print), after this i tried to increase current from 800 to 1000) but the distance travel increase twice once again. Like before i changed the default steps from 100 to 50. It seemed to be ok, but after some modification on marlin the distance changed again (looks like It change in a radom way).
I did everything like Thomas said, with the diference of the SENSORLESS_HOMING, i did't make the connection for the endstop.

X_CS_PIN 66
Y_CS_PIN 44

[telamon]

I'm having similar issues, got a couple of modified Fystec tmc2130, where i followed the instructions from this thread: https://github.com/MarlinFirmware/Marlin/issues/8480

Anyways, the steppers are moving way too fast/much and make a huge noise while doing so.
Main problem is that it causes the steppers to overheat so that the overheat-protection kicks in and immediately kills the printer after a homing instruction.

I've touched the heatsinks after disabling MONITOR_DRIVER_STATUS and yes, they do physically overheat quite fast by just powering the coils in hold position, so it's not a false alarm.

I'm on a Rumba board btw, reprap-discount-fullgraphics display, Marlin 1.1.8, CoreXY printer, SPI wired to ISP1 header and chip-selects to pin 30 and 31. Hold multiplier set to 0.3, and current in firmware set to 600.

I'm not prepared to give up on these clones just yet, I still have the feeling that it's some weird configuration that's causing the cascade of issues. Nice knowing that I'm not the only one with this challenge. I guess it's normal for M906 to report current 0 when the coils are powered down? Cause i have never seen it report anthing else but 0 ..

[teemuatlut]

No it's not normal.
M906 doesn't even actually talk to the driver actually. It reports back the set current held by the library but because of how the current scale works this isn't precisely the current target the driver has. The actual value is reported back by M122.

Could you post your M43 output? PINS_DEBUGGING required.

[telamon]

(Sorry It's quite huge, shame to paste it here, I can edit comment to remove everything but the relevant lines if you tell me which indicators you're interested in.)
M43 Ouptut:

PIN:   0   Port: E0        RXD                         protected
PIN:   1   Port: E1        TXD                         protected
PIN:   2   Port: E4        HEATER_0_PIN                protected
PIN:   3   Port: E5        HEATER_1_PIN                Output = 0    TIMER3C   PWM:     0    WGM: 1    COM3C: 0    CS: 3    TCCR3A: 1    TCCR3B: 3    TIMSK3: 0
PIN:   4   Port: G5        SPINDLE_LASER_PWM_PIN       Input  = 1    TIMER0B   PWM:   128    WGM: 3    COM0B: 0    CS: 3    TCCR0A: 3    TCCR0B: 3    TIMSK0: 5   compare interrupt enabled   overflow interrupt enabled
PIN:   5   Port: E3        SERVO0_PIN                  Input  = 0    TIMER3A   PWM:     0    WGM: 1    COM3A: 0    CS: 3    TCCR3A: 1    TCCR3B: 3    TIMSK3: 0
PIN:   6   Port: H3        HEATER_2_PIN                Output = 0    TIMER4A   PWM:     0    WGM: 1    COM4A: 0    CS: 3    TCCR4A: 1    TCCR4B: 3    TIMSK4: 0
PIN:   7   Port: H4        FAN_PIN                     protected
PIN:   8   Port: H5        FAN1_PIN                    protected
.                          HEATER_3_PIN                protected
PIN:   9   Port: H6        HEATER_BED_PIN              protected
PIN:  10   Port: B4        <unused/unknown>            Input  = 1    TIMER2A   PWM:     0    WGM: 1    COM2A: 0    CS: 4    TCCR2A: 1    TCCR2B: 4    TIMSK2: 0
PIN:  11   Port: B5        BTN_EN1                     Input  = 1    TIMER1A   PWM:  2000    WGM: 4    COM1A: 0    CS: 2    TCCR1A: 0    TCCR1B: 10    TIMSK1: 2   non-standard PWM mode   compare interrupt enabled
PIN:  12   Port: B6        BTN_EN2                     Input  = 1    TIMER1B   PWM:     0    WGM: 4    COM1B: 0    CS: 2    TCCR1A: 0    TCCR1B: 10    TIMSK1: 2   non-standard PWM mode
PIN:  13   Port: B7        LED_PIN                     Input  = 0    TIMER0A   PWM:     0    WGM: 3    COM0A: 0    CS: 3    TCCR0A: 3    TCCR0B: 3    TIMSK0: 5   overflow interrupt enabled
.                  TIMER1C is also tied to this pin                  TIMER1C   PWM:     0    WGM: 4    COM1C: 0    CS: 2    TCCR1A: 0    TCCR1B: 10    TIMSK1: 2   non-standard PWM mode
PIN:  14   Port: J1        SPINDLE_LASER_ENABLE_PIN    Input  = 1
PIN:  15   Port: J0        SPINDLE_DIR_PIN             Input  = 1
PIN:  16   Port: H1        X_DIR_PIN                   protected
PIN:  17   Port: H0        X_STEP_PIN                  protected
PIN:  18   Port: D3        LCD_PINS_D4                 Output = 1
PIN:  19   Port: D2        LCD_PINS_RS                 Output = 0
PIN:  20   Port: D1        SDA                         Input  = 1
PIN:  21   Port: D0        SCL                         Input  = 1
PIN:  22   Port: A0        E0_DIR_PIN                  protected
PIN:  23   Port: A1        E0_STEP_PIN                 protected
PIN:  24   Port: A2        E0_ENABLE_PIN               protected
PIN:  25   Port: A3        E1_DIR_PIN                  Output = 0
PIN:  26   Port: A4        E1_STEP_PIN                 Output = 0
PIN:  27   Port: A5        E1_ENABLE_PIN               Output = 1
PIN:  28   Port: A6        E2_DIR_PIN                  Output = 0
PIN:  29   Port: A7        E2_STEP_PIN                 Output = 0
PIN:  30   Port: C7        X_CS_PIN                    Output = 1
PIN:  31   Port: C6        Y_CS_PIN                    Output = 1
PIN:  32   Port: C5        <unused/unknown>            Input  = 0
PIN:  33   Port: C4        Z_MIN_PIN                   protected
PIN:  34   Port: C3        Y_MAX_PIN                   protected
PIN:  35   Port: C2        <unused/unknown>            Input  = 1
PIN:  36   Port: C1        X_MAX_PIN                   protected
PIN:  37   Port: C0        <unused/unknown>            Input  = 1
PIN:  38   Port: D7        LCD_PINS_D5                 Input  = 1
PIN:  39   Port: G2        E2_ENABLE_PIN               Output = 1
PIN:  40   Port: G1        LCD_PINS_D7                 Input  = 0
PIN:  41   Port: G0        LCD_PINS_D6                 Input  = 1
PIN:  42   Port: L7        LCD_PINS_ENABLE             Output = 0
PIN:  43   Port: L6        BTN_ENC                     Input  = 1
PIN:  44   Port: L5        BEEPER_PIN                  Output = 0    TIMER5C   PWM:     0    WGM: 1    COM5C: 0    CS: 3    TCCR5A: 1    TCCR5B: 3    TIMSK5: 0
PIN:  45   Port: L4        CASE_LIGHT_PIN              protected
.                          PS_ON_PIN                   protected
PIN:  46   Port: L3        KILL_PIN                    Input  = 1    TIMER5A   PWM:     0    WGM: 1    COM5A: 0    CS: 3    TCCR5A: 1    TCCR5B: 3    TIMSK5: 0
PIN:  47   Port: L2        Y_DIR_PIN                   protected
PIN:  48   Port: L1        X_ENABLE_PIN                protected
PIN:  49   Port: L0        SD_DETECT_PIN               Input  = 1
PIN:  50   Port: B3        AVR_MISO_PIN                Input  = 0
.                          MISO_PIN                    Input  = 0
PIN:  51   Port: B2        AVR_MOSI_PIN                Output = 0
.                          MOSI_PIN                    Output = 0
PIN:  52   Port: B1        AVR_SCK_PIN                 Output = 1
.                          SCK_PIN                     Output = 1
PIN:  53   Port: B0        AVR_SS_PIN                  Output = 1
.                          SDSS                        Output = 1
.                          SS_PIN                      Output = 1
PIN:  54   Port: F0 (A 0)  Y_STEP_PIN                  protected
PIN:  55   Port: F1 (A 1)  Y_ENABLE_PIN                protected
PIN:  56   Port: F2 (A 2)  Z_DIR_PIN                   protected
PIN:  57   Port: F3 (A 3)  Z_STEP_PIN                  protected
PIN:  58   Port: F4 (A 4)  <unused/unknown>   Analog in =   550   Input  = 1
PIN:  59   Port: F5 (A 5)  <unused/unknown>   Analog in =   549   Input  = 1
PIN:  60   Port: F6 (A 6)  <unused/unknown>   Analog in =   748   Input  = 1
PIN:  61   Port: F7 (A 7)  <unused/unknown>   Analog in =   643   Input  = 1
PIN:  62   Port: K0 (A 8)  Z_ENABLE_PIN                protected
PIN:  63   Port: K1 (A 9)  <unused/unknown>   Analog in =   987   Input  = 1
PIN:  64   Port: K2 (A10)  <unused/unknown>   Analog in =   869   Input  = 1
PIN:  65   Port: K3 (A11)  TEMP_BED_PIN                protected
PIN:  66   Port: K4 (A12)  <unused/unknown>   Analog in =  1023   Input  = 1
PIN:  67   Port: K5 (A13)  TEMP_2_PIN                  Analog in =  1023
PIN:  68   Port: K6 (A14)  TEMP_1_PIN                  Analog in =  1023
PIN:  69   Port: K7 (A15)  TEMP_0_PIN                  protected

And output from M122 is:

x   y
enabled     false   false
set current 0   0
rms current 1767    1767
max current 2491    2491
run current 31/31   31/31
hold current    12/31   12/31
cs actual       12/31   12/31
pwm scale   128 128
vsense      0=.325  0=.325
stealthchop true    true
msteps      16  16
tstep       1048575 1048575
pwm
threshold       0   0
[mm/s]      -   -
ot prewarn  false   false
ot prewarn has
been triggered  false   false
off time        5   5
blank time  24  24
hysterisis
-end        2   2
-start      3   3
stallguard thrs 0   0
drvstatus   x   y
stallguard
sg_result       0   0
fsactive
stst        x   x
olb
ola
s2gb
s2ga
otpw
ot
driver registers:
x = 0x80:0c:00:00
y = 0x80:0c:00:00

[mindgy]

Send: M906
Recv: X axis driver current: 1000
Recv: Y axis driver current: 1000
Recv: ok

Send: M122
Recv: ok

Send: M43
Recv: ok

:/

[telamon]

@mindgy you probably need to have #define TMC_DEBUG and #define PINS_DEBUGGING uncommented in Configuration_adv.h in order for the debug-gcodes to work.

I see that my values for pwm_prescale, msteps and tsteps differ quite a bit from other people's M122 dumps, not quite sure what they do though. my tsteps looks quite arbitrary to my untrained eye, there should probably be some clue in the TMC2130 datasheet as to what theese registers symbolize.

[mindgy]

@telamon thank you

Send: M122
Recv: X Y
Recv: Enabled false false
Recv: Set current 1000 1000
Recv: RMS current 994 994
Recv: MAX current 1402 1402
Recv: Run current 17/31 17/31
Recv: Hold current 8/31 8/31
Recv: CS actual 8/31 8/31
Recv: PWM scale 1 1
Recv: vsense 0=.325 0=.325
Recv: stealthChop true true
Recv: msteps 16 16
Recv: tstep 1048575 1048575
Recv: pwm
Recv: threshold 0 0
Recv: [mm/s] - -
Recv: OT prewarn false false
Recv: OT prewarn has
Recv: been triggered false false
Recv: off time 5 5
Recv: blank time 24 24
Recv: hysterisis
Recv: -end 2 2
Recv: -start 3 3
Recv: Stallguard thrs 0 0
Recv: DRVSTATUS X Y
Recv: stallguard
Recv: sg_result 0 0
Recv: fsactive
Recv: stst X X
Recv: olb
Recv: ola
Recv: s2gb
Recv: s2ga
Recv: otpw
Recv: ot

btw, sometimes when i compile the code, this mensage pops up in arduino console:
C:Users\MinD\Documents\Arduino\librariesTMC2130Stepper\src\sourceSW_SPI.cpp: In member function 'void SW_SPIClass::init()':

C:Users\MinD\Documents\Arduino\librariesTMC2130Stepper\src\sourceSW_SPI.cpp:42:21: warning: invalid conversion from 'volatile uint8_t* {aka volatile unsigned char*}' to 'uint8_t {aka unsigned char}' [-fpermissive]

   mosi_register = portOutputRegister(getPort(mosi_pin));

                 ^

C:Users\MinD\Documents\Arduino\librariesTMC2130Stepper\src\sourceSW_SPI.cpp:43:21: warning: invalid conversion from 'volatile uint8_t* {aka volatile unsigned char*}' to 'uint8_t {aka unsigned char}' [-fpermissive]

   miso_register = portOutputRegister(getPort(miso_pin));

                 ^

C:Users\MinD\Documents\Arduino\librariesTMC2130Stepper\src\sourceSW_SPI.cpp:44:20: warning: invalid conversion from 'volatile uint8_t* {aka volatile unsigned char*}' to 'uint8_t {aka unsigned char}' [-fpermissive]

   sck_register = portOutputRegister(getPort(sck_pin));

                ^

what this mean?

[teemuatlut]

The compiler warnings are from the library and are concern the SW SPI implementation. I've fixed it but haven't pushed yet.

PWM scale is the value with which the driver scales the PWM signal to achieve the desired coil current.
msteps means microsteps.
tstep is the "time" between steps, normalized to 256, in terms of _driver_ clock cycles.

You can probably guess that many of these reported parameters are more for me than a normal user.

[telamon]

Yeah I figured, gonna take another shot at becoming you later this evening. I'm still playing the guessing game but from what I know right now, is that everything seems to work fine until the drivers step, they immediately fly into a screaming rage and triggering the overheat-flag just a second after the operation.
My M906 should atleast display something closer to the configured 600 vref (Given the assumption that once you're in SPI mode the small trimpot on the drivers is ignored) but instead it reads 0 and M211also reads zero, does zero indicate 'unlimited' or max? Either way, that's fishy. [END OF RANT]

I came kindof late into this discussion, and I might have forgot to mention that I'm using the vanilla 1.1.8 marlin + tmc2130 driver downloaded by the library manager. @teemuatlut you had another developer branch somewhere I understand?

[teemuatlut]

That branch was merged already and I haven't made anything significant since. Trying to move my development efforts into v2.0 base.

M122 and M906 use the same methods for reading the current.
Try this;

• Cold boot the machine from zero.
• Send M906. I presume this is when it reports 0 to you.
• Send M122. This would then be what you posted earlier.
• Send M906 X600 and then M500.
• Reboot the machine again. Preferably from zero power again.
• Send M906 again and see if the X driver 0 or 600.

I'm thinking that for some reason your EEPROM current setting is stored as 0 and is configured as such on boot time.

Yes, the trimpot is ignored because we use SPI to set the current.

[telamon]

@teemuatlut Yah it works, thanks, was an EEPROM setting bug.
both M906 and M122 reflect the new value and 'max rms' was lowered to correct voltage aswell.

Still having overheat issues though, after a few minutes of standstill the overheat flag triggers,
Is that overheat threshold embedded inside the stepper or is it something that's possible to configure?
Feeling the heatsink it's not even luke-warm. If it's a hardware issue then I guess that it's bad heat-conduction and that's the end of that. But if it's a software issue then the over-heat, over-step and over-speed might be related to eachother. Thanks for all the help so far :)

[mindgy]

I'm using genuine tmc2130 from watterot, and a fan to cool the drivers and I still get this mensage when i try to print.
I have the 4x distance problem, that I solved changing the default steps from 200 to 50.
It is possible that I mess with the connections? My connections and soldering are not pretty, nevertheless I think they are working fine.

Recv: Y driver error detected:
Recv: overtemperature
Recv: X Y
Recv: Enabled true true
Recv: Set current 1000 1000
Recv: RMS current 994 994
Recv: MAX current 1402 1402
Recv: Run current 17/31 17/31
Recv: Hold current 8/31 8/31
Recv: CS actual 17/31 17/31
Recv: PWM scale 97 133
Recv: vsense 0=.325 0=.325
Recv: stealthChop true true
Recv: msteps 16 16
Recv: tstep 8 10
Recv: pwm
Recv: threshold 0 0
Recv: [mm/s] - -
Recv: OT prewarn true true
Recv: OT prewarn has
Recv: been triggered true true
Recv: off time 5 5
Recv: blank time 24 24
Recv: hysterisis
Recv: -end 2 2
Recv: -start 3 3
Recv: Stallguard thrs 0 0
Recv: DRVSTATUS X Y
Recv: stallguard
Recv: sg_result 0 0
Recv: fsactive
Recv: stst
Recv: olb
Recv: ola X
Recv: s2gb
Recv: s2ga
Recv: otpw X X
Recv: ot X
Recv: Driver registers:
Recv: X = 0x24:11:00:00
Recv: Y = 0x06:11:00:00
Recv:
Recv: Error:Printer halted. kill() called!
Changing monitoring state from 'Printing' to 'Error: Printer halted. kill() called!

[telamon]

@mindgy I'm starting to suspect the same, that the soldering instructions might not be the best to blindly follow. I understand why I unsoldered the SPI bridge, but the cfg4 and cfg5 bridges i'm not quite sure about, maybe we should ask the same question in the other thread if anyone else is experiencing these issues. And dive into the datasheet and figure out what exactly we've done, not to mention just trace the leads and compare that to the offical watterot schematics. I suspect there's a bug somewhere and I don't want to use 1/4th step configuration as a workaround to get the right amount of steps. But yeah, your printer was halted the same as mine due to overheat-flag triggered, it's not a false alarm it does really overheat and even at ridiculous undercurrents..

[mindgy]

I did all the steps from the beginning with no success whatsoever. I did all the re-wiring, and the proper connections, I even changed the LCD and nothing... I have no more ideias

[telamon]

@mindgy Oh so you've having the same issues with genuine drivers?? Now that's interesting!!!
Ok, CFG4 bridged to GND and CFG5 bridged to VIO was recommended because that's the default configuration for genuine watterot stepper-boards from what i can see by cross-referencing the schematics. Not quite sure what they do but i'm excluding those two as error-factors for now.

I've checked all the connections I've soldered myself but I can't find anything wrong with it. if we're having the same issues i can only assume that your connections are probably correct as well.
I started reading the datasheet but ran out of tinker-time today. to be continued...
Would be cool to know if anyone else here is having similar issues and how/if they fixed it.
I'm runing on 12v btw, not sure if that's an issue, @mindgy , @teemuatlut are you guys running on 12 or 24 volts?

[teemuatlut]

12V.
A few things you can try; run the drivers outside of Marlin to rule that out or try the v2.0 branch on AVR. You can also try the software SPI, which while not merged yet, is available on my fork.
I'll also try to get some additional debugging capabilities to handle these situations and to get more information.

The CFG5 and CFG4 lines are configuration options for SPI driven mode. Not to be confused with the typical SPI configured mode but a mode when you through SPI actually tell the driver the specific coil currents to use.

[mindgy]

Just to be sure, which jumpers should be plugged in? I did the experiment with no jumpers, just like in Thomas video. But now i tried to plug in them all in X driver, and with that i have 2x distance instead of 4x

[telamon]

Wait what? I thought that the pins that connected to the jumpers were the ones that are used for SPI-communication. E.g. they should become unconnected when sck,mosi,miso,cs pins are soldered to the topside. I don't even have jumpers on my rumba board but micro switches...

[mindgy]

As far I can tell the problem is not from the jumpers, I tried diferent configurations, and got the same results. Neverthess the distance reduced from 4x to 2x, but I think it was a random change, like in the past.

[mindgy]

@teemuatlut about your sugestions, I don't know how to do them :/ sorry for not be very helpful.
Is there a possiblity that I messed with something in the marlin code? I'm using vanilla version 1.1.8 with my configs. Can someone share a marlin code that is working allright?

[telamon]

@mindgy that's really interesting, I've plugged my driver in and out a few times but have never experienced any change in behaviour. I'm gonna follow @teemuatlut 's suggestion as soon as i find some time for it, and see how the steppers behave without marlin.
Basically if you have time/energy you can just download the Arduino IDE and then install the tmc2130 library from the library manager and try to run a few of the TMC2130-examples, you'll probably have to update the pin-numbers in the example sketches to match your configuration. But uh make sure to unhinge your belts or couplers to let your motors spin freely because when you run without marlin there is no logic to tell the motors to stop when an endstop is triggered. Other than that it should be pretty safe to run plain arduino sketches on your printer, but keep a watchful eye on your heater leds, I've already accidentally heated up my hotend once while searching for the right pin-number to put chip-select on. xD

[telamon]

Alright I've just had my own share of wierdness, @mindgy there's definitively something to that's ghosting through power-cycling.
Attempt 1: Ran the following Sketch ,in soft-spi mode, driver moves really slow (rotates around 30deg/2sek) and refuses to change direction but completley silent.
Attempt 2: Same sketch with hard-spi enabled, motor moves jerkily making lots of noise, triggers OverTemperature.

--- powercycled the whole printer, removed and disconnected tmc2130 stepper, reinserted/reconnected --

Attempt 3: SoftSPI mode, stepper moves much faster makes a whole revolution then CHANGES DIRECTION! :O It's still noiseless.

Attempt 4: HardSPI, stepper moves even faster, minimal noise (@teemuatlut I suspect that the sketch just runs faster with hardware-spi?) , direction is working.

Attempt 5: HardSPI; Set microsteps to 8 instead of 16, stepper runs at twice the speed but jerkily and makes same loud grinding noise that marlin did. direction is working.

Not quite sure what to make of these results.. I need to come up with better tests, any suggestions?
I suspect that the direction problems in my first test could be caused by artifact-registers left-over by marlin before i did a complete power-cycle. Anyways it's good to see that I've had the motor spinning for about 20 minutes and the stepper is barely hot and no OT triggered, maybe the problem lies in the software domain afterall..

[telamon]

Ok. I've solved the issue.. It was simplier than expected as always.
I had my Chip-selects swapped, when i translated the ATmega Pin-names to arduino numbers i missed that PC6 = 31, and PC7 = 30. So i had them swapped around, meaning that the library and marlin was doing what they were supposed to just that half of the communication went to the wrong driver.
Which means that whenever marlin tried moving the X-axis , SPI-configuration and communication went to my Y-driver but the step-signal got sent to the X-driver and the inverted problem occured when marlin tried moving the Y-axis ofcourse.

Basically, if you're experiencing wierd step issues, triple-check your chip-select pins to make sure that they're mapped to the correct driver. I'm not sure if it's possible to write some code to detect this case.
Thanks for all the help, I have yet to try out the hybrid-stepping mode, but regular stealthchop now steps like it should.

[fabriciomoeller]

Telemon,

Could you send a picture of the layout of your Rumba?

[telamon]

@fabriciomoeller
My actual rumba board is a complete mess of wires so I made you this picture instead.

I'm using a BIQU Rumba clone that matches the open-source specs found here
http://reprap.org/wiki/RUMBA
I used the schematic on that page to trace the EXP3 and ISP1 header, and then translated the pin-names into arduino pin-numbers using the following map:
https://www.arduino.cc/en/Hacking/PinMapping2560

I'm only using pins PC6,PC7 ( 31,30 ) to drive my X and Y axi. But if you wanna drive your Z-axis and Extruder then you should be able to use the two arduino 14,15 as well.

I added theese rows to the bottom of my pins_RUMBA.h:

//
// Trinamic 2130 ChipSelect pin definitions
//
#define X_CS_PIN  31 // Arduino pin 31 = Mega PC6/A14
#define Y_CS_PIN  30 // Arduino pin 30 = Mega PC7/A15

If you're using hardware SPI (the default mode) then you don't need to specify anything special, it should be enough to just happily connect the TMC2130 SPI wires in parallel to the ISP1 header pins illustrated by the picture.

Also as I mentioned earlier, if you're using the FYSTEC TMC2130 cheapo drivers you'll also have modify a few solder bridges per instruction in this thread: https://github.com/MarlinFirmware/Marlin/issues/8480

[fabriciomoeller]

Thanks @telamon

[Hywelmartin]

I had a similar problem, but it only occurred in spread cycle on my E0 stepper twice as much filament....
Now I run in stealth mode and everything works. except current control.
FYSETC tmc2130 v1.0 resoldered
adding my own notes, but the configs are not totally according to the document, adding config files as well...
edit:there is a v 1.1 of the aliexpress drivers https://www.aliexpress.com/item/2X-MKS-TMC2130-V1-1-Stepstick-Stepper-Motor-Driver-SPI-with-Heat-Sink-Ultra-silent-Excellent/32850746257.html

marlin_1.1.8.zip

tmc2130 on Anycubic kossel trigorilla.pdf

[teemuatlut]

Those involved, please try the latest bugfix-1.1.x or bugfix-2.0.x branch to test if the recent fix works.

[RogueBolo]

Hey all, I just installed my genuine tmc2130s on my x and y axis using tom's guide and a helper guide ( https://www.youtube.com/watch?v=i08tvVQqX64&feature=youtu.be ) that had me change some pins around. I'm running a ramps 1.4 board and marlin 1.1.8
Without stealthchop, my drivers move 4x the distance input by either a print or via command, and with stealchop enabled it moves 2x the distance instead. I'm just setting the steps lower for now, but I'm curious as to what it could be. Do you guys have any thoughts?

[thinkyhead]

@RogueBolo — It might be a bug in 1.1.8.

Please test with the latest bugfix-1.1.x (and/or bugfix-2.0.x) branch to see if we fixed this issue. If the problem hasn't been solved and you still see the bad behavior we should investigate further.

[PhthorF2]

Hey,

I registered at github, just to say thank you! I also had the problem with incorrect steps/s and insanely noisy stepppers, which overheated, after introducing several new features like setting the drivers from standalone to spi mode with sensorless homing, hybrid mode etc, and updating to Marlin 1.1.8. The update to bugfix-1.1.x (and switching the z and z2 endstop plugs to the correct positions) solved all problems! Again, thank you. Finally I can use my printer again after two weeks of maintenance.

[thinkyhead]

@PhthorF2 — Good to hear. The next release is imminent and definitely more bug-free than 1.1.8.

[RogueBolo]

After finally getting around to updating to the bugfix as of today, the printer is still having the same problem as commented earlier. Otherwise, it seems to be operating normally.

[thinkyhead]

That's pretty strange. If the stepper drivers had digital micro-stepping I would think it was related to a short between some pins. But when it affects all steppers then a short seems less likely. In any case, the stealthchop stuff sets new state on the stepper drivers but it doesn't change any states within Marlin itself. So it's not as though Marlin "knows" that stealthchop is active and is changing its behavior. It seems more likely that something is strange or mis-wired about the drivers.

@teemuatlut — Have you ever seen this behavior?

[archi]

I was reluctant to reply, but I suppose something like that to be a possible cause. I am on a 1.1.8-based fork (without any SPI/TMC2130 related patches) and didn't see any Marlin-related issues with my watterott-made TMC2130. That's not to say 1.1.x or bugfix-1.1.x are 100% bug-free (1.1.x is definitely not, see this thread), but maybe taking a second look or testing from scratch are worthwhile. Watterott has a TMC2130 arduino test sketch (disconnect belts, pulleys,...!), maybe try that one to rule out any hardware errors?

The only problems I hit:

• Mixed up CS for E0 and Z due to wrong label on the PCB (no problem at first since I used x32 microstepping and 800mA for all drivers; only realized this when I reduced E0 microstepping)
• Driver either DOA or got killed while soldering the pin headers; maybe one of yours is faulty?
• ICs prone to overheating (800mA, only passive with heat sinks; moving the board out of the kossel heatbed "chamber" and adding a silent PC 80mm fan solved this for me)
• Pin assigned to CS and something else
• Wrong settings due to EEPROM overriding what I set in the configuration files

Also, some of my dirt cheap chinese jumper cables and breadboards are of really poor quality and caused random errors in the past (bad contacts; poor soldering/crimping in the jumper cables). This would probably not be a consistent error source, but maybe worth to double check?

[teemuatlut]

@RogueBolo Did you power cycle the board after updating?
I will also after v1.1.9 release make a verbose debugging option that lets us see the raw register values that should let us better debug these situations.

[RogueBolo]

@teemuatlut I did, yes. I should also mention that stealthchop doesn't appear to be working; the drivers are as loud or worse than my drv8825s. After a reflash from the 1.1.x bugfix to a clean 1.1.8 download, there are no visible changes.
I should amend this a little bit: my problem is now only with the noise of stealthchop, as there is no difference in noise between having it enabled or disabled, and changing between them does not make a difference in steps/mm. Apparently, I originally had my microstepping configured incorrectly, which accounts for the original stealthchop distances being double what they should be.

[Brandvik]

Hi, I encountered the same issue with TMC2130 and I think the root cause is in the firmware, not in the driver.
My setup:

• Core XY,
• five fystech TMC2130 XYZE0E1, microsteps = 16,
• driver control by SPI bus,
• #define STEALTHCHOP,
• #define SENSORLESS_HOMING,
• this option is disabled -> //#define HYBRID_THRESHOLD

First time, I had set everything as described in the spec. The result was successful, printing was correct.
Then, once I rebooted the printer after a glitch during printing, the driver started moving 2 times as much as instructed on X and Y axis (no issue with Z, E0, E1).
I tried to fix the problem in different ways, none of them helped:
1) checked the firmware settings and overrode it - no luck,
2) cleaned EEPROM - nothing,
3) checked all physical wire contacts - no change, although all contacts were OK.
In order to exclude the driver problem as a root cause, I ran the following experiment: with my axies X, Y, E0, E1 having the same settings for steps/mm, I swapped SPI connectors on X and E1 axies. After that, I tried to move the axis, then my E1 axis moved 2 times as much as instructed while X suddenly moved correctly 1 time. My conclusion is that the issue is that the microsteps rate setting is being corrupted by the firmware.
Is there anything that could be done here or the new firmware version should address it?

[teemuatlut]

Try bugfix-1.1.x and powercycle the printer after uploading.

[AnHardt]

@teemuatlut
Do you know how well/bad the TMCs react on starting with 'double steps' ?
I remember disasters when i tried to use z-zerk above 0.4 with M5 lead screws and 'normal' drivers.

[teemuatlut]

Staring = Starting?

I haven't tried anything myself but I wouldn't think it's a problem unless the maximum step pulse frequency is reached. The value is defined as 0.5 * f_clk where f_clk = 12.4MHz.
It's also possible that something is going on with changing modes or ramping up from I_hold.

[Core3dTech]

I'm getting stuck too.
Marlin 1.1.8
CoreXY
Waterott TMC2130
installed all 4 of them.

Had to reduce steps_per_unit by half for X,Y and Z but NOT E0??

when I try to print
G28 works fine
G29 goes to all the right places
Print itself goes all over the place (not quiet either)

SENDING:M122
        X   Y   Z   E0
Enabled     false   false   false   false
Set current 1000    1000    1000    800
RMS current 994 994 994 795
MAX current 1402    1402    1402    1121
Run current 17/31   17/31   17/31   25/31
Hold current    8/31    8/31    8/31    12/31
CS actual       8/31    8/31    8/31    12/31
PWM scale   1   1   1   1
vsense      0=.325  0=.325  0=.325  1=.18
stealthChop true    true    true    true
msteps      16  16  16  16
tstep       1048575 1048575 1048575 1048575
pwm
threshold       0   0   0   0
[mm/s]      -   -   -   -
OT prewarn  false   false   false   false
OT prewarn has
been triggered  false   false   false   false
off time        5   5   5   5
blank time  24  24  24  24
hysterisis
-end        2   2   2   2
-start      3   3   3   3
Stallguard thrs 0   0   0   0
DRVSTATUS   X   Y   Z   E0
stallguard
sg_result       0   0   0   0
fsactive
stst        X   X   X   X
olb
ola
s2gb
s2ga
otpw
ot
Driver registers:
    X = 0x80:08:00:00
    Y = 0x80:08:00:00
    Z = 0x80:08:00:00
    E0 = 0x80:0C:00:00

[teemuatlut]

Use the bugfix-1.1.x branch.

[Core3dTech]

Wow, that worked and what silence!! Thank you!

[Iamsadomaso]

Unfortunatelly latest bugfix didin't solved my problems.
Fysetc TMC2130 hooked up with SPI on MKS GEN L board with latest (downloaded today) bufix branch of Marlin.
Steppers were working fine in standalone mode, but now with SPI they are pretty loud while normal homing or manual movement, a bit less while printing, but significaly more than they should. Using hybridmode or stealthchop not affect they sound level. Also while printing Y axis is losing steps, and Z dimensions are to small on calibration cube. It's similar to cases abowe, but I can't crack it :/

[teemuatlut]

Follow the troubleshooting steps from here and report back your findings.

[sbcrumb]

@telamon should I be measuring 5volts on the MOSI pin on the Rumba I have the same board as you. I don't want to fry anything if I hook it up this way.

[PavLeMa]

Any news? Got myself few Fysetc TMC2130s, Arduino and RAMPS. Installed Marlin. On each driver re-soldered 4 pins to other side, opened big jumper pad and closed two small ones. Disconnected one stepper from my printer, hooked up new hardware. Stepper loudly jumps back and forth. Switched on drivers diagnostics, found out SPI works fine (if I disconnect wires firmware kills everything and I see it on display). Current change does not work - nothing changes. Found this thread... As @teemuatlut recommended did troubleshooting steps. Everything seems right, but stepper jumps even with "Simple" example from 2130 library, with all my 5 drivers, so Marlin is not a cause. I'm going to read drivers datasheet and will try to exclude as much hardware and software as possible (RAMPS, library) from my setup.
Or should I just declare my TMC2130s DOA?

[telamon]

@sbcrumb that sounds about right. If I don't remember incorrectly all atmega based based have two power rails, one 5v for logic and one 12v+ for motion/heaters/fans. Spi pins are for logic so they should measure the maximum 5v for atmega boards, arm board usually run 3.3v logic.

[obor00]

I have same problem here, Z micro stepping does not work on my config (Z+Z2).
M122 show usteps = 16 for X Y Z and Z2.
usteps work fine on X and Y, but not on Z. I have to set 400 steps/mm to move the correct distance on Z.
It should be much more with leadscrew TR8x4...

[unixb0y]

@PavLeMa did you resolve the issue? My drivers do print fine and everything but they're louder than they should be and it doesn't seem to make a difference whether I enable stealthchop or not.

[PavLeMa]

No, I've assembled setup as simple as possible and decided my drivers do not react on configuration commands properly. Probably just counterfeit. Look like they can be configured with jumpers and not with SPI.

[unixb0y]

@PavLeMa thanks for your reply! I see. Which ones do you have? I have FYSETC. Next time will buy 2209 from Bigtreetech.

[PavLeMa]

@unixb0y Also Fysetc, from random chinese eBay seller. They were meant as direct replacement for simplest drivers, so I guess all "advanced" functions were bugged or just absent.

[unixb0y]

@PavLeMa okay. Yes mine were also configured in standalone mode (all pins facing down) so I changed 4 pins to face on top and removed a resistor on the bottom side to activate SPI mode. I mean, it works according to marlin. They’re just louder than they should be.

[lock[bot]]

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.