Retract / prime problems with enabled LIN_ADVANCE

[Sebastianv650]

I got some response from Lulzbot TAZ users who are using my pressure advance feature. I can reproduce the issue, but I have no idea where it comes from at the moment:

• With FW retract (default prime speed = 8mm/s) or no retracts, the print is good.
• With normal retract (Speeds tested between 20-35mm/s), the first ~2mm of the line are missing.
• With normal retract speed at 8mm/s, the print is good again.
• With FW retract prime speed = 20mm/s the line start isn't perfect, but not missing.
• Note that during retract/prime movements the pressure adjustment calculations are not active. The only difference to disabled LIN_ADVANCE is the seperate extruder ISR then.

The question are:

• How is it possible that we get different results between FW and normal retracts at the same prime speed? I thought the FW retract/prime movment ends up in the same action as a G1 E move?
• Why there is a difference between the separate extruder ISR and the stock one?

I will do some further analysis, but I'm not sad if somebody has some hints ;-)

Edit: Small update, a G4 P300 short wait after each normal prime event (at 20mm/s) heals the problem. 100ms wait or a M400 doesn't work. Hm..

[paulusjacobus]

Maybe we should start with looking at the Lulzbot TAZ default speeds/specs
and see where the obvious differences are? With those differences we should
ask the users to reduce them in gradual steps i.e. acceleration, speed
etc.and see where the issues pop up.

Just from speculation, I would say it is the ISR timing and the number of
tasks/features running at the same time. The processor gets overburdened.

I saw the comment

"With normal retract (Speeds tested between 20-35mm/s), the first ~2mm of
the line are missing.".

I noticed a missing line in the first perimeter layer print. I'll take a
photo so you will understand what I am saying. I installed the same
firmware on my second printer and lot's of checksum errors appear. I tried
to configure the baud rate in config.h but it got ignored, it still
connects at 250k. So I am a bit puzzled about that...

On 22 June 2016 at 03:14, Sebastianv650 [email protected] wrote:

I got some response from Lulzbot TAZ users who are using my pressure
advance feature. I can reproduce the issue, but I have no idea where it
comes from at the moment:

.) With FW retract (default prime speed = 8mm/s) or no retracts, the print
is good.
.) With normal retract (Speeds tested between 20-35mm/s), the first ~2mm
of the line are missing.
.) With normal retract speed at 8mm/s, the print is good again.
.) With FW retract prime speed = 20mm/s the line start isn't perfect, but
not missing.
.) Note that during retract/prime movements the pressure adjustment
calculations are not active. The only difference to disabled LIN_ADVANCE is
the seperate extruder ISR then.

The question are:
.) How is it possible that we get different results between FW and normal
retracts at the same prime speed? I thought the FW retract/prime movment
ends up in the same action as a G1 E move?
.) Why there is a difference between the seperate extruder ISR and the
stock one?

I will do some further analysis, but I'm not sad if somebody has some
hints ;-)

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
#4114, or mute the thread
https://github.com/notifications/unsubscribe/AIOTKQqtJjvOFgHpyqYW2mxHECTrg_5Gks5qOBwPgaJpZM4I6-EW
.

[thinkyhead]

The processor gets overburdened.

A distinct possibility. Be on the lookout for opportunities to optimize.

[Sebastianv650]

The TAZ 5 is using the following values regarding extruder speeds:
Ve-jerk: 10
max. e velocity: 40
Retract acceleration: 3000 (I lowered this to 2400 because I had problems with 3000 also with the stock FW)

I don't know values from other printers, do you see something unusual?

Even if it's related to the processor load or timing with the extruder ISR, why is it possible that FW retract acts different than the equivalent G1 command.. I think that's the first question I have to solve.

@paulusjacobus baud rate selection works fine for me, I'm using 115200 baud.

[Sebastianv650]

I'm very sorry, there is definitly something wrong with the timing on the ISR stepper! I did some back and forth dry movements with the stepper at various speeds by sending G1 commands. About 12mm/s is the maximum safe speed. If I try to move it faster, the extruder spins faster for the duration the move should take but it isn't finishing the esteps in this time. Therefore it continues to move until esteps = 0 but at a much lower rate.

I have not noticed that because I'm using FW retract where the default prime speed is set to 8mm/s. For retracts where I'm using much higher speeds, the effect wasn't noticeable due to the time the following travel move is needing.

The TAZ has a quite high esteps/mm value of about 800-850 (as far as I know most printers have lower ones), that means for other printers the maximum extruder speed value should be aprox. 12mm/s * 800 / your_esteppmm_value.

I will have a look if a step rate dependend double / quad stepping can solve this issue..

[paulusjacobus]

@Sebastianv650 great pick up. Will try to reflash my Mega to use a lower baudrate and see where it goes wrong. May be use even a lower setting than 115200 to troubleshoot it. Is the config.h file the only place where it is set or did I oversee something?

[thinkyhead]

Does #4123 (#4126) help?

[Sebastianv650]

Yes to change the baud rate, just copy one of the values from the comment above the baud rate setting inside the configuration.h. No further changes are necessary.
Pronterface will display wired characters when you try to connect with a wrong baud rate for example. Maybe other hosts have an auto select feature?

[Sebastianv650]

One note after another day of testing and playing with the code: At last with enabled LIN_ADVANCE, Marlin stalls at about 29.5kHz step rate. This limits the extruder speed on a TAZ 5 to about 35mm/s (29500/801).

Stalling is indicated by not executed extruder steps (extruder not moving) because the main stepper is consuming all of the available CPU time. I never reached this limit in normal printing with PLA, but I break it sometimes with nGen prints which uses k=150. This can be another reason for underextrusion at line starts - X and Y is moved by the main ISR, but the extruder ISR isn't fired.

To have a pressure advance feature that works save in every situation, I will implement another check in the next days that will do the folowing:

• Check if the esteps rate violates the extruder velocity limit due to extra esteps.
• If yes, limit the advance steps down to a value that respects the max. extruder velocity.
• Try to execute all the advance steps in the next ISR loop - remember that the advance step amount is highest at the start of a print move due to jerk, so the chance is good.
• For the special case where the print speed is so high that the advance steps can't be executed at all or partialy, this will lead to a print that looks like k was too low - but there will be no missed steps.

Another M command will be available to display a message if some steps had to be postponed. I hope I will not find any other conditions where the pressure advance can fail.

[thinkyhead]

This is the big challenge. We are hitting some limits with the lower-powered boards. Keep looking for any and all opportunities to optimize Stepper::isr, Stepper::advance_isr, and Temperature::isr. Perhaps we can save a couple of cycles by using attachInterrupt to directly set the ISR functions instead of calling them from ISR handlers as we do now.

[lonelymyp]

Marlin 1.1.0-RC7

same problem.
retract is extremely slow.
retract speed is about the same as normal feed, 5-10 mm/s

normal retract speed -200 mm/s

[mosh1]

I'm having a similar issue - essentially the extruder is stalled when printing fast (120mm/s) on RUMBA w/ 1/16 microstepping on x&y and LCD and LIN_ADVANCE enabled...

[thinkyhead]

Because LIN_ADVANCE requires a second interrupt, and because high speed moves don't leave a lot of time between stepper interrupts, the combination of high-speed printing with advance extrusion might just be pushing your CPU to its limits. That isn't a bug, it's just a limitation.

[mosh1]

I ended up fixing my issue by bringing down my steps/mm on Y from 360 to 90, freeing up CPU.

[Roxy-3D]

I ended up fixing my issue by bringing down my steps/mm on Y from 360 to 90, freeing up CPU.

We need to get on to a 32-Bit platform just for things like this. For sure the Delta's would do better with more CPU cycles available!

[boelle]

since this one is VERY old and for the fact that you can still have discussion with the issue closed i would close it to shorten the list.

[github-actions]

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.