TMC2130 not working properly / only working sporadically

[Ordenkeim93499]

I know that i'am not at all in the right forum for this kind of stuff (i also dont know where the right place for this could be) but maybe someone can help me or it might could actually be a bug.

---

I'am having serious problems to get my TMC2130 Stepsticks from Watterott to work properly and i have no clue why. Sometimes all axis Home and travel as they should, sometimes only two are "working". After 2 or 3 mins into a Print one Driver just failed and started printing in the air.

It's not consistent at all, if i turn on the Printer one axis does not work and than i turn it off and on again and it works atleast for the above mentioned 2 -3 mins. But after that time it fails again.

I also don't get any compiling errors.

I tried Marlin 1.1.5, 1.1.7 and Marlin 1.1.8 but non of them worked right. Atleast with the TMC2130 It's just i'am at the end of what i know and what i can do, to maybe get it back working.

---

• The Sticks ar sitting in a Trigorilla Board with which i had no Problems in the Past.

I Wired them so that

• SCK (red)
• SDI (grey)

• SDO (green)

  are all for themselve in paralell and only the CS (blue) are getting one Pin per Stick.

I put the SCK in SCK on to the ISP header on the board. The SDI into MISO and SDO into MOSI. I also switched the MOSI and MISO pin but than non of them worked so it is probably right. I put the CS pins on D42, D43, D21, and D20 and assigned them in the RAMPS.h.

• The Sticks as such

I hope someone knows whats up. Thanks in advance. I try to continue the search for problem aswell maybe i get a brainstorm :)

[teemuatlut]

Did the behavior start when you started using the drivers or when you updated the firmware?

If the drivers are first working properly but then start shutting down a bit later, it sounds like a thermal issue. Maybe your drivers are running too hot and they're shutting down to prevent any damage. What are your driver current settings? Try adding a fan for the drivers and see if that makes a difference.

You didn't post your config files so what are your enabled TMC related settings?

[Ordenkeim93499]

Well i got the drivers and at the same time I updated the firmware but I actually tried it with the old A4988 and Marlin 1.1.8 and it worked. So i would say that either something is wrong with the drivers or my firmware settings or my cabling :)

With the thermal protection that is actually a good point but sometimes they even don't work than they are cool. I shutted my printer off for half an hour and the drives were cool (room temperature) and than i switched it on and well the same problem occurred two axis have been running one was "dead". That is actually the problem i just can't find any sort of a pattern that i can reproduce and see the same effect, it's always random. The driver current was set to 500mA (for testing purpose cause i wanted to try everything) in the firmware and i remember that one driver reported 800mA RMS than i put in M122.

I actually have a question as for the current is it actually normal that the sticks get fairly hot even only after homing the axis and jogging them back down again 100mm?

I also thought about that something might be wrong the ISP header? Do you know if it's possible to get the SCK, SDI and SDO from the LCD/SD headers? Or kinda like a software SPI which i can assign custom PIN's to?

Config.zip

I really hope that I can get it back working again it's super frustrating

[teemuatlut]

It wouldn't be surprising for the driver to heat up quickly once it is in use as the mass of the driver and the board is quite minimal. More important would be the temperature it settles to.

Your problem actually sounds a bit similar to what I had and what I was never able to track down. One of my drivers would detect a short to ground (for whatever reason) and accordingly shut down. This is the very reason that I made the STOP_ON_ERROR option. The Allegro drivers of course don't have a shutdown feature like this and would "work" alright. For me too the errors were seemingly random. As of now, there is no way to recover from a situation like this because we lose all the steps while the driver is shut down. Perhaps this can be done after we get skipped step recovery (Prusa style) implemented.

You can try running M122 once you see one of the axis stopping, or turn have STOP_ON_ERROR do it automatically for you. The former might be easier as having it automatically you'll just see the printer suddenly stop and give you the error message on serial. Also if you could let me know if the axis is question is always the same and if it's turned off (you can turn it by hand when you shouldn't be able to) after the error? Does the stopping axis follow the driver if you switch two of them?

I very much doubt a software problem or a communication problem. If you have MONITOR_DRIVER_STATUS disabled, Marlin will not talk to the drivers after the initial boot up (redone on M80). And since you can drive the steppers and have a sensible debugging message we can rule out a communication problem. This leaves us with a hardware issue.

[Ordenkeim93499]

Well first of all thank you very much for your answer this is probably gonna help me alot. I try to turn on STOP_ON_ERROR i hope it works cause than i first uploaded the new firmware, where i got the Step Sticks freshly unboxed, the Display showed Driver Error Please Reset. I really hope it's not a hardware issue cause i already talked to Watterott and well they said that they check all drivers before shipment.... -_-

[teemuatlut]

It may not be the the driver board itself but the connection from it to the motor. Or perhaps the motor itself, or the cables. I'd suggest shuffling components to try and isolate the faulty bit. And check the M122 output when you see the error and the printer is still running. I'd still recommend the manual way and disable STOP_ON_ERROR. That's mostly meant to abort the print so you don't waste plastic for a flawed print.

[revilor]

What kind of Marlin are you using? I can't find a board with id 4 corresponding with

define MOTHERBOARD 4

in your Configuration.h

[Ordenkeim93499]

@_revilor yes this was actually a fail from my side the Firmware was freshly configured and not tested after i uploaded it her I already fixed it it should be 44. It was just because i had so many versions i somehow lost the track of some things :/

• So I found some new things: I tried to connect the SCK, SDI and SDO Pins from the TMC2130 in paralell to those of the LCD/SD panel well it did not work so atleast that was sorted out. I put them back onto the ISP header and the same thing only two motor are working.

• But I found out some other fairly interresting thing: on Marlin 1.1.5 with TMC2130 disabled the SD Card slot is working fine. On Marlin 1.1.8 with TMC2130 enabled it knows that a SD Card is inserted but in the menus it shows No SD Card maybe some collision on the SPI bus?

@_teemuatlut well you might have been right with the hardware issue it's always the x axis thats noch working how it shoud be. I also discovered that if all StepSticks are inserted and I switch on my PSU it squeals a bit (very high frequency) and after a while the X Stick starts to get warm even without doing something. I removed it from the board and well no squealing anymore. I will test the overall current draw from it tomorrow and also look for shorts on the board maybe that will be the solution. For now i'am more than enough annoyed from my Printer :)

[revilor]

From your photo it looks like 2 of the CS wires are connected to UART3 of the Trigorilla board, which according to this document https://cdn.thingiverse.com/assets/b9/c7/f3/06/35/Trigorilla_details.pdf are pins D15 and D14. Pins D20 and D21 would be the I2C connector's SDA and SCL

[Ordenkeim93499]

revilor holy s.... awesome on what little details youre looking but I actually have to disappoint you the Pic was from my old configuration. I probably tried 5 different pin configurations over the day so yeah the config that i posted was younger than the picture :)

[SpeedGP]

You're not the only one having these kind of issues. I'm super happy these guys have been available this holiday season to help us out :)

If in doubt, re-crimp. It looks like your SPI interface is in series, you may want to try a breadboard or soldering them all into parallel. I'm always having issues with one bad crimp here or there... Good luck!

[revilor]

@Ordenkeim93499 well, I like to solve puzzles of any kind, but wrong configuration, wrong photo, I guess I'm out of this one ...

[Ordenkeim93499]

@SpeedGP well i already checkt the continuity of all cables and all of them were OK. Here is how i connected them: (i'am not the best in paint) red=SCK green=SDO grey=SDI blue=CS Also is it right that on the ISP header MISO corresponds to SDO and MOSI to SDI ?

[Ordenkeim93499]

I have a update about the status of my Printer and it's not good looking i think: I switched the X Y and Z Drivers to my old A4988 so only the extruder would be running by the TMC2130, I wanted to test each TMC driver separately for it's function but as i wanted to extrude something the motor just vibrated. (the Hotend was of course preheated to 200C°) . I plug in a diffrent TMC2130 Driver but the same result. After that i opened Pronterface to run an M122 command but I saw something interesting the current got decreased by 50mA about every half a second. So atleast the Monitor_Driver_Status worked.

#define MONITOR_DRIVER_STATUS

  #if ENABLED(MONITOR_DRIVER_STATUS)
    #define CURRENT_STEP_DOWN     50  // [mA]
    #define REPORT_CURRENT_CHANGE
    //#define STOP_ON_ERROR
  #endif

The only Problem was the Printer hasn't done anything to this point not even homing. I think that pictures say more than 1000 words:

• Pronterface console output

I went on for a bit so I disconnected it from power and saw that it is a overtemperature warning cause of the ridiculous high mA setting but i only set it to 800mA in Marlin. Maybe something is wrong the SPI connection. I just can't to believe that all 4 of the Drivers are F@€**# Did i really do anything right with the wiring?

[teemuatlut]

That's a communication error. See the driver register value reported as 0xFFFFFFFF. Check your wiring and configured pins.

I'd recommend to always do debugging through a console. LCD is very limited.

[Ordenkeim93499]

@teemuatlut OK i will look over it or even make a new wiring harness for them. But my wiring schematics are fine right?

• CS from each TMC2130 on a separate I/O Pin
• SCK from all 4 in parallel onto the ISP SCK header
• SDO from all 4 in parallel onto the ISP MISO header
• SDI from all 4 in parallel onto the ISP MOSI header

i just want to get this finally right so i don't have to annoy you anymore :/

[marcio-ao]

@teemuatlut: I am chiming in because you wrote the following:

Your problem actually sounds a bit similar to what I had and what I was never able to track down. One of my drivers would detect a short to ground (for whatever reason) and accordingly shut down.

We were seeing this problem on our Z axis. In our case, we had two Z motors wired in parallel on a single Trinamic driver. What solved the problem for us was to wire them in series instead (i.e, one coil of one motor wired in series with the coil from the other). So you if you have a similar arrangement, you may want to try that trick.

[teemuatlut]

It was the Z axis in my case too so that might very well be the cause. I remember I switched the RAMPS board and that fixed it but I may have also switched to dual Z driver setup at the same time which would also fix a problem like that.

[teemuatlut]

@Ordenkeim93499 If your wiring would be wrong, you wouldn't be able to move the axis at all. The drivers require at least one successful (write) communication to configure one particular setting for the driver to work at all. Your SDO -> MISO wiring can be bad and the driver could still work.

[Ordenkeim93499]

@teemuatlut
I wired up some crude harness for the drivers but apparently it works better than my "clean" one

My Delta homes now all axis via Pronterface only one axis does the double bump faster than the other two but i think thats for now irrelevant. So the communication between the board and the drivers should work right? Well if I send M122 I get the following even than the drivers are enabled and i've also turned on StealthChop in Marlin

And M911, M912 and M906 seem to be working too.

EDIT: I just uploaded Marlin with the SD_SUPPORT Disabled cause i thought maybe there is a issue with the SPI but still the same problem...

[Ordenkeim93499]

I can't get them to work don't know whats wrong with them. I got my delta to print a 20x20x10 test cube but after the 3rd or 4th layer the head just moved into the complete wrong direction and into the bed -_- The SD card also only init. if I only had 3 of the drivers in the board after i put in the 4th one in it no longer works. Pronterface also puts out weird things if i have all 4 plugged in no messages. If I change the firmware to only have TMC2130 on XYZ and pull out the 4th one on the board i get constantly current decreased messages.

[SpeedGP]

Stupid question, are the heatsinks shorting any pins out? Have you checked all the solder joints on the drivers? Are you sure none of the digital pins aren't being used and / or they are configured and enabled correctly in software? Just trying to cover all the bases. Did you crimp all the cables yourself, or are they premade ones? (I've never had good luck with the premade ones)

[Ordenkeim93499]

No heatsink is not shorting out anything. I also checked the solder joints and also they are fine. Pins have not been used by anything else checked it with M43 and also, i dont know how often i checked this XD, they are correctly assigned in the firmware. I also crimped the cables myself, twice actually on the second set of cables I even soldered them and checked every lead with a multimeter all of them have a lower resistance than 0.01Ohm. The problem is that they are not, not working at all they do work i can home the axis and jogg them around but as soon as I start a print the head goes wild after the 3rd or 4th layer. I even checked the gcode and let it run on my old A4988 drivers and this print completed without an issue at all.

[SpeedGP]

Part of my issue before was the drivers went crazy after my parts cooling fan came on, I had to enable fan_soft_pwm

-James--

On Thu, Jan 4, 2018 at 12:03 PM, Ordenkeim93499 notifications@github.com wrote:

No heatsink is not shorting out anything. I also checked the solder joints and also they are fine. Pins have not been used by anything else checked it with M43 and also, i dont know how often i checked this XD, they are correctly assigned in the firmware. I also crimped the cables myself, twice actually on the second set of cables I even soldered them and checked every lead with a multimeter all of them have a lower resistance than 0.01Ohm. The problem is that they are not, not working at all they do work i can home the axis and jogg them around but as soon as I start a print the head goes wild after the 3rd or 4th layer. I even checked the gcode and let it run on my old A4988 drivers and this print completed without an issue at all.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/MarlinFirmware/Marlin/issues/9012#issuecomment-355384456, or mute the thread https://github.com/notifications/unsubscribe-auth/ALPvIDY9rUbGmu-tiA_UEtZB9aNWTrPbks5tHS6mgaJpZM4RQulC .

[Ordenkeim93499]

Well thats also a possibility that i haven't checked out yet I will try it immediately.

But there is also another Bug/Glitch/Error if SD_Support is enabled my SD_card only shows up in the menu if I disconnect the extruder Driver from the motherboard. That could mean that this driver is bad or something but if I print directly from cura and I plugged in the Extruder Driver back into the motherboard, the driver drives the extruder just fine or at least fine to that point where the head begins to move randomly.

[SpeedGP]

I didn't understand that last part at all.

I believe I was having an SD issue also, where the SD card wouldn't read, then when I finally got it to display, I started a print and it un-mounted the SD card and stopped the print about 10 mins in. I didn't follow up with that issue at all. I just started printing from my computer directly.

-James--

On Thu, Jan 4, 2018 at 12:13 PM, Ordenkeim93499 notifications@github.com wrote:

Well thats also a possibility that i haven't checked out yet I will try it immediately. But there is also another Bug/Glitch/Error than if SD_Support is enabled my SD_card only shows up in the menu than i disconnect the extruder Driver from the motherboard but if i print directly from cura the driver drives the extruder just fine or at least fine to that point where the head begins to move randomly

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/MarlinFirmware/Marlin/issues/9012#issuecomment-355386658, or mute the thread https://github.com/notifications/unsubscribe-auth/ALPvIHEnaBFqAyKV4gGrh0JW1s9c2G71ks5tHTDrgaJpZM4RQulC .

[Ordenkeim93499]

I have to admit that my last comment, after reading it again is not the clearest one I wrote. I will fix it XD

[ikarisan]

Do you get any "Driver error. Please reset!" messages? That what I got the last two days. I am using twei TMC2130 on my X and Y axis. First everything seemed to work fine. But suddenly Marlin reported a "Driver error". And now, everytime I power up the printer it runs into this message. On the Z axis the same driver works for only +10mm, then this axis reports a driver error, too. After replacing the TMC2130 with A4988 the printer works well.

The error message from Marlin is:

X driver error detected: overtemperature short to ground (coil A) short to ground (coil B) Error:Printer halted. kill() called!

But these messages are all not true....

[teemuatlut]

If Marlin reports all those errors it means there's a communication error and the status response was 0xFFFFFFFF, which normally would never be the case. I didn't expect there to be this many communication errors when I was writing that but I will be adding it in. I just don't know if we're doing any more 1.1.x releases before 2.0.x.

[SpeedGP]

I'm wondering if the soft pwm fan fixed the other guy's issue too. That one is a doozy

On Jan 5, 2018 3:42 PM, "teemuatlut" notifications@github.com wrote:

If Marlin reports all those errors it means there's a communication error and the status response was 0xFFFFFFFF, which normally would never be the case. I didn't expect there to be this many communication errors when I was writing that but I will be adding it in. I just don't know if we're doing any more 1.1.x releases before 2.0.x.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/MarlinFirmware/Marlin/issues/9012#issuecomment-355695304, or mute the thread https://github.com/notifications/unsubscribe-auth/ALPvIHHmDW6J1g0tiA88F7g6xIR7ThN9ks5tHrNygaJpZM4RQulC .

[ikarisan]

Maybe it has nothing to do with this problem, but on this site someone has a simmilar problem. He solved it by using pin D4 for CS. I am using pin D40 and D42 for my X/Y drivers.

If I find the time I will test it with D4, D5 and/or monitor the pins with M34.

@Ordenkeim93499 Can you try it with the digital input pins D1, D4, D5 and D6?

[Ordenkeim93499]

Well I have already tried this out, all my TMC2130 CS pins are on Servo Pins but that didnt changed anything. I came to the following conclusion.

So far 1 Driver is smoked because it gets fairly warm only if I turn on the power and do nothing with it. The other 3 Drivers are probably also bad but not that cooked like the 1st that gets warm. There is a SPI communication problem cause everytime I get that the OT protection is triggered although the Drivers are not even enabled. The second thing is that I also only get an empty Drive register back like 0xFF:FF:FF:FF.

I wrote with Watterott and the said the following. It's apparently super Critical that the TMC2130 get the VM voltage before the VIO voltage cause otherwise it's probably getting cooked. I didn't know that or atleast I thought that it would be OK if the VM and the VIO get switched on simultaneously but no that's not the Case. The answer for that problem is to connect a Schottky Diode between VM and VIO.

• VM = Cathode
• VIO = Anode and the Diode should be (1A 60V)

I would be currious how some of the TMC2130 user have solved that? In the FAQ from Watterott it's not mentioned that you can use a Schottky Diode neither the Video from Tom's3D but i don't want to blame him.

The next thing is that you also should always use Freewheeling diodes with the TMC2130 Driver's and that is apparently also the cause why some of my drivers are gone bad because I pult the cord, as my Printhead moved towards the Heatbed when those errors occured. Should I have let my Printhead crash into the bed and maybe even let itself destroy, just because Marlin doesnt take any G-Code commands in this moment and the Drivers are too sensitive to those maybe occurring inductive spikes? I don't know.

I'am sry that I might sound a bit grumpy but that is what i'am actually are right now, 1st cause I destroyed one of my Drivers completely beyond repair.

2nd Because 50€ just went out of the window for well a scratched Heatbed and yeah well Nothing.

and 3rd because you actually don't get any Disclaimer about something important like those Schottky diodes or the Freewheeling diodes.

Not every Body is a Electronical Engineer and knows that much stuff about that topic. I wouldnt have actually came up with this Schottky diodes I probably would have soldered something way more complicated together.

Please tell me if you would make so much research befor you get a new StepStick that is specifically made for 3D-Printers.

Please take this things as an experience that you don't have to throw out 50€ yourself as well.

What also makes me curious if those Users that are running TMC2130 Drivers are using those Schottky Diodes and Freewheeling diodes as well? If yes how did you know about this?

What I'am actually also a bit disappointed about is that Watterott did not even ask if I could maybe send them the 4 faulty ones so that they could check it so I could get a definitely answer what is wrong with them. I'am actually still sitting infront of unfinished suspicions. I don't know if it was really the Schottky diodes missing or if the 3 other Drives could still work if I would change out just a blown resistor or if the Drives have already been faulty after I recieved them. Writing that Watterott does a 100% ECheck before shipment or really doing a 100% check is a big difference for me and if I can really trust them is the next thing.

Thanks to all of them who participated in this Issue and helped me or tried to help me. You're a great Community

[teemuatlut]

Could you do a summary of your current status? Try the Simple example provided by the library before you start throwing anything away. Start with a single driver connected. I also took a closer look at your schematic-done-with-paint and if the wires going from the drivers are in the order your draw, then your SDO and CS are wrong way around.

Standard RAMPS does not allow us to control the power up order as VMOT is straight from 12V and VIO from VCC. I don't think anyone is using additional diodes.

[Ordenkeim93499]

My current Status is the following: 1 Driver heats up even without doing anything so it is probably completely dead. If I connect that driver to my Board and cable harnes it also throws the SPI bus completely over board in that state my Board doesnt even recognize my SD card. If I disconnect it my SD Card works fine

The other 3 Driver work sometimes and sometimes not, if I send M122 I always get back an empty driver register with 0xFF:FF:FF:FF. Which should according to this page https://www.reddit.com/r/3Dprinting/comments/7mhuj4/tmc2130_short_to_ground/ not happen.

Sometimes there is also an ridiculous high running current set like 43 Amps which Marlin immediately starts reducing and says that the OT Prevention got triggered although the Driver hasn't even started to move the motor. The next thing is if I enable the STOP_ON_ERROR in MONITOR_DRIVER_STATUS I can't even start Marlin cause every time it says Driver Error on the LCD regardless of what I do.

The schematic was just a quick sketch to just give an idea how I wired it. I didnt connect the SDO and CS wrong way around You can also see this on the first Picture I uploaded Grey is SDI Red is SCK Blue is CS and Green is SDO

Standard RAMPS does not allow us to control the power up order as VMOT is straight from 12V and VIO from VCC. I don't think anyone is using additional diodes

Thats the same thing as I thought and I can't really believe that this is or was the problem in my case

[SpeedGP]

Another stupid question,

Have you tried moving Driver1 and Driver3 to different spots on your board? Are you sure it's not the socket?

-James--

On Sun, Jan 7, 2018 at 2:42 AM, Ordenkeim93499 notifications@github.com wrote:

My current Status is the following: 1 Driver heats up even without doing anything so it is probably completely dead. If I connect that driver to my Board and cable harnes it also throws the SPI bus completely over board in that state my Board doesnt even recognize my SD card. If I disconnect it my SD Card works fine

The other 3 Driver work sometimes and sometimes not, if I send M122 I always get back an empty driver register with 0xFF:FF:FF:FF. Which should according to this page https://www.reddit.com/r/3Dprinting/comments/7mhuj4/ tmc2130_short_to_ground/ http://url not happen.

Sometimes there is also an ridiculous high running current set like 43 Amps which Marlin immediately starts reducing and says that the OT Prevention got triggered although the Driver hasn't even started to move the motor. The next thing is if I enable the STOP_ON_ERROR in MONITOR_DRIVER_STATUS I can't even start Marlin cause every time it says Driver Error on the LCD regardless of what I do.

The schematic was just a quick sketch to just give an idea how I wired it. I didnt connect the SDO and CS wrong way around You can also see this on the first Picture I uploaded Grey is SDI Red is SCK Blue is CS and Green is SDO

Standard RAMPS does not allow us to control the power up order as VMOT is straight from 12V and VIO from VCC. I don't think anyone is using additional diodes

Thats the same thing as I thought and I can't really believe that this is or was the problem in my case

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/MarlinFirmware/Marlin/issues/9012#issuecomment-355813464, or mute the thread https://github.com/notifications/unsubscribe-auth/ALPvID-OwQVL_rcbD7eYtVBt6g9TmGQBks5tIJ-XgaJpZM4RQulC .

[Ordenkeim93499]

Yeah I'am 100% sure that its not the Socket cause

1st: my old A4988 are running like a charm in it right now

2nd: I probably switched all drivers around like a bazillion times tried only 1 Driver than 2 and 3 but no changes at all.

3rd: I made 2 new crimped cable harness and I even made a 3rd soldered one but there were no changes aswell.

4th: I plugged the CS pins onto every and really every free and usable Pin on my board didnt changed anything.

I actually just stopped working on it cause there is nothing more that I can do about it. I switched back to my old A4988. I will call it a fairly expensive Experience :/ unfortunately.

[teemuatlut]

Did you try running the example sketch yet?

[Ordenkeim93499]

No thats actually something I didnt tried yet. I will try to do it tomorrow on my Nano

[SpeedGP]

Probably unrelated, but you could try completely disabling your LCD through firmware. Since it's on the same SPI bus, it could interfere?

-James--

On Sun, Jan 7, 2018 at 12:31 PM, Ordenkeim93499 notifications@github.com wrote:

No thats actually something I didnt tried yet. I will try to do it tomorrow on my Nano

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/MarlinFirmware/Marlin/issues/9012#issuecomment-355850332, or mute the thread https://github.com/notifications/unsubscribe-auth/ALPvICnHQOau4h0xnrWw96C6Pz1XiThnks5tISmygaJpZM4RQulC .

[SpeedGP]

Why did you close this? Any update?

[Ordenkeim93499]

@SpeedGP Sry I forgot to give you guys an Update. You're wright. Well the Drivers seem to be partially broken and I couldn't get them to work reliable. Marlin tries everytime to decrese the Current if MONITOR_DRIVER_STATUS is enabled. You probably already know all the errors that occured. :) For now I thought that I solder together the little jumper on the Bottom so theyre like "TMC2100" and give them a try if they might work this way. If not there is not much I can do about it. Thats it for now. Oh and I Closed this Issue cause I didn't want to bug you anymore with this problem. Thanks for all the Help. If my idea works with the Jumper I will tell you. :)

[Ordenkeim93499]

Hey guys, so today I soldered together the little Jumper on the underside of the PCB so that the Drivers behaves like a TMC2100. I let all conf. Pins open so it runs at StealthChop 16 Steps and interpolate to 256 Steps. And it worked. Atleast as good as with the SPI interface. 2-3 Mins into a print and loosing Steps.

So I wanted to test how hot the Driver gets. I put my NTC of the Heatbed onto a Driver Heatsink, and it got fairly warm when running about 90°C which is as far as I know below the max. working temperature of 150°C. So I think that the heat is not necessarly the problem and to fix the loosing Steps problem the solution could be to increase the current. Right? But wouldn't that cause more heat to be generated?
And couldn't that in turn cause the Driver to reach it's temperature Limit?

On what I want out is have you seen someone or know someone who is running TMC2100 passively cooled on StealthChop? With normal NEMA17 motors?

I dont want to blame anyone or anything I accepted it that I probably f..... this part up of my printer. I'am just currios if "Me" is just to dump to do it or that something could actually change if I would buy new Drivers. StealthChop is actually the only reason why I bought this Drivers. Do I have the wrong requirements motor wise or is it actually just a little problem of stealthChop? Or are my Drivers actually really trash and this the cause for my Step Loosing problem?

Well I'am excited for your answers.

[teemuatlut]

150C is the absolute maximum temperature (Junction temp) and should never ever reach anything near that high. 120C is the very maximum operational range and triggers the prewarn flag.

If we also take into account the temperature difference from the chip through the thermal vias and the heatsink compaund, into the heatsink itself and then finally into your likely a bit loose thermistor, you can be pretty sure that the actual temperature is higher than 90C.

[SpeedGP]

Have you tried to run them with an electronics cooling fan?

-James--

On Wed, Jan 10, 2018 at 10:35 AM, teemuatlut notifications@github.com wrote:

150C is the absolute maximum temperature (Junction temp) and should never ever reach anything near that high. 120C is the very maximum operational range and triggers the prewarn flag.

If we also take into account the temperature difference from the chip through the thermal vias and the heatsink compaund, into the heatsink itself and then finally into your likely a bit loose thermistor, you can be pretty sure that the actual temperature is higher than 90C.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/MarlinFirmware/Marlin/issues/9012#issuecomment-356694751, or mute the thread https://github.com/notifications/unsubscribe-auth/ALPvILDhNkrSskUi7lyVDr3rjuiVloyAks5tJQL1gaJpZM4RQulC .

[apprentice10]

Vi lascio questo forum russo nell'Esperanza che vi possa aiutare. usate il traduttore di google chrome. http://3dtoday.ru/blogs/tosikdelta/connection-tmc2130-in-trigorilla-boards-anycubic-kossel/

[ss89]

i had the same issue with drivers reporting 0x00:00:00:00 when power supply was off and 0xFF:FF:FF:FF when power supply was powered on. I had tried some of the stuff mentioned here, but what finally resolved my problem was switching from the current ramps board to a spare i had lying around. Obviously for cost reasons, i order my ramps boards from china for 3-4€ and these seem to have quality issues every now and then.

[Bob-the-Kuhn]

See Issue #10133 to see what others have done to get their systems working reliably.

With MONITOR_DRIVER_STATUS enable try moving the SPI cable wires around and see if that causes problems. Don't unplug anything, just move the wires.

[OperatorB]

Hello together,

I am using Marlin_bugfix_1.1.9 with MKS genL board and Aliexpress (Bigtreetech) TMC2130. SPI mode, STEALTHCHOP, MONITOR_DRIVER_STATUS is enabled. My printer halted after around 3 hours of printing. According to Octoprints log it was due to short to GND at E0 driver. Also the reported 'Set current' looks like an overflow. 'Set current' for E0 is 700 by Marlin.

Any idea what is the source of this issue?

Recv: E0 driver error detected: Recv: short to ground (coil B) Recv: X Y Z E0 Recv: Enabled true true true true Recv: Set current 700 700 700 65436 Recv: RMS current 673 673 673 1767 Recv: MAX current 949 949 949 2491 Recv: Run current 21/31 21/31 21/31 31/31 Recv: Hold current 6/31 6/31 6/31 15/31 Recv: CS actual 21/31 21/31 6/31 31/31 Recv: PWM scale 83 82 29 0 Recv: vsense 1=.18 1=.18 1=.18 0=.325 Recv: stealthChop true true true true Recv: msteps 16 16 16 16 Recv: tstep 65535 16154 1048575 72 Recv: pwm Recv: threshold 0 0 0 0 Recv: [mm/s] - - - - Recv: OT prewarn false false false false Recv: OT prewarn has Recv: been triggered false false false true Recv: off time 5 5 5 5 Recv: blank time 24 24 24 24 Recv: hysteresis Recv: -end 2 2 2 2 Recv: -start 3 3 3 3 Recv: Stallguard thrs 0 0 0 0 Recv: DRVSTATUS X Y Z E0 Recv: stallguard Recv: sg_result 0 0 0 0 Recv: fsactive Recv: stst X Recv: olb X Recv: ola X X X Recv: s2gb X Recv: s2ga Recv: otpw Recv: ot Recv: Driver registers: X = 0x00:15:00:00 Recv: Y = 0x20:15:00:00 Recv: Z = 0xE0:06:00:00 Recv: E0 = 0x30:1F:00:00 Recv: Recv: Recv: Error:Printer halted. kill() called!

[OperatorB]

Update: I disabled MONITOR_DRIVER_STATUS. After 2 prints(7 hours together) error did not occur.

[github-actions[bot]]

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