Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[BUG] Marlin 2.0 32 bit Linear Advance error #13040

Closed
Milu1980 opened this issue Jan 28, 2019 · 46 comments

Comments

@Milu1980
Copy link

commented Jan 28, 2019

Description

Steps to Reproduce

  1. [First Step]
  2. [Second Step]
  3. [and so on...]

Expected behavior: [What you expect to happen]

Actual behavior: [What actually happens]

Additional Information

  • Include a ZIP file containing your Configuration.h and Configuration_adv.h files.
  • Provide pictures or links to videos that clearly demonstrate the issue.
  • See How Can I Contribute for additional guidelines.
@Milu1980

This comment has been minimized.

Copy link
Author

commented Jan 28, 2019

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.

@InsanityAutomation

This comment has been minimized.

Copy link
Contributor

commented Jan 28, 2019

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

@SupremeFPV

This comment has been minimized.

Copy link

commented Jan 28, 2019

See #12983 for workaround.

@Milu1980

This comment has been minimized.

Copy link
Author

commented Jan 28, 2019

@marcio-ao

This comment has been minimized.

Copy link
Contributor

commented Jan 31, 2019

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?

@Milu1980

This comment has been minimized.

Copy link
Author

commented Jan 31, 2019

@marcio-ao

This comment has been minimized.

Copy link
Contributor

commented Jan 31, 2019

@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.

@teemuatlut

This comment has been minimized.

Copy link
Member

commented Jan 31, 2019

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.

@marcio-ao

This comment has been minimized.

Copy link
Contributor

commented Jan 31, 2019

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.

@SupremeFPV

This comment has been minimized.

Copy link

commented Jan 31, 2019

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

@marcio-ao

This comment has been minimized.

Copy link
Contributor

commented Jan 31, 2019

@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.

@SupremeFPV

This comment has been minimized.

Copy link

commented Jan 31, 2019

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?

@marcio-ao

This comment has been minimized.

Copy link
Contributor

commented Jan 31, 2019

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

@Milu1980

This comment has been minimized.

Copy link
Author

commented Feb 3, 2019

@Milu1980

This comment has been minimized.

@SupremeFPV

This comment has been minimized.

Copy link

commented Feb 3, 2019

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?

@Milu1980

This comment has been minimized.

Copy link
Author

commented Feb 3, 2019

@marcio-ao

This comment has been minimized.

Copy link
Contributor

commented Feb 6, 2019

@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.

@deamoncrack

This comment has been minimized.

Copy link

commented Feb 13, 2019

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 ).

@mhmdrefaat60

This comment has been minimized.

Copy link

commented Feb 21, 2019

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

@boelle

This comment has been minimized.

Copy link
Contributor

commented Feb 21, 2019

@Milu1980 problem solved?

@Milu1980

This comment has been minimized.

Copy link
Author

commented Feb 22, 2019

@boelle

This comment has been minimized.

Copy link
Contributor

commented Feb 22, 2019

just copy and paste the pic

but you can not do it from email

@boelle

This comment has been minimized.

Copy link
Contributor

commented Mar 6, 2019

remember to upload pic

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

@juchong

This comment has been minimized.

Copy link

commented Jul 11, 2019

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.

@thinkyhead

This comment has been minimized.

Copy link
Member

commented Jul 11, 2019

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….

@thinkyhead

This comment has been minimized.

Copy link
Member

commented Jul 11, 2019

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

@teemuatlut

This comment has been minimized.

Copy link
Member

commented Jul 11, 2019

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.

@juchong

This comment has been minimized.

Copy link

commented Jul 11, 2019

@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?

@teemuatlut

This comment has been minimized.

Copy link
Member

commented Jul 11, 2019

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.

@marcio-ao

This comment has been minimized.

Copy link
Contributor

commented Jul 11, 2019

@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.

@teemuatlut

This comment has been minimized.

Copy link
Member

commented Jul 11, 2019

Lin adv on or off?

@marcio-ao

This comment has been minimized.

Copy link
Contributor

commented Jul 11, 2019

@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.

@teemuatlut

This comment has been minimized.

Copy link
Member

commented Jul 11, 2019

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.

@daiben2

This comment has been minimized.

Copy link

commented Jul 16, 2019

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

@EvilGremlin

This comment has been minimized.

Copy link

commented Jul 16, 2019

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

@daiben2

This comment has been minimized.

Copy link

commented Jul 16, 2019

How can I disable it or what to do?

@EvilGremlin

This comment has been minimized.

Copy link

commented Jul 16, 2019

Only through UART.

@juchong

This comment has been minimized.

Copy link

commented Jul 16, 2019

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

@boelle boelle changed the title Marlin 2.0 32 bit Linear Advance error [BUG] Marlin 2.0 32 bit Linear Advance error Jul 21, 2019
@SiskoBen

This comment has been minimized.

Copy link

commented Aug 15, 2019

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

@AnHardt

This comment has been minimized.

Copy link
Contributor

commented Aug 15, 2019

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.

@Black6spdZ

This comment has been minimized.

Copy link

commented Aug 17, 2019

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

@ritor1sefa

This comment has been minimized.

Copy link

commented Sep 17, 2019

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

@boelle

This comment has been minimized.

Copy link
Contributor

commented Oct 12, 2019

@Milu1980 tried what @ritor1sefa suggested?

@jharmn

This comment has been minimized.

Copy link

commented Oct 14, 2019

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.

@boelle

This comment has been minimized.

Copy link
Contributor

commented Oct 14, 2019

oki will close this one as its fixed

@boelle boelle closed this Oct 14, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
You can’t perform that action at this time.