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.

[wuspy]

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\libraries\TMC2130Stepper\src\source\SW_SPI.cpp: In member function 'void SW_SPIClass::init()':

C:\Users\MinD\Documents\Arduino\libraries\TMC2130Stepper\src\source\SW_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\libraries\TMC2130Stepper\src\source\SW_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\libraries\TMC2130Stepper\src\source\SW_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.