[BUG] TMC2130 not tuned for Linear Advance

[govido]

Hi,

i'm desperatly trying to get my printer working with 32-bit hardware. I use a (heavily) modified Ramps 1.4 Board on top of an arduino due with TMC2130 for X,Y,Z and E0. The first time I used a marlin 2.0 version from june 3rd 2018. With this version everything was working fine, apart from very heavy steploss after the first printed layer. This resulted in the printhead smashing into the end of the x-axis and very noisy steppers. This wasn't a problem with the old 8-bit hardware I was using previously (Mega/Ramps/2130/Marlin2.0).

The problem I have with the latest builds (from yesterday and a few hours ago with added esp32 support): Everything seems to be working fine, the new options #define MINIMUM_STEPPER_PULSE 0

define MAXIMUM_STEPPER_RATE 400000 seem to kill the whining noise from the steppers.

But one thing I can't figure out after hours of testing is that the extruder motor won't move in the slightest... I deactivated extrusion prevention, even flashed a firmware without it. Nothing changes... I edited the pins file to swap the stepper drivers E0 with the X one. Nothing again The machine homes OK, starts printing but the extruder motor won't move. The motor is moving if I plug the X motor cable in the E0 motor and move the axis.

Is there any (new?!) option in Marlin that I am not aware of? The part that is puzzling to me is that the stepper driver was working in the version from a few weeks ago. The stepper driver is enabled (stepper is hard to turn by hand) and disabled if the power is off. Any ideas would be appreciated.

[thinkyhead]

Start with non-TMC2130 steppers and get everything working solidly. Only after that should you start working with TMC2130 drivers. This will help to ensure that you have everything configured and that TMC2130-specific issues aren't holding you back.

[govido]

I quickly tested a DRV8825 and A4988 driver. Both only get the motor to make horrible whining noise and 'click' one time and stop (if I test to extrude 5mm). All other 2130s are working as expected with driver status and sensorless homing. Even if I swap the driver placement in the pins configuration X, Y and Z always work... but the extruder won't turn a bit. I made another test where I swapped the stepper drivers Y and E0. I changed the pin file that the E0 marked stepper drives Y and the Y marked stepper drives E0. I changed the endstop wire on the diag pin accordingly and swapped the stepper cables. Following happens: The machine homes perfectly, I heat up the extruder to 200° and only hear a click, nothing happens. If I plug in the X or Y stepper cable and move the axis the extruder turns. So it should be a software related issue. (fyi i drive the x and y at 600rms and the extruder at 650rms, z at 700rms) All numbers work fine on a Mega 8bit board. As an IT guy I'm used to troubleshooting... but I have no clue what I need to search for next

[viper93458]

I had a similar issue with AVR and E0 using TMC2208 drivers and bugfix-2.x. I had to disable Stealthchop to make E0 move if LA is enabled. With LA disabled (K=0) then E0 would work, but with anything over K=0, the E0 motor would not move with stealth chop enabled. I don't know if this is similar to what is being experienced here or completely different in every way, but I wanted to throw it out in case it leads someone in the right direction.

Perhaps it may be something for the OP to test and see if something similar happens.

-William

[thinkyhead]

no clue what I need to search for next

To answer your earlier question, there's nothing new about configuring E axes. A configuration that worked for an earlier version of Marlin 2.0.x (for example, from two months ago) should still be working today.

Just to see if the E axis can turn when given fewer steps-per-second, try reducing your E0 steps-per-mm to a very low value (e.g., 100). Also lower your E jerk and E acceleration. Be sure to always do M502, M500 after flashing new firmware.

[govido]

I am digging down deeper to the core of the problem. I configured a new firmware with basic functionality: Endstops, stepper direction, automatic extruder fan, tmc2130 with stealthchop (software spi), custom pins, no adjusted steps or anything else... and it works. Heated up the exruder and was able to extrude.

So the must be some conflict with a feature I am using (SD Card (hw_spi), I2C display, emulated eeprom , linear advance (was set to 0 as standard), rotary encoder, beeper, interrupt endstops...). I will try to get to the cause of the problem.

[govido]

So... after reflashing my board about 30 times I found the problem, and it is related to the problem viper was describing. As soon as I add #define LIN_ADVANCE the extruder stops working. It makes no difference if the value is 0.22 or 0 aka off. It won't work if the option is active in the firmware. (doesn't matter if stealthchop or spreadcycle is active) I would call this a bug then... I have another quastion about the Due HAL. I wanted to use a 'normal' digital pin for the sdss pin for the sd card. But that will break hardware spi if I don't use one of the 4 special spi cs pins on the due. That is because the spi_pins file deactivates hw spi and uses sw spi that I need for the steppers. I can easily edit the spi_pins file with my pin 27 #if (SDSS == 4) || (SDSS == 10) || (SDSS == 52) || (SDSS == 77) || (SDSS == 27) that gives me just normal hw spi that I would expect from an arduino mega. And my SD card works perfectly good. Is there a specific reason for this choice?

Edit: I wanted to do a test print but the steppers are losing directions like crazy. It seems like every 2nd direction change is a gamble... with or without stealthchop. The x and y axis just smash into things after a few seconds of printing. This is far beyond losing a few microsteps... should I just go back to 8bit hardware because 2.0 isn't ready yet? Or am I doing something totally wrong here? :(

[viper93458]

If you leave LA on but then disable Stealth chop, it may work like mine does. I simply can't use stealth chop along with LA with TMC drivers.

I suspect it may be related to the known bugs in the TMC code that also prevents M122 from showing the status of all the drivers. M122 only returns the status of the last defined TMC driver (which in my case is e0, and I suspect is the case with yours too). I have seen threads that talk about after 1.9 is released then the TMC code may be updated, or possibly in 2.1. :)

I am just assuming its related to that and am simply disabling steath chop to work around it on my devices for now. Again, not sure its the same issue, but it feels the same which is why I brought it up.

-William

[crzcrz]

TMC drivers in StealthChop mode do not tolerate abrupt changes in motor velocity (which is exactly what LA does - it makes the extruder motor convulse back and forth at insane speeds). Switching drivers to SpreadCycle fixes the stalling issue.

[ghost]

I also encountered a similar problem. Marlin on June 1 did not have a problem, but in the latest version E0 (TMC 2130) does not work if LA is enabled. I compare the two Marlin configuration files. In Marlin on June 1, MINIMUM_STEPPER_PULSE was set to 2. However, the latest Marlin says:

/**
 * Minimum stepper driver pulse width (in µs)
 *   0 : Smallest possible width the MCU can produce, compatible with TMC2xxx drivers
 *   1 : Minimum for LV8729 stepper drivers
 *   2 : Minimum for DRV8825 stepper drivers
 *   3 : Minimum for TB6600 stepper drivers
 *  30 : Minimum for TB6560 stepper drivers
 */
#define MINIMUM_STEPPER_PULSE 2

So I set it to 0.

I set MINIMUM_STEPPER_PULSE to 2 in the latest version. Then E0 became to work with LA enabled. When using TMC 2130 Is there a problem with setting MINIMUM_STEPPER_PULSE to 2?

P.S. Although it operated by the manual operation from the host, when actually starting printing, it made a very noisy sound and stopped after moving a little.

[govido]

As I'm currently on vacation I didn't have time to confirm this, but I will try the different stepper pulse settings. Maybe the skipped steps issue is now also gone thanks to the new merge. I will update the issue next week.

[govido]

Back again at testing... I can confirm the same JXPA reported: Setting #define MINIMUM_STEPPER_PULSE from 2 to 0 (which the documentation suggests) makes the extruder completly stop working. Setting this to 1 or back to 2 will make it work again. But what my greatest problem by now ist this: I wanted to print a bed test pattern at 30mm/s that should look like this. But what the printer gives me is this crappy piece. The axis move completely random in different directions. The outer lines are printed first, but as you can see no infill ever hit the target even slightly. This happens with linear advance on or off, doesn't matter. I'm using the 2.0 bugfix from today (07/01). Does anyone have an idea what is going on here? (the Z-axis is slightly to high on the right side, but a crashing x-axis and y-axis is more of a problem here)

Update: What I can confirm so far is:

define MINIMUM_STEPPER_PULSE 0 is incompatible with #define LIN_ADVANCE

if ENABLED(LIN_ADVANCE)

define LIN_ADVANCE_K 0 (even if set to 0=off)

If I set stepper pulse to 1 or 2 the extruder moves again.

The second problem / bug: I think there is something horribly wrong with the way spreadcycle is handled. The way I understand the tmc2130 so far ist:

• stealthchop is used for silent operation but does not support stallguard (so sensorless homing doesn't work)
• spreadcycle is used for 'louder but powerful' of driving the steppers and allows the use of stallguard for homing

Now here is the intersting part: If I disable stealthchop (//#define STEALTHCHOP) the motors get very loud whining noises and the print will look like the picture above. If I enable stealthchop and disable hybrid mode the machine is very quiet (as expected), but when the machine homes the motors get only a little bit louder than stealthchop (the way I am used to from my old RAMPS board). That tells me with my (fairly limited) knowledge of these drivers the homing seems to change the driver modes correctly. But if I define in marlin to never use stealthchop because I want to go faster something goes horribly wrong (or try to use hybrid mode).

I hope that this brings us a little closer to the bug. On a side note: how many times can I flash a due board before it dies on me? 😄

Update 2: I stripped my config to the basics to get this print working with stealthchop at maximum travel speed of 100mm/s. The interesting part is, if I alter this config only by disabling stealthchop the extruder stops moving. Step pulse 0 worked also with one special combination but ended smashing into the axis... I am not 100% sure what the real cause of this really is. Is there something in the driver handling of spreadcycle that changed in the last months? I am using arduino IDE 1.9 for compiling btw. with the libraries of their repository.

[govido]

Hi, today I'm back at testing for the sake of getting the bug here. I tried to test it a little more organized and flashed the following config variations. Maybe someone can confirm this bugs with their tmc2130 extruder driven boards.

Config 1: Stealthchop off LA off Step_dir_delay 20 Stepper_pulse 0
Stepper_rate 400000 Result: Extruder won't move at all, engine whine

Config 2: Stealthchop off LA off Step_dir_delay 20 Stepper_pulse 1
Stepper_rate 400000 Result: Extruder won't move at all, engine whine

Config 3: Stealthchop off LA off Step_dir_delay 20 Stepper_pulse 2
Stepper_rate 250000 Result: Extruder won't move at all, engine whine

Config 4: Stealthchop on LA off Step_dir_delay 20 Stepper_pulse 0
Stepper_rate 400000 Result: successful, silent steppers moves

Config 5: Stealthchop on LA on Step_dir_delay 20 Stepper_pulse 0
Stepper_rate 400000 Result: Extruder won't move at all, silent steppers moves

Config 6: Stealthchop on LA on Step_dir_delay 20 Stepper_pulse 2
Stepper_rate 250000 Result: successful, silent steppers moves

If the extruder doesn't move it still gets warm to the touch. So it is doing something... I have yet to find the config that crashes the axis.

Update: A few other tests: Config 7: Stealthchop on LA on Step_dir_delay 20 Stepper_pulse 2
Stepper_rate 250000 Adaptive_step_smoothing on Result: successful, silent steppers moves

Config 8: Stealthchop on LA on Step_dir_delay 20 Stepper_pulse 2
Stepper_rate 250000 Adaptive_step_smoothing on Endstop_interrupts on Nozzle_park on Result: successful, silent steppers moves

Config 9: Stealthchop on LA on Step_dir_delay 20 Stepper_pulse 2
Stepper_rate 250000 Adaptive_step_smoothing on Endstop_interrupts on Nozzle_park on SD on Result: successful, silent steppers moves

Config 10: Stealthchop on Hybrid_threshold on (x/y 60mm/s) LA on Step_dir_delay 20 Stepper_pulse 2
Stepper_rate 250000 Adaptive_step_smoothing on Endstop_interrupts on Nozzle_park on SD on Result: bad extruder performance (might be due to switching to spreadcycle)

Config 11: Stealthchop off LA on Step_dir_delay 20 Stepper_pulse 2
Stepper_rate 250000 Adaptive_step_smoothing on Endstop_interrupts on Nozzle_park on SD on Result: underextrusion / extruder rattles

Config 12: Stealthchop off LA on Step_dir_delay 200 Stepper_pulse 2
Stepper_rate 250000 Adaptive_step_smoothing on Endstop_interrupts on Nozzle_park on SD on Result: underextrusion / extruder rattles

At this point I'm postive that spreadcycle is completely broken. If step_dir_delay, pulse or rate are altered, the behaviour changes to clicking and blobbing out fine filament pieces. It seems it 'clicks' to the next full step now end then. Oh and I learned that coolstep, not spreadcycle, is used for homing.That would explain the lack of whining noise when using stealthchop.

Just a small info: both the 2.3 and the 2.4.3 libraries for the tmc2130 produce the same problems.

[GasM0nkey]

Hi @all,

i have the same problem with the same behavior that my TMC2208 Driver don't work on the E-Axis combined with Linear Adv. I use the TMC2208 on Ramps 1.4 with no mechanical issues (when i change the E - TMC2208 against a A4988 everything works great also with lin_adv enabled).

@govido i also checked your configs and give them a try with the last Bugfix 2.0.x branch but unfortunately to change the Step_dir_delay / Stepper_pulse doesn't solve the problem with the TMC2208 driver.

my current config looks like.

Stealthchop2 on LA on Step_dir_delay 20 Stepper_pulse 2 ( 1 also doesn't work) Stepper_rate 250000 Adaptive_step_smoothing on

does anyone have a working solution on E - with the TMC2208 drivers, or do they need maybe some other settings because they run Stealthchop 2 regular.

[crzcrz]

As per TMC: rapid changes in the motor velocity cause back EMF spikes that confuse the driver when in StealthChop2 mode and it shuts down. Switching to SpreadCycle should fix the problem.

You can either re-program the driver (just remember that it can only be done once so there's no room for error) or connect it to the RAMPS board with extra wires and let Marlin configure it in runtime. There are plenty of guides available online on how to do that.

[frech-tech]

Hey, @govido: Do you use the HW_SPI or SW_SPI? I'm also trying to get the best settings, since the new features changes a lot. For testing I am similar to your Config 1 (disabled LA, S_Curve, JunctionDevaion, StepSmoothing). First I thought the non moving Extruder it's due to the different type of motor (0.9° Slim ind E, Standard 1.8° on XYZ) Anyway after I switched to the HW_SPI Pins Stepper_pulse 0 works for me. I'm using a Arduino DUE and a modified RAMPS board.

[govido]

@crzcrz I don't know what you want to contribute to this topic... as stated in many of my replies stealthchop is working perfectly, spreadcycle isn't!!! And why should you only be able to reprogram a tmc2130 only once? I would like to stay on topic here. @JackDaFlow I'm using SW_SPI, thanks for pointing that out. I have never thought of it being the problem. If you take a look at my configs above, config 4 also worked with SW_SPI and pulse 0 if no spreadcycle is used. As spreadcycle is always buggy with the extruder I haven't looked into it. Do you run your stepper with the recent 2.0 version in spreadcycle with working extruder and without stepper whining?

[crzcrz]

@govido I was replying to @GasM0nkey in relation to his problems with TMC2208 and StealthChop.

[govido]

@crzcrz ok thanks for clarifying. As the main problem here are 2130 with spreadcycle problems I got really confused with this answer. @JackDaFlow I tried using hardware SPI but got the same whining noise from the steppers. I even tried the version from june 1st where these new options weren't implemented yet.

[frech-tech]

@govido: Sometimes it seems unpredictable to me, therefore I really need to get more into this. I rechecked my settings/setup, and here are some possible differences: I also disabled #define MAXIMUM_STEPPER_RATE: // #define MAXIMUM_STEPPER_RATE 400000 Since I have 32bit, I use real 256 microstepping and no interpolation. You are using a modified RAMPS + DUE? Did you use the D10 and D4 PINs? On DUE these Pins are connected to another PIN (kind of special CS_PIN with new features). D10 to D77(SPI-CS0) and D4 to D87(SPI-CS1). Therefore I don't use these PINS for the MOSFET or Servo. Instead I use D7 and PS_ON_PIN (D12?). What SSSD did you use? I use 10 and therefore CS-Pin for the SD card goes toto D10/D77. Actually I don't think It's hardware related, but these are the possible differences to your setup.

[govido]

@JackDaFlow Hi, as stated above I cheated with the hardware spi settings a little:

I can easily edit the spi_pins file with my pin 27 #if (SDSS == 4) || (SDSS == 10) || (SDSS == 52) || (SDSS == 77) || (SDSS == 27) that gives me just normal hw spi that I would expect from an arduino mega. And my SD card works perfectly good.

I just deactivated SD support and wired the drivers to the hardware SPI while using pins 53, 51, 49 and 52 for the steppers cs line. (my SDSS pin is 27) As the SD card works flawlessly with this trick and the drivers can communicate when I changed this, I can't really understand this limitation that is build in. Even on the Arduino page it is stated that the due can handle AVR spi mode or the extended one. As I haven't found info about Marlin using the extended functions I edited the code accordingly (as it stays AVR compatible anyways).

I use a modified Ramps 1.4 board with Arduino Due @ 24V input for the steppers and extruder heaters (changed mosfets). The fans and heatbed are driven of a custom diy mosfet board (12V/24V). As a display I'm using a 1.3" I2C OLED with rotary encoder (that conflicts with I2C eeprom btw, I haven't got a solution yet).

[GasM0nkey]

I now changed my E Stepper TMC2208 to SpreadCycle mode (over OTP) and this has solved the Problem. Looks like as @crzcrz said that he 2208 cant handle the high and rapid acceleration changes.

[LichtiMC]

I think these "high an rapid acceleration changes" shouldn't occur in the first place. I also think these are the reason for the layer shifting issues. There's still a little bug somewhere (in the planner?), I guess. Is it investigated further or is the topic closed for the devs?

[govido]

Hi, as I have written earlier I would have liked to stick to the topic in this thread. I opened this issue because I'm having very specific issues with 32bit Marlin and TMC2130 when using spreadcycle mode. I don't think it is helpful if users of completely different drivers complain about stealthchop not working. As nobody seems to have a similar config to mine I couldn't dig deeper to what is causing this. Currently I'm running my printer again with 8bit hardware with only stealthchop enabled, because I was running in to too much limitations which the 32bit hal currently has (and no help in sight). To name a few: Neopixel won't work mit 32bit (startup works fine, won't update if steppers move) Eeprom i2c won't work if i2c display is used spreadcycle doesn't work properly engine whine that won't go away in spreadcycle (maybe I will upload a video to illustrate this better) spi config limitations confuse me, I couldn't find any answer for this yet capacitor is needed for z limit switch (more of a 3.3v hardware limitation)

Currently I'm using a printing profile in Slic3r that moves at max. 140mm/s in stealthchop without skipping any steps. I'm using 600mA on X and Y on a 220mm x 220mm printbed. So stealthchop is working flawlessly for me now (at least on 8bit hardware). If anyone is interested in the config I cloned them in my marlin repo (this is my 32bit config). On 8bit I'm using a different pin file and 16 microsteps not 64.

As this is an open source project and @thinkyhead has more than enough to do already, I decided to switch back to 8bit until 2.0 is closer to a finished release. There are just too many things still changing that break other features and bring new ones. As my I don't have real programming skills I can't contribute much to this project beside testing configs and hardware.

[frech-tech]

@govido It seems that we have a similar SetUp. I ran some further tests the last days (still in progress). All Motors (with TMC2130) running fine in Spreadcycle and Stealthchop. In Steahlchop I got some layershift in Y with accelerations higher than 1200mm/s², therefore I'm using Spreadcycle. The motors are still more quiet than the fans (256 microstepping, no interpolation). Stepper_Pulse 0 works with JUNCTION_DEVIATION, ADAPTIVE_STEP_SMOOTHING and S_CURVE_ACCELERATION However, when enabling LIN_ADVANCE the extruder stops moving. Using Stepper_Pulse 2 all options seem to work. Should I upload my actual firmeware?

[ModMike]

Also having the same issue with LA set to .4. Using 2208 on a re-arm, extruder stops after 25th layer.

Any definitive answer?

[ModMike]

Finally got working on 24V Re-Arm with TMC2208. First step is to properly set TMC (or whatever driver you are using) driver settings as per the recommended values in Marlin:

Minimum delay after setting the stepper DIR (in ns)

• 0 : No delay (Expect at least 10µS since one Stepper ISR must transpire)
• 20 : Minimum for TMC2xxx drivers
• 200 : Minimum for A4988 drivers
• 500 : Minimum for LV8729 drivers (guess, no info in datasheet)
• 650 : Minimum for DRV8825 drivers

• 1500 : Minimum for TB6600 drivers (guess, no info in datasheet) *15000 : Minimum for TB6560 drivers (guess, no info in datasheet)

  Minimum stepper driver pulse width (in µs)

• 0 : Smallest possible width the MCU can produce, compatible with TMC2xxx drivers
• 1 : Minimum for A4988 stepper drivers
• 1 : Minimum for LV8729 stepper drivers
• 2 : Minimum for DRV8825 stepper drivers
• 3 : Minimum for TB6600 stepper drivers
• 30 : Minimum for TB6560 stepper drivers

Maximum stepping rate (in Hz) the stepper driver allows

• If undefined, defaults to 1MHz / (2 * MINIMUM_STEPPER_PULSE)
• 500000 : Maximum for A4988 stepper driver
• 400000 : Maximum for TMC2xxx stepper drivers
• 250000 : Maximum for DRV8825 stepper driver
• 150000 : Maximum for TB6600 stepper driver
• 130000 : Maximum for LV8729 stepper driver
• 15000 : Maximum for TB6560 stepper driver

define MINIMUM_STEPPER_DIR_DELAY 20

define MINIMUM_STEPPER_PULSE 0

define MAXIMUM_STEPPER_RATE 400000

Then you need to test extruder jerk. Mine was at 5 which stalled the extruder after a K factor of .1 so I bumped it to 40 and worked my way down. 10 seemed to work best so thats where I ended up.

[ModMike]

Thought I had it but completely unreliable, extruder still stalls. Something definitely up with E jerk and Linear Advance

[yagona]

I'd like to contribute to this thread. My modified Anycubic i3 MEGA is equipped with TMC2208 also for the extruder. The extruder is an E3D Titan clone in a bowden setup (=430steps/mm). I use Linear Advance with K=0.6 in bugfix-1.1.x. As I suffered from regular extrusion stops I tried to identify possible reasons. Now, I am quite sure that these are triggered in Stealthchop mode by quick speed and/or direction changes as mostly occuring with activated LA and as mentioned by some of you before. Changing Vref in legacy mode or changing the timings as well as accelerations and jerk settings never succeded 100%. However, as I did the neccessary hardware modifications to switch the extruder TMC2208 from Stealthchop to Spreadcycle, these extruder stops never occured again. Now I am using hybrid mode at 30mm/s threshold for the extruder and there are no problems any longer...

configuration.zip

Throughout the tests I could identify a small range of layers in the referenced object (KACA-ORBITAL03.STL) where the problem reproducibly occured and as found in the reduced gcode attached.

https://www.thingiverse.com/thing:542914/files gcode.zip

The problem with a stopping extruder occurs (for me) already after a couple of layers (<10) when in Stealthchop mode. Now, when in hybrid mode, I can clearly hear and feel high frequency direction changes at the extruder for some small movements within each layer (infill?), but it doesn't stop, fortunately. I suppose that these parts are where the extruder would stop when in Stealthchop mode and is now switching to Spreadcycle automatically. So despite I understand that Stealthchop is not a suitable choice for the extruder when using LA, I wonder why there are such frequent extruder direction changes caused by the attached gcode at all. At least, the behavior of these extruder movements is clearly different from others in the attached gcode. Though I found a way to prevent the extruder to stop, I suspect a bug in LA which is caused by one/some of the movements in the attached gcode resulting in unwanted direction changes at high frequencies. Maybe this issue is reproducible for some of you with the attached gcode movements and we can narrow down the problem.

[erikkallen]

I think I have a similar issue but with an 8-bit board 12V ramps

During the infill the printer decides to shift to the left front it does this consistently, this is the 20mm test cube but the same happens with different models I have disabled lin_advance and tried both stealth chop and spread cycle

Configuration.zip

20mmTestCube_repaired.zip

My extruder seems to work ok though

[thinkyhead]

We had an issue with bad jerk values (in bugfix-2.0.x) for a few days. It's now patched, so give the latest bugfix-2.0.x code a try.

[erikkallen]

I tried again this morning with the latest bugfix-2.0.x commit 07db08e39 and the same thing happens. It works fine on bugfix-1.1.x but on bugfix-2.0.x somehow the printer chooses a random direction half way through the infill or half way a outside perimeter. I have tried lower jerk values but that does not help either.

If there is any combination/configuration suggestion I should try I am happy to do so.

Added picture of this mornings attempt (I did reslice the test cube)

[thinkyhead]

@erikkallen — Printing from host or from SD?

[erikkallen]

I am printing from host (raspberry pi 3)

---

From: Scott Lahteine notifications@github.com Sent: Friday, October 26, 2018 12:07 PM To: MarlinFirmware/Marlin Cc: Erik Kallen; Mention Subject: Re: [MarlinFirmware/Marlin] Bugfix 2.0.x tmc2130 incompatible linear advance / stepper pulse, spreadcycle problems (#11024)

@erikkallenhttps://github.com/erikkallen — Printing from host or from SD?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHubhttps://github.com/MarlinFirmware/Marlin/issues/11024#issuecomment-433358275, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AAff5OzZtyH_VfbujtuHUU6FDFQJlidOks5uot7XgaJpZM4UoqmE.

[moracabanas]

Thanks you because I found this thread. Im working with Re-Arm and XYZE TMC2130. Extruder motor just lock itself instead of extrude if you use Linear_Advance so I can confirm we cannot use at least at the moment.

[erikkallen]

I tried the latest bugfix-2.0.x release just now and for me the problem seams to have disappeared (full disclosure I did reinstall my system, so it could have been a bad library as well, config was not changed in between tries hough)

[boelle]

@govido problem solved?

[lookiamluke]

Hey all, can confirm the issue still persists on my build and the latest bugfix as of 4 days ago. I'm running RE-ARM and SD2224 drivers (which are based on the TMC2208's)

The only way I can get Lin_Adv to work without making the extruder motor crap out is in Spreadcycle mode.

If I want to use Stealthchop2, I have to set my print speed LOW --- like 20mm/s to keep it from crapping out. Changing #define MINIMUM_STEPPER_PULSE to 2 did not fix this for me.

So for the time being, anyone running TMC drivers will likely need to set the extruder driver to Spreadcycle mode until this issue is resolved.

[ModMike]

The extruder has to be in spread cycle, nothing else you can do about it. Fought that issue for months, gave up, now use spread cycle and enjoying linear advance.

[harleycarr]

If we're going to close this without fixing it there should be a flag when Stealthchop is enabled on e0 to check for the presence of lin_adv until this has a solution. Or leave this issue open.

[govido]

Hi, after a long time i finally got back to testing this issue (work happened...). I'm now using an BTT SKR 1.3 board with 4x 2130 drivers. I tested with a build of Marlin 2.0 from 05.23.19. With linear advance I still can't get movement from the extruder motor. I also tried the new option to disable stealthchop on E. The only way I managed to get the extruder going so far, is disabling linear advance completely... @ModMike did you have success with the pulse options? The extruder still has an awful whining noise if it moves without spreadcycle.

[Gerggg]

Hello, This is the same problem with TMC2208, on my side to maintain linear advence, I put TMC2100 on my extruders. There is no problem with the TMC2100

[govido]

@Gerggg Could you try to set MINIMUM_STEPPER_PULSE to 1? This fixed the issue for me on tmc2130 drivers in spi mode.

[ptyork]

This definitely should not be closed. Trying to get LA to work on SKR v1.3 with 5 2208 (dual Z). Interestingly, commenting out STEALTHCHOP_E doesn't seem to actually disable it. Though, manually disabling it from the LCD results in the extruder perhaps TRYING to work, but only giving an annoying buzzing sound.

I DID finally get it to work using @govido's suggestion (setting MINIMUM_STEPPER_PULSE to either 1 or 2 worked). Did NOT have to comment STEALTHCHOP_E.

All makes me wary. What is the potential implication of setting the stepper pulse? According to the comments, upping it would SEEM to make it somehow incompatible with the TMC2xxx drivers. Are the TMC driver libraries just buggy as sin? Or is the fixable in Marlin?

[claymore666]

I have Marlin 2 as of July 2019 running with an Ender 3 on an SKR1.3 w. 4 x TMC2130; StealthChop and Linear Advance enabled. Settings:

#define LIN_ADVANCE //k=0.22 default
#define MINIMUM_STEPPER_PULSE 1   // <<= would not work with 0
//#define MINIMUM_STEPPER_DIR_DELAY 650  //<<= I still have the default delay by the driver
#define MAXIMUM_STEPPER_RATE 400000
#define TMC_USE_SW_SPI
#define STEALTHCHOP_XY
#define STEALTHCHOP_Z
#define STEALTHCHOP_E
//#define HYBRID_THRESHOLD
#define INTERPOLATE       true 

For all TMCs Current is set to 800, 16 Microsteps, i.e. defaults from Marlin.

From what I think, the problem is related to the EMV emissions, as stated earlier. That is, the feature creates so many impulses on the control lines to the stepper that the signal does not come through clean enough anymore. You can countermeasure this by using shielded cables(not an option for a 3d printer, but standard with CNC machines) or reduce the frequency and cable length. Can you try out my config?

[thinkyhead]

A MINIMUM_STEPPER_PULSE of 1µs seems to be a good idea for some (most? all?) of the TMC stepper drivers. The "standalone" options have it default to zero. The other TMC drivers fall through so the pulse gets set to 2µs. Thus I would expect the standalone drivers to lose pulses, but the non-standalone drivers to behave like DRV8825's and be fairly reliable in their pulse timing.

[gloomyandy]

The other TMC drivers fall through so the pulse gets set to 2µs. Thus I would expect the standalone drivers to lose pulses, but the non-standalone drivers to behave like DRV8825's and be fairly reliable in their pulse timing.

I would say that is not what most users (myself included) have experienced. From the many comments both here and in the Bigtreetech faecbook group setting MINIMUM_STEPPER_PULSE to 1 or 2 seems to be required when using TMC drivers (with either SPI or UART control) on LPC176x based boards (having said that I'm pretty sure that DRV8825s also required the same setting on the LPC176x boards as well). This seems to be particularly true for the extruder.

The recently introduced SQUARE_WAVE_STEPPING option seems to offer an alternate solution to setting the minimum stepper pulse. With that option enabled I no longer needed to set any value for MINIMUM_STEPPER_PULSE.

[gloomyandy]

@thinkyhead looking at the definition of "TRINAMICS" https://github.com/MarlinFirmware/Marlin/blob/bugfix-2.0.x/Marlin/src/inc/Conditionals_post.h#L499 HAS_TRINAMIC (see https://github.com/MarlinFirmware/Marlin/blob/bugfix-2.0.x/Marlin/src/inc/Conditionals_post.h#L499) includes the SPI and UART controlled TMC drivers (like TMC2208 and TMC2130). So they will currently be using a pulse time of zero unless MINIMUM_STEPPER_PULSE has been set.

[LastDragon-ru]

MINIMUM_STEPPER_PULSE to 1 or 2 seems to be required when using TMC drivers (with either SPI or UART control) on LPC176x

I can confirm that MINIMUM_STEPPER_PULSE required for extruder with 2208 on skr 1.3 and mks sbase (combination with SQUARE_WAVE_STEPPING not tested).

SQUARE_WAVE_STEPPING = true/false | MINIMUM_STEPPER_PULSE = 1 or 2 | any chopper mode | any microsteps (4/8/16/32)

But extruder on my delta (2208 and skr 1.3 or mks sbase) loses steps in any case (lin advance pattern looks similar to DRV8825 from #14538, but gaps start from ~0.5-0.6).

[pkucmus]

I can't tell if I'll add noise or actually give some helpful input but I had the issue. Disabling LIN_ADVANCE helped. I'm using TMC2130 on X, Y, Z, E0 24V All spreadCycle Here's my config: https://github.com/MarlinFirmware/Marlin/compare/bugfix-2.0.x...pkucmus:skr1.3_mk3 To be clear the only thing I changed to make my extruder move was Disabling LIN_ADVANCE

[claymore666]

Disabling LIN_ADVANCE helped. I have disabled LIN_ADVANCE for now again because it stresses the drivers that much that I do run into thermal issues. Working on an active cooling the moment we speak. Will test it again then, to verify my assumption.