[bugfix-2.0.x] Marlin not outputting E steps (smoothieboard LPC1769 )

[Lafonen]

Hello.

I am having an issue with marlin running on a smoothieboard not outputting E steps. I am running TMC2130 drivers, all are ok according to M122. Dual Z axis so extruder is configured for M5 on the board.

I have tried swapping X and E0 in the pins file. The problem follows E0 so motor/driver and wiring seems ok. By the looks of it marlin tries to move the motor because I have to wait until the move is finished before I can move another axis. EN and DIR pin are working when I measure them.

I have tried with the extruder at 220deg and with cold extrusion disabled. Also tried with a new config file with just the essentials.

Nothing works, anyone has some tips I can try?

config.zip

[fakcior]

I also have similar problem. When I try move E axis from menu by 10mm or 1mm motor just clicks. No movement. 0.1mm steps work better, but I'm not sure if fully correct - I haven't measure the travelled distance. Anyway during the print extruder works just fine. Swapping pins in config and stepper wires confirmed that is the firmware issue.

I'm using SKR v1.1 + TMC2208 on all axes.

[Lafonen]

The issue seems to be caused by linear advance. Extruder works when it is disabled.

[marcio-ao]

Sounds like this is confirmation of #12870

[Lafonen]

Jupp, I tried and it will not work for any K value. only when lin_advance is disabled so its the exact same issue. Might as well just close this thread then.

[marcio-ao]

Is your board a 32-bit board?

[Lafonen]

yeh

[marcio-ao]

I'll change the title of that original ticket, since it looks like your board may not use the same processor as the DUE (SAM3X8E). I guess the problem is not exclusive to that processor.

[marcio-ao]

@SupremeFPV: You may want to add a comment to that thread saying you are seeing that on a smoothieboard, which I guess is a LPC1769 processor.

[Lafonen]

ill do that. thanks

[hectori4502]

I have the same problem with the MKS SBASE. LPC1768 TMC2130 SPI on all axes but disabling linear advance as SupremeFPV says it works.

[Lafonen]

What drivers are you guys running?

[fakcior]

TMC2208 on all axes with SKR v1.1

[HackingGulliver]

I had this problem all of a sudden on my MKS SBASE (with external TMC2130). Measuring the length of the step pulses with an oscilloscope I found out that the extruder step pulse width was about one tenth of the x/y step pulse width. I solved the problem by setting the minimum stepper pulse width in Marlin to 1 (i.e. 1 µs).

[Lafonen]

I had this problem all of a sudden on my MKS SBASE. Measuring the length of the step pulses with an oscilloscope I found out that the extruder step pulse width was about one tenth of the x/y step pulse width. I solved the problem by setting the minimum stepper pulse width in Marlin to 1 (i.e. 1 µs).

This also worked for me. Great catch.

running TMC2130 btw

[marcio-ao]

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?

[fakcior]

@marcio-ao It's possible, but then why it happens only on extruder?

[marcio-ao]

It's possible, but then why it happens only on extruder?

@fakcior: Good question. But I will add that we only see this particular issue with particular builds of our FW, not with all builds. These FW variations have miscellaneous differences having nothing to do with extrusion (such as dual nozzles vs. single). So one possibility is the pulse width is just on the edge of being valid and any slight timing variations in the code is enough to break things. It may even help with #12635, although I haven't tested that hypothesis yet.

[AnHardt]

Maybe only together with LinearAdvence. In that codepath is dos much less between setting and resetting the pin, than in the 'normal' code without LA

[marcio-ao]

@AnHardt: We had a dual-nozzle FW that exhibited no problems with LIN_ADVANCE enabled, but a single-extruder FW would show the problem with LIN_ADVANCE. But there were other differences between the build too, so it's hard to nail down exactly what what combination of factors were at play. All I know is that the workaround of setting MINIMUM_STEPPER_PULSE to 1 resolved the issue for us.

[marcio-ao]

It may even help with #12635, although I haven't tested that hypothesis yet.

See comment on #12635. Setting MINIMUM_STEPPER_PULSE to 1 seems to have a visible improvement on babystepping and may be a solution to that ticket as well.

[Lafonen]

Does it have this effect on babystepping regardless of if lin_adv is enabled?

[marcio-ao]

@SupremeFPV: I didn't test it with LIN_ADVANCE disabled, but it does appear to work with it enabled. Babystepping is completely independent of the stepper ISR (it actually is done in the temperature ISR), so it would be independent of LIN_ADVANCE too. However, since babystepping also sends pulses to the driver, it likely shares the code that would use MINIMUM_STEPPER_PULSE. This is what led me to suspect that perhaps #12635 could also be affected by MINIMUM_STEPPER_PULSE.

[marcio-ao]

@SupremeFPV: It would appear that the code that toggles the step pin is slowest with LIN_ADVANCE disabled, it is faster with LIN_ADVANCE enabled, and it is fastest of all for babystepping. This kind of makes sense, as babystepping is the simplest of the operations and probably involves no computation at all.

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