Marlin: Linear Advance bug — occasional backwards motion

[thinkyhead]

I have received a bug report via Twitter:

"Linear advance code is messed up in bugfix-1.1. It will actually drive the extruder moter too fast/backwards intermittently. I now have a working Marlin 1.1.8/Einsyboard/PrintrBot Simple by using pinMode/digitalWrite(HIGH) patch for the TMC2130 CS pins in setup()."

[Sebastianv650]

Well, that's not much information. I would think that the extruder jerk setting might be too high as this limits the speed. Which k is used, do we habe a sample gcode that triggers the problem at a specific point?

[thinkyhead]

I agree it is vague. This issue is looking for things to tell them to try as much as anything. Perhaps we can get them to solve their own issue. I asked whether the problem also exists when using regular stepper drivers (just swap them on your Einsy! 🤕 ). And I can propose that they try using MINIMUM_PULSE_DELAY and see if that helps.

[Sebastianv650]

It will actually drive the extruder moter too fast/backwards.

This is not very logical, or I get it wrong. The extruder will run approximately at the same speed forward and backward, and the filament spring force is helping it during the reverse running. So I would expect seeing problems during forward running phase, not during reverse.
Is this related to v1.5 code for sure? If yes, does he use a new K factor? The old one would be much too high.

[thinkyhead]

I will ask her (well, I guess "Kelly" may be a guy's name) to sign up to Github and join this issue.

[thinkyhead]

"Yeah, I have the RAMBo pins file. I don't know if it affects non-TMC2130 users. There were certainly a lot of changed to the linear accel code between 1.1.8 and current bugfix-1.1.x, my hunch is it's a math (overflow) problem since it seems to drive the extruder backwards."

"BTW, 1.1.8 is working fine. I did tweak stepper_indirection.cpp a bit to eliminate high-pitched squeal in spread-cycle mode. hysteresis specifically. Also borrowed the knowledge from @josefprusa Marlin port and configured the stepper a bit differently for extruders vs XYZ."

"It'll do the same thing at the same time on a given print. It's like this. On a long move, it will start off turning the extruder forward (but too fast) and then it will switch to running the extruder backwards (also too fast)."

[thinkyhead]

Is it possible this could be improved by … ?

- static int8_t e_steps;
+ static int16_t e_steps;

[cbxbiker61]

I'm a guy. Now if you met me in person and mistook me for a woman....i'd have a problem.

[cbxbiker61]

BTW, I just looked at the TMC2130 stepper debug info with 1.1.8 and I have no signs of overheating. Last print came out nice...100mm/sec linear extrude.

[thinkyhead]

In homophobic USA your name is not too popular for boys. But I knew a guy from Jamaica named Kelly who had the best hash in Boston.

[thinkyhead]

So when you build 1.1.8 you're using the same Trinamic library as we use for bugfix-1.1.x. If there's a problem with heat in the bugfix but not in the release we should definitely look closer. I assume you have tuned your defaults the same for both.

[cbxbiker61]

No, thinkhead, i wasn't saying their was a problem with overheating in bugfix-1.1.x. You had mentioned on twitter the TMC21XX's are susceptible to overheating...just saying that my current config seems to be good and no signs of overheating here. Yeah, both my configs are the same between versions.

The TMC's are so tuneable... I'm not surprised with some settings they could be prone to overheating.

Also, yes, I'm using the same TMC2130 drivers for both.

[cbxbiker61]

I'm currently printing a sitting bob-omb at 100mm/sec linear extrude, the printer sounds real good.

[thinkyhead]

Ah, ok. When you posted a positive review of your print with 1.1.8 I took it as an implied "however, the bugfix branch… $&$%$" Thanks for clarifying.

[Sebastianv650]

I'm a little bit confused as @thinkyhead closed this now. Does this mean there is no problem at all or only no problem with overheating?

@thinkyhead static int8_t e_steps should be no problem as this one will always be well below 10.

[cbxbiker61]

Sabastianv650, there is still a problem, yeah I think he made a mistake by closing it.

[Sebastianv650]

OK back to business. You are aware of the changed K unit in the current rcbugfix branch? Because you stated "On a long move, it will start off turning the extruder forward (but too fast) and then it will switch to running the extruder backwards (also too fast)."
Sounds like K is just too high.

[cbxbiker61]

K is set at 30 for PLA. This is being set by Slic3R PE. What does 30 translate to in the rcbugfix branch?

[cbxbiker61]

It would nice to do write an old to new K factor utility. I could write it in Python if I had the algorithm.

[Sebastianv650]

See the documentation for LIN_ADVANCE v1.5: http://marlinfw.org/docs/features/lin_advance.html
I don't know the exact translation between old K and new one, but I start to get a feeling for the values. You wrote you have a printrbot simple metal, with PLA I would start with K = 0.06 to 0.08. Use the calibration pattern generator on the documentation page to find the perfect value. I will provide a calculation on the docs page for a good starting point when I have more datapoints. I have one, but I don't want to publish something that could be wrong.

[cbxbiker61]

OK,

Range checking on M900 should be added. I'd say just ignore it if it's not in the allowable range since this could be a major trouble point for those of us that start off with a "standard" Slic3rPE config.

[Sebastianv650]

I wasn't aware that there are any default profiles available which enables LA. In the Prusa FW I'm checking for a range as it was requested, but the problem is the user will never notice it when printing from SD card (and also most likely will not see the note when printing over serial). So I have the choice generating issue due to a "not functional" LA or "LA goes crazy" ones like this one. Both are not perfect, I'm open for advises.

[thinkyhead]

I wasn't aware that there are any default profiles

The Wanhao Duplicator 6 config has LIN_ADVANCE enabled, but with K set to 0, probably because the submitter had it that way.

[thinkyhead]

K = 0.06 to 0.08

Given the large change, it may do well to either:

• Sanity-check for large values in the old K range (using float-compatible static_assert) and tell users in the error message that the value range has changed, or
• Create a new LIN_ADV_K setting that replaces the old LIN_ADVANCE_K setting, and throw an error when the old one is seen, giving a similar message.

We've been through some of it before, when changes to the Jerk code resulted in the values needing to be cut by half. Many many reports from people who had no idea this was the case. Had we renamed the setting and given an error about changing to the new name (and range) it might have prevented many of those issues.

[Sebastianv650]

@thinkyhead I underestimated the problem with the different K meanings. I see the problem here and also on PrusaFW (where I already implemented another commit in the open PR for a K check).

I will create PRs for 1.1 and 2.0 including a sanity check so no K value > 10 can be compiled in the FW and also a check for M900 so only values between 0 and 10 are accepted.

I guess there will be issues created even with that as people might try to set their old K value via M900 in the start gcode which would result in no visible reaction (beside a note over serial), but better than nothing.

[cbxbiker61]

thinkhead, yeah that would be fine in the source code.

The problem with current Slic3rPE is that it sets it per filament type. This will be a pain in the ass for those of us that have a Marlin 1.1.9+ machine and a Prusa MKx printer in the same environment. I like that Slic3rPE sets it per filament, seems like a nice way to handle it, but it's a problem here.

Prusa PLA 1.75mm.ini:

start_filament_gcode = "M900 K{if printer_notes=~/.PRINTER_HAS_BOWDEN./}200{else}30{endif}; Filament gcode"

[cbxbiker61]

Of course if Prusa's firmware was revved to use the new K values, everything would be fine.

[Sebastianv650]

@cbxbiker61 I don't think that's a problem. As soon as they merge the PR and publish an official release, they very likely will change their default values inside Slic3rPE. And users pulling non-published code should be advanced enough to read the notes and documentations.

[cbxbiker61]

Sounds good.

[thinkyhead]

Note that we don't have to worry about sanity-checking the K value loaded from EEPROM. With the new firmware loaded, the EEPROM will need a reset anyway. Even if savvy users use M503 S0 before they flash the new firmware (so they can use the output to restore the old EEPROM values) the new sanity check in M900 will catch old value and prevent it from being applied.

[cbxbiker61]

Everything seems to be working fine here. I tuned my PLA settings to 0.07 and the results are good.