TMC2660 LPC1769 Linear Advance issue

[stefan85]

I have an LPC1769 with TMC2660 drivers (this includes the extruder motor). Everything works fine but when I enable Linear Advance, the extruder motor does not turn anymore. I can hear it being enabled but it does not rotate.

When I disable linear advance again (hardcoded), it works.

Does anyone experience the same issue?

[stefan85]

Just an update. I fixed the issue by increasing the MINIMUM_STEPPER_PULSE to 1. After this, everything is fine.

[p3p]

I'm glad you worked that out, I wasn't aware there was any default to get a minimum length pulse on the LPC176x boards but that does seem to be the case for TMC drivers, We should probably change that.

[stefan85]

I don't have a probleem with linear advanced disabled. Only when I enable it.

At the moment I don't use linear advance because I am using a bowden setup. I am seeing slow ramp up and down in the movements which I don't really like.

[gloomyandy]

I think there is an issue with the timing calculations and how gcc optimisation on the LPC176X impacts it. @ejtagle commented on this some time ago. I think the same problem means that 8825 drivers need a longer minimum stepper pulse than the default. At I guess I'd say that the inclusion of linear advance introduces another optimisation/timing combination which is why you only see it in this case.

[p3p]

If I remember correctly there is another code path that handles linear advance steps that does less (no) computation during the pulse, this means that with linear advance the lower bounds for pulse duration (on the extruder) will be shorter (lower than I can measure reliably on a 25Mhz logic analyser) causing issues like this.

[ejtagle]

Yes, it is a GCC optimization "problem". GCC tends to precompute variables outside of loops, depending on register pressure. So, wild changes in timing are possible. IO PORT access is marked as volatile, so the order of writes and the written values will not be altered, but the code in between will be moved, thus modifying pulse timing. As said previously, on 32bit targets, we could add delays between edges without issues, but on AVR, we cannot, as the stepper is already consuming too much time This is a case where having the exact same codebase for AVR and ARM plays against us...

[gabtremblay]

Messaging to confirm that this problem also affects TMC2130 on Re-Arm.

[boelle]

@stefan85 still an issue?

[stefan85]

Not an issue when I increase MINIMUM_STEPPER_PULSE

[boelle]

@thinkyhead so maybe the default value is to low?

[gabtremblay]

I think it is an issue, yes there's a workaround, but it's not the documented and expected behaviour.

[boelle]

i agree that if a workaround is needed something is not right

but it could be as simple as default values are just borderline from being correct

you know like with computeres just as much as a comma wrong and it stops

[thinkyhead]

thinkyhead so maybe the default value is [too] low?

The MINIMUM_STEPPER_PULSE value is set based on the slowest stepper type. If the recommended "safe" values appear to be "too low" that would tend to indicate an electrical noise problem on the board.

[AnHardt]

so maybe the default value is [too] low?

If the recommended "safe" values appear to be "too low" that would tend to indicate an electrical noise problem on the board.

There are more possibilities:

• The times are based on the datasheets. Driver could be slower than that. Or we misinterpreted the datasheet.
• Pins/wires could have added (hidden) capacities preventing the input from rising in time. Like in reusing a former temperature or hardware denoised endstop pin.
• The delay function may not wait the ordered time. We already had that problem with the STM32s.
• A combination of the above.

[gloomyandy]

I think the post above from @ejtagle hints at some of the other things that may be going on. The current code is not really designed for operation on a fast 32bit system, particularly one in which the timing can be rather variable due to how the flash accelerator works and how gcc optimisation can impact things. It probably needs someone to hook up a scope and toggle some pins at various points to actually measure what is going on. I'd certainly second that using endstops and temp pins may also cause problems, I saw this very clearly when attempting to use those pins for software serial use. The resulting pulses are a horrible shape compared to those from a "normal" pin.

[thinkyhead]

We have a lot more timers at our disposal on ARM, so maybe there's a timer-based solution that can produce more regular signals.

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