Marlin: [BUG] Marlin 2.0 32 bit Linear Advance error

Created on 28 Jan 2019  Â·  55Comments  Â·  Source: MarlinFirmware/Marlin

Hi,
Linaer Advance not working on Marlin 2.0 with 32 bit board.
if i set it to 0 and i want to print a test, the Extruder engine do Nothing... like disabled...
can somebody help me please ?

on 1.1.9 with 8bit board workin good.

thx.

Most helpful comment

here we go.
Imgur
I was not able to reproduce any problems with babystepping, but the step pulse when lin_adv is on and pulse length is 0 is extremely small (8us) and looks nothing like a square wave at all. Is this something that might be a issue with rise/fall time on the MCU?

All 55 comments

This is a duplicate of #12870 - can you close this and continue the discussion there?

See #12983 for workaround.

Sorry, i am new...
What can i do now ?
Is was fixed ?
Can i get a new fixed version ?
Thx.

Am Mo., 28. Jan. 2019, 23:22 hat SupremeFPV notifications@github.com
geschrieben:

See #12983 https://github.com/MarlinFirmware/Marlin/issues/12983 for
workaround.

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/MarlinFirmware/Marlin/issues/13040#issuecomment-458325524,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AjH116yYnEofLcGBmssFe_VJ_NQc9ZP0ks5vH3gUgaJpZM4aWp0c
.

See #12983 for workaround.

I can confirm that setting MINIMUM_STEPPER_PULSE to 1 on Archim 2.0 solves the problem.

It seems like the trouble lies in the following code in "Conditional_post.h":

#ifndef MINIMUM_STEPPER_PULSE
  #if HAS_DRIVER(TB6560)
    #define MINIMUM_STEPPER_PULSE 30
  #elif HAS_DRIVER(TB6600)
    #define MINIMUM_STEPPER_PULSE 3
  #elif HAS_DRIVER(DRV8825)
    #define MINIMUM_STEPPER_PULSE 2
  #elif HAS_DRIVER(A4988) || HAS_DRIVER(LV8729) || HAS_DRIVER(A5984)
    #define MINIMUM_STEPPER_PULSE 1
  #elif TRINAMICS
    #define MINIMUM_STEPPER_PULSE 0
  #else
    #define MINIMUM_STEPPER_PULSE 2
  #endif
#endif

This apparently defaults to 0 when using TRINAMICS. My guess is that this is fine (maybe even required) on the slower AVR chips, but on the faster 32-bit chips, the pulse width becomes too small. Perhaps this should be updated so on faster chips a default of 1 is used for TRINAMICS?

@teemuatlut: @thinkyhead: Thoughts on implementing this idea?

Hi,

I have 2208 inside...

Am Do., 31. Jan. 2019, 16:41 hat Marcio Teixeira notifications@github.com
geschrieben:

See #12983 https://github.com/MarlinFirmware/Marlin/issues/12983 for
workaround.

I can confirm that setting MINIMUM_STEPPER_PULSE to 1 on Archim 2.0 solves
the problem.

It seems like the trouble lies in the following code in
"Conditional_post.h":

ifndef MINIMUM_STEPPER_PULSE

if HAS_DRIVER(TB6560)

define MINIMUM_STEPPER_PULSE 30

elif HAS_DRIVER(TB6600)

define MINIMUM_STEPPER_PULSE 3

elif HAS_DRIVER(DRV8825)

define MINIMUM_STEPPER_PULSE 2

elif HAS_DRIVER(A4988) || HAS_DRIVER(LV8729) || HAS_DRIVER(A5984)

define MINIMUM_STEPPER_PULSE 1

elif TRINAMICS

define MINIMUM_STEPPER_PULSE 0

else

define MINIMUM_STEPPER_PULSE 2

endif

endif

This apparently defaults to 0 when using TRINAMICS. My guess is that this
is fine (maybe even required) on the slower AVR chips, but on the faster
32-bit chips, the pulse width becomes too small. Perhaps this should be
updated so on faster chips a default of 1 is used for TRINAMICS?

@teemuatlut https://github.com/teemuatlut: @thinkyhead
https://github.com/thinkyhead: Thoughts on implementing this idea?

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/MarlinFirmware/Marlin/issues/13040#issuecomment-459390981,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AjH111ebieKWr04-q11nSqewdPMOlwYUks5vIw6UgaJpZM4aWp0c
.

@Milu1980: Edit "Configuration_adv.h" in the "Marlin" directory and change this line:

//#define MINIMUM_STEPPER_PULSE 2

To:

#define MINIMUM_STEPPER_PULSE 1

Recompile, flash and see if it helps.

The datasheet gives us a parameter for STEP input high time.
It is determined by t_FILTSD and t_clk + 20, which ever is higher.
t_FILTSD ranges from 36 to 85 (min, max) with 65 given as a typical value.
t_clk is 1/12,65MHz = 79ns, therefore it is higher at around 100ns or 0.1ms 0.1µs.
Step signal low time is limited in the same manner.

I don't know linear advance logic well enough to say why the problem would be present only with it enabled.
If using a setting of 1 is enough to remedy the issue, I have no objections to changing the parsed default value.

therefore it is higher at around 100ns or 0.1ms.

You mean 0.1us rather than 0.1ms? Anyhow, 1us certainly is greater than 0.1us, so setting MINIMUM_STEPPER_PULSE to 1 would certainly be sufficient.

It seems the Due runs at 84Mhz, which means that at an approximation, every instruction could run every 10ns. Certainly it is possible that if Marlin is executing fewer that 7 or so instructions between toggling the pins, it would be too fast for the Trinamic drivers. In this thread, @HackingGulliver said he was seeing shorter pulses on the E stepper vs the XY steppers, but he did not say how long they were.

I can get some oscilloscope data of the stepper output if it will help?

@SupremeFPV: If that is something you can do easily, it would be great to verify that the step signal lengths were within the acceptable ranges. Maybe try it for regular extrusion on E as well as for babystepping on X and Y.

I'll see what I can do over the weekend. I have to bring my printer to work then.
ill do E with/without lin_adv. I havent used babystep on x/y before, is this the same as on Z?

Yes. Although measuring it on Z is probably sufficient. It is all the same code.

Hi, yes its working but bad...
I set it 10 lines and do this:

Am Fr., 1. Feb. 2019, 00:10 hat Marcio Teixeira notifications@github.com
geschrieben:

Yes. Although measuring it on Z is probably sufficient. It is all the same
code.

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

here we go.
Imgur
I was not able to reproduce any problems with babystepping, but the step pulse when lin_adv is on and pulse length is 0 is extremely small (8us) and looks nothing like a square wave at all. Is this something that might be a issue with rise/fall time on the MCU?

With "K0" can be set the correct line...
If i set the pattern to K 0.2-0.3 with 0.01 step, in 8 bit board do 10
lines, in 32bit just 2-3 and thats was :( it break just the print...

Am So., 3. Feb. 2019, 20:44 hat SupremeFPV notifications@github.com
geschrieben:

here we go.
https://imgur.com/a/dfQXYT3 http://Here
I was not able to reproduce any problems with babystepping, but the step
pulse when lin_adv is on and pulse length is 0 is extremely small (8us) and
looks nothing like a square wave at all. Is this something that might be a
issue with rise/fall time on the MCU?

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

@SupremeFPV: Good work! I think this confirms why we've been having good luck with MINIMUM_STEPPER_PULSE set to 1.

I guess the question now is whether and how Marlin should be patched. Either we make a choice for all 32-bit boards or perhaps we could add MINIMUM_STEPPER_PULSE to the "pins.h" files corresponding to boards where this issue crops up.

Hello !

It does'nt work for me...

LIN_ADVANCE K 0 is ok, K 0.1 make the extuder stops.

I use Malin bugfix 2.0 on MKS SGEN (Sbase settings with TMC2208_STANDALONE drivers ).

layers shift when the printer climbs layer Can help I use tb6600
loi tb

@Milu1980 problem solved?

Not really...
Its working, but the pattern looking not the samme like with the 8bit
board..
I cant upload the pic.

Am Do., 21. Feb. 2019, 23:04 hat Bo Herrmannsen notifications@github.com
geschrieben:

@Milu1980 https://github.com/Milu1980 problem solved?

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

just copy and paste the pic

but you can not do it from email

remember to upload pic

just copy and paste it in here... crtl+c then here ctrl+v

For anyone looking, I can confirm that setting MINIMUM_STEPPER_PULSE to 1 fixed extruder stepping on my SKR V1.3 board running Trinamic TMC2130 drivers after enabling Linear Advance.

For anyone looking, I can confirm that setting MINIMUM_STEPPER_PULSE to 1 fixed extruder stepping on my SKR V1.3 board running Trinamic TMC2130 drivers after enabling Linear Advance.

@teemuatlut — Do you think this should apply to all "TRINAMICS" and other TMC stepper drivers? We now have this:

#ifndef MINIMUM_STEPPER_PULSE
  #if HAS_DRIVER(TB6560)
    #define MINIMUM_STEPPER_PULSE 30
  #elif HAS_DRIVER(TB6600)
    #define MINIMUM_STEPPER_PULSE 3
  #elif HAS_DRIVER(DRV8825)
    #define MINIMUM_STEPPER_PULSE 2
  #elif HAS_DRIVER(A4988) || HAS_DRIVER(A5984)
    #define MINIMUM_STEPPER_PULSE 1
  #elif HAS_DRIVER(LV8729)
    #define MINIMUM_STEPPER_PULSE 0
  #elif TRINAMICS
    #define MINIMUM_STEPPER_PULSE 0
  #else
    #define MINIMUM_STEPPER_PULSE 2
  #endif
#endif

…And apparently zero is just too small (or 2 is just too large) for these drivers on 32-bit boards. We're currently specifying these in µs, so maybe, if needed, we can graduate to ns and set this pulse length to ~500….

@juchong — Are you using TMC2130_STANDALONE or TMC2130? (I'm assuming the latter.)

I think dedge is a more elegant solution that doesn't increase the time spent in ISR.
But we can do it if the user has Lin Adv enabled, dedge disabled and at least one TMC.
Bonus points if it gets documented somewhere.

@thinkyhead TMC2130 - I'm connecting to the drivers via SPI. Out of curiosity, is the limitation the timer resolution or the actual interface hardware? The "non-square pulse" shown in the imgur album linked above looks suspiciously like what happens when a GPIO is set and reset in concurrent CPU instructions. Specifying the minimum pulse in uS would likely help, and since 2.0 is targeted at 32-bit processors, there really isn't a need to keep compatibility with legacy boards, right?

The #1 priority of Marlin v2 is to keep compatibility with 8bit boards. They're the vast majority of the user base and will be for a long time.

@thinkyhead: Our printers use TMC2130 and we needed to set MINIMUM_STEPPER_PULSE to 1.

UPDATE: Only on a 32-bit Archim. On 8-bit AVR, our TMC2130 use MINIMUM_STEPPER_PULSE = 0.

Lin adv on or off?

@teemuatlut: With LIN_ADV, we needed to set MINIMUM_STEPPER_PULSE to 1 with the TMC2130 in order for the extruder motor to run on the Archim. With LIN_ADV off, the default of zero worked fine.

On the 8-bit AVR, MINIMUM_STEPPER_PULSE of zero works both with LIN_ADV on and LIN_ADV off.

Well that's nothing new. The conditions however are starting to stack up for the issue to occur, but as said, I'm fine with increasing the default if these conditions all are true in the config.

I'm haveing the same issue Ender 3 skr 1.3 tmc 2208 standalone drivers for all motors.
If linear advance uncommented the extruder stops with the value of 1 in the minimum pulse it extrudes but under printing it's not. Same with value 2

Minimum pulse have nothing to do with this issue. Just don't use 2208 on extruder with stealthchop enabled.

How can I disable it or what to do?

Only through UART.

I just re-tuned the extruder after setting MINIMUM_STEPPER_PULSE to 1. Haven't had issues since.

Hi I ran into this as well. I have an SKR v1.3 with TMC2130 drivers in spi mode. I found this thread which helped to resolve the issue (MINIMUM_STEPPER_PULSE to 1).

What i do not get is how a MINIMUM_STEPPER_PULSE at 0 would even be possible, apart from how difficult it would be to create such a zero length pulse ;-) the stepper would never move as it would not be able to differentiate a zero length pulse from no pulse :-P.

This is clearly a bug MINIMUM_STEPPER_PULSE should never be set to 0. at the very lowest value it should be something like "BEST EFFORT SHORTEST PULSE".

I know the rationale for setting it to 0, to get a shortest possible pulse but setting it to zero is asking for trouble, as seen now with faster MCU/boards

That's tried to express by MINIMUM_STEPPER_PULSE.
On the AVRs 0 used to be no problem because the processors where not able to switch the pins fast enough to hurt.

so what is the consensus here? any TMC driver used with extruder set min step pulse to 1 OR disable stealthcop?

I test it
board: scr 1.1 pro
drivers: tmc5160
uncomment pulse and set 1 => nothing change; "#define MINIMUM_STEPPER_PULSE 1"
comment stealthchop AND comment pulse => Working!
//#define STEALTHCHOP_E
//#define MINIMUM_STEPPER_PULSE 1

enjoy

@Milu1980 tried what @ritor1sefa suggested?

Confirming fix in my setup: SKR 1.3 + TMC2208 (delta configuration)
Enabling LIN_ADVANCE disabled my extruder stepper
Changing MINIMUM_STEPPER_PULSE to 1 re-enabled it.

oki will close this one as its fixed

SKR mini DIP 1.0, 2208s, Stealthchop disabled on E stepper.

2.0.x firmware from Bigtree I got Lin_Adv working

On recent pull of 2.0.x build when I turn on Lin_Adv I don't get any E movement.

MINIMUM_STEPPER_PULSE to 1 did NOT work for me either.

also here: skr 1.3, TMC 2208, marlin 2.0.3
whatever LIN_ADVANCE= on/off
MINIMUM_STEPPER_PULSE=off/0/1
nothing work
stepper give slow and not correct movement

@yoc1983 — Please open a new issue and fill in the template. Test the latest bugfix-2.0.x first.

@gannon145 — Please open a new issue and fill in the template. Test the latest bugfix-2.0.x first.

FYI Same issue with no practically no extrusion on stock Creality Ender 3 (Pro) 1.1.5 board, TMC2208 drivers set as TMC2208_STANDALONE in Configuration.h. This is an 8bit atmega1284p, so certainly not just a 32bit problem.

Manually extruding via Prontiface or similar works fine, but not during printing with linear advance enabled. After disabling it it extrudes fine. for the first few layers then starts having issues - not sure if it's skipping steps or something else, going to do some further testing to see if I can isolate the issue get linear advance working on this board.

If anyone knows if it's possible to run this board+drivers in UART mode I'd appreciate any pointers.

Capture
-All steps/mm are set correctly. Something is going awry during the print.

Edit: Print issues once LinK was disabled were due to a dead part cooling fan, nothing to do with Marlin.

This is a known and well documented issue with LA and TMC drivers in stealthchop mode. We have a line on a method to resolve it but it basically means a rewrite of how LA injects steps, as the interpolation function of stealthchop cant handle the sudden change in the pulse train.

the interpolation function of stealthchop cant handle the sudden change in the pulse train

It'll be good to see this on an oscilloscope. The E stepper should be following its own trapezoid acceleration / deceleration trajectory, and pulses should be as regular as with the other axes. Is there something related to a too-high E Jerk that could be exacerbating this? I seem to recall that E Jerk needs to be in a limited range to work well with LA.

@sjasonsmith had a logic analyzer trace showing LA injected pulses very close to the normal step train.

The normal part of the move and LA inject steps independent of one another. This leads to an effective double-step when they happen to align within the same ISR, which the drivers don’t like. I had some workarounds that improved things, but there were always more edge cases that would mess up, and I had to set it aside.

FWIW I ended up replacing the stock Creality board with an SKR 1.4 and TMC2209's. This combo is fine in StealthChop w/ LA enabled.

One thing I have noticed is with UBL enabled there are micropauses when the nozzle passes over/within ~1mm of the UBL grid points. This results in slight over-extrusion at these areas and mild surface artefacts. I saw earlier reports about something similar on grid boundaries, which appears to have been fixed in more recent versions but there is still something going on at the grid corners. Any chance this is in any way related or should I be filing another ticket?

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.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

Tamonir picture Tamonir  Â·  3Comments

Matts-Hub picture Matts-Hub  Â·  3Comments

manianac picture manianac  Â·  4Comments

Kaibob2 picture Kaibob2  Â·  4Comments

Ciev picture Ciev  Â·  3Comments