MarlinFirmware / Marlin

Marlin is an optimized firmware for RepRap 3D printers based on the Arduino platform. Many commercial 3D printers come with Marlin installed. Check with your vendor if you need source code for your specific machine.
https://marlinfw.org
GNU General Public License v3.0
16.34k stars 19.26k forks source link

Marlin 1.1.9 - Linear Advance causes Trinamic TMC2208 motor drivers to shut off in StealthChop mode #11825

Closed adriaanb closed 6 years ago

adriaanb commented 6 years ago

Description

Enabling Linear Advance while using Trinamic TMC2208 stepper drivers on the extruders almost immediately causes the extruder to stop extruding - any K factor larger than 0 has some files failing immediately after priming the nozzle or somewhere in the first layer of the print due to the extruder motor shutting off.

My printer is a cartesian design based off of the Prusa i3 with dual extruders, both with a direct drive. Due to the ertruder assembly's significant mass, I have low Acceleration (600 mm/s²) and Jerk (10 mm/s) settings.

The error occurs both with the 1.1.x and the bugfix-1.1.x bugfix branches. I tried setting the hybrid threshhold for E0 and E1 to 0 as to see wether the problem would also occur in SpreadCycle mode as opposed to StealthChop, but doing so made no difference.

The slicer used is Cura 3.4.1

Steps to Reproduce

  1. Use TMC2208 configured with UART on Extruder
  2. Enable Linear Advance
  3. Print any file using a K factor greater than 0

Additional Information

I found bug reports for other firmwares while searching the web for a solution to the problem that suggested increasing jerk and/or decreasing the k factor as well as decreasing the motor current as a remedy, which did not affect my printer in a positive way. The most interesting one was the following:

https://github.com/KevinOConnor/klipper/issues/196 (or this post in particular)

My Configuration.h and Configuration_adv.h files

mathmac commented 6 years ago

I had the same issue i finally found that my set up doesn't like low values of k like 0.05

I tried finally decreasing k from 1 to 0.1 and found a sweet spot at 0.12

tmc2208 (no UART) and ramps 1.4

adriaanb commented 6 years ago

I created test files for testing all K factors between 0 and 2, in .01 increments (using lin advance 1.5) - it makes no difference, the extruder stops working almost immediately.

If testing with gcode generated for the K factor calibration pattern, it always prints the first slow line segment followed by the fast line segment, but no matter the K factor then fails when it comes to printing the second slow line segment at the end.

But out of curiosity - how did you tweak the behavior of your extruder to match a k factor of 0.12 as opposed to the one you determined for your settings & filament using the calibration pattern? All filaments I use require K factors between 0.06 and 0.08 depending on filament (I calibrated while my A4988 drivers were still in place), so printing with twice the K factor would result in rather distorted prints, no?

mathmac commented 6 years ago

I had the problem using the K patern becaause it starts with low values of K

so I abandonned the use of K pattern and printed calibration cube adjusting K directly before printing starting from "high " values intentionnaly I know it is a lot longer than k pattern but closer to real prints as I was focused on angles orthogonality

here are some examples at 40 mm/s no retraction from left to right : 0.3 - 0.15 - 0.1 - 0 (vase gcode for 0, old try for comparison) I only note angle aspect and start of layer aspect

0.3 has no matter on angles, 0.15 has a little round corners, 0.1 the swelling starts to appear then I did 0.12, but it depends on print speed, at 60 mm/s, 0.12 seems a little too high, 0.1 should be ok K is dependant of your setup extruder hotend nozzle... 0.12 for me, 0.08 for you sounds normal to me 896deb516d16880c0badd21d28da1b860c8eebd1

adriaanb commented 6 years ago

I tried to print several benchies within reasonable parameters for my printer in terms of K factors. All failed after priming the nozzle.

Do you run a bowden setup or how are you using K factors above 0.1? As stated in my initial post I am running a direct drive setup (with and e3d v6 hotend).

I also modified the g-code of the test pattern by hand, allowing me to reduce the K factor instead of increasing it with each incremental line to print - testing that way yielded the same results sadly :(

For now I will just have to disable linear advance it seems - possibly I'll order some TMC2130 drivers and see if the issue persists with those drivers. Would be interesting to find out if TMC2208 on X Y and Z and TMC2130 on E0 and E1 mix well...

adriaanb commented 6 years ago

In case others come along looking for a solution to this issue - as a solution for now I ended up using the drivers in legacy mode and setting them to SpreadCycle using the OTP (One Time Programmer). Unfortunately trying to set individual drivers to SpreadCycle via UART by endabling HybridThreshhold and setting the threshhold to 0 for the respective axes did not work.

Since setting this up viat the OTP may not be super straigtforward for some, this video may be of help.

Also, don't forget to solder in the pin headers for MS1 and MS2 to configure the microsteping mode in case only the pins necessary for running the drivers via UART were previously soldered in, heh.

I am still hoping there will be a better solution to this at some point, as it is quite nice to be able to monitor and tweak the drivers via gcode, but for now I hope this will help others :)

Sebastianv650 commented 6 years ago

As long as we don't know the reason for this problem, it's hard to fix it. My personal feeling is that there is quite a big amount of issues related to TMC drivers, which raises the question if this drivers are much more picky to settings than "normal" drivers. So, is it a LA problem or a driver problem?

When LA works at some K value but stops suddenly at some lower value, all that will be changed is the pulse frequency. But all frequencies could also happen during printing without LA and even if there would be an issue with odd timings (short double pulses for example), it should "only" lose a step and not stopping extrusion completely.

adriaanb commented 6 years ago

@Sebastianv650 based on my limited understanding of this post I referenced earlier, it seems plausible to me that it is a hardware/firmware issue with the chip. I am not sure to what extent changes in the Marlin firmware can compensate for this, but I would happily help in trying to identify which settings interfere with it/narrowing down the source of the error. For me, it does not work at all no matter the K value, for others it apparently does up until a certain point. I will start playing around with settings and seeing if I can get the printer to react (disabling various features, playing around axis steps per unit,... not sure what else would be worth a shot) as soon as I have the time to do so.

@thinkyhead I carried over the Linear Advance settings I used prior to installing the TMC2208s, it has all the fancy extrusion features disabled except for retraction itself. Once I get back home I will try to disable that and report back, thanks for the tip.

Sebastianv650 commented 6 years ago

@adriaanb your linked post might be the root cause indeed. LA can only work when it has some jerk speed to play with. That's an amount of speed where the extruder doesn't need an acceleration part. To prove that, try using the spreadCycle mode because as I understand it this problem should only exist in stealthChop mode. Using this on the extruder stepper only should be OK if thats possible.

adriaanb commented 6 years ago

@Sebastianv650 that is exactly the solution I have resorted to, so far it works well. I switched the drivers on my extruders to SpreadCycle using the One Time Programmable memory, as I could not find a solution to switch only individual drivers to SpreadCycle in Marlin. Enabling HybridThreshold and setting it to 0 for the extruders did not have the desired effect.

As the OTP is not that intuitive and requires users to make irreversible, potentially destructive changes to their drivers, a better solution might be a way to put individual drivers in different modes using the Marlin firmware without having to rely on the HybridThreshold mechanism. On the extruders SpreadCycle does not cause any noticeable increase in noise anyways and generally seems to be a more robust, less error-prone mode.

Sebastianv650 commented 6 years ago

Good to know, one important thing to keep in mind if we see issues with shifted layers and so on when there is a TMC in the system. As all movements can see jerk, a jerk-sensitive driver mode is realy not a good thing at all.

thinkyhead commented 6 years ago

I could not find a solution to switch only individual drivers to SpreadCycle in Marlin. Enabling HybridThreshold and setting it to 0 for the extruders did not have the desired effect.

@teemuatlut — Do we have a standard and supported method to switch one driver to SpreadCycle?

teemuatlut commented 6 years ago

Not yet but you can do with TMC_ADV. stepperE0.en_spreadCycle(true)

thinkyhead commented 6 years ago

@adriaanb — Looks like TMC_ADV can do what you want.

#define TMC_ADV() { stepperE0.en_spreadCycle(true); }
adriaanb commented 6 years ago

That is great news, thank you! I will reconnect the drivers and give this a whirl as soon as I get the chance!

Thesecky commented 6 years ago

I am going to change my driver to spreadcycle using the One Time Programmable memory. Does anyone have a reliable video of hot to handle the software to make the change.

adriaanb commented 6 years ago

@Thesecky I linked a comprehensive video description on how to do this in this post.

However, you might want to first give the method teemuatlut and thinkyhead mentionned above a try, as this will allow you to avoid making permanent, potentially destructive changes to your driver as well as monitor the drivers from Marlin.

I hope it helps.

Thesecky commented 6 years ago

I am using cliper so this unfortunatly isnt posible. Thanks for the video, will take a chance and use otp.

Maximuscr31 commented 6 years ago

Using Klipper you can program them using UART so it isn't permenant.

ModMike commented 6 years ago

Ok so I disabled Stealtchop on my TMC2224 extruder driver by installing a jumper on MS3. Not sure if this would work for everybody in stand alone mode, this was the procedure for my Azteeg X5 Mini Wifi.

I immediately heard a swish swish noise when I actuated the extruder, but it still refused to budge.

I then set:

#define MINIMUM_STEPPER_PULSE 2

and it prints. The weird swish swish noise is a little disconcerting but it's not stalling so looks good so far.

thinkyhead commented 6 years ago

@teemuatlut — What's the closest thing we have to TMC2224 in our stepper selections? Should we add TMC2224 as another option?

ModMike commented 6 years ago

@thinkyhead The TMC2208 "seems" identical save for the pinout.

https://www.trinamic.com/fileadmin/assets/Products/ICs_Documents/TMC220x_TMC222x_Datasheet.pdf

teemuatlut commented 6 years ago

TMC2208. You could make a new specialized template for it in tmc_util.h that just inherits the TMC2208 specialization and passes on every parameter given. Then add it as a supported option.

ModMike commented 6 years ago

So here is the conundrum:

I have 4X TMC2224 but turned off stealth chop on the extruder driver by installing a jumper on MS3. In order to get it working, I had to #define MINIMUM_STEPPER_PULSE 2.

If I understand correctly this will apply to all axis, will this cause any issues?

ModMike commented 6 years ago

FYI: I just found 1 difference between TMC2208 & TMC2224. On the TMC224 you can disable StealthChop by installing a jumper on MS3.

elektrinis commented 5 years ago

Just a confirmation that same issue persists in bugfix-2.0 2019-JAN. Also: extruder driver crashes with any value, even if K=0 (but LA enabled). Temporarily installed A4988 for extruder.

ML3D commented 5 years ago

I have TMC2208s on my Prusa p3Steel, running 8 bit RAMPS. I'm also using a bowden tube.

If I have default_ejerk set to 5.0, I can get it to print, but the extruder motor makes a horrible noise every time the print turns a corner. I know this has been reported elsewhere.

If I change the ejerk to 1.0, the extruder stops and the print never gets off the ground.

I have not been able to find any satisfactory setting using the TMC2208 with lin_advance in stealthchop mode, unfortunately. I think the TMC guy said that the noise comes from an abrupt voltage change?

Anyway, it's too bad that this problem exists. Hopefully someday there will be a solution.

FelixHauser commented 5 years ago

If I have to be honest, after finding myself helpless trying to use a 2208 on the extruder motor, I switched back to an Alegro 4489 and I haven't regretted it ever since. The extruder driver is, by far, the least problematic one. Once you tune in the current delivered to the motor and have a consistent extrusion without overheating or skipping steps, it isn't really noisy at all. So I have a couple of printers with 2130s on X and Y, 2208 on Z and 4489 on E... very happy with the setup.

ML3D commented 5 years ago

If I want to use lin_advance, I will have to go back to an 8825 driver. I will be going 32bit soon, so maybe then, if I'm using Marlin 2.0, I can use the 2208 in spread cycle mode.

Otherwise, without lin_advance, I'm quite happy with the 2208 on the extruder.

zemanemail commented 4 years ago

Just a confirmation that same issue persists in bugfix-2.0 2019-JAN. Also: extruder driver crashes with any value, even if K=0 (but LA enabled). Temporarily installed A4988 for extruder.

Replaced the extruder driver "unfliping" its connectors only? Thanks!

zemanemail commented 4 years ago

That is great news, thank you! I will reconnect the drivers and give this a whirl as soon as I get the chance!

So, did it work? I'm waiting for my tmc2208s and thinking about applying this to enable LA. Thanks!

github-actions[bot] commented 4 years ago

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.