Firmware bug - retraction speed

Has anyone else run into this bug in Marlin where if you set the retraction speed too high, all of a sudden it will go either 1/2 or 1/4 of the speed commanded? It is described in this Ultimaker blog post:

https://ultimaker.com/en/community/2734-marlin-bug-the-myth-of-retraction-speed

I've know about this bug for awhile, but now that I've got a bowden extruder with a really long (650mm) tube, I'm wanting to speed up my retractions to the limit. Can anyone point me to a code fix? I looked at Ultimaker's release firmware and I can't find any evidence of the fix.

I hope this doesn't sound stupid but...

could you just up the speed to 4x what you want?

EDIT: It appears that Marlin will divide it until it's under the hard limit of 40,000 steps per second. Perhaps repetier-firmware or Teacup would be the best solution.

Edited 1 time(s). Last edit at 07/04/2016 08:45PM by epicepee.

I'd try halving the microstepping on your extruder driver, and halving the steps per mm on the E axis. That will allow you to retract twice as fast before hitting the limit (at the cost of some resolution, but really that won't make any difference).

Edited 1 time(s). Last edit at 07/04/2016 10:34PM by nebbian.

The issue with the bug, as I understand it, is the high accelerations and velocities used during retraction trigger a bug in the stepper driver related to the high speed mode switching wherein the 10000Hz interrupt is suppose to generate either 2 or 4 steps per interrupt, but for some reason it doesn't. A step rate of more than 10KHz will trigger the bug. There are work-arounds, but I was wondering if anyone had and actual fix for the code? The original Ultimaker post alludes to a fix, but I can't find it in their current release.

Install Repetier?

I ran into yet another bug with Marlin two days ago, where it would consistently trigger an overtemperature shutdown on the same part of the model (1.5 hrs into the print). This happened three times, with me carefully looking into possible causes each time.

After this I installed Repetier, spent an hour transferring settings and commissioning, and watched it sail past the problematic part of that model with no issues. It eventually finished the 18 hr print with no issues (apart from normal speed settings that needed a bit of tweaking).

I'd already changed to Repetier on another of my printers, so the learning curve wasn't that bad. It's a much better system imho.

Edited 1 time(s). Last edit at 07/05/2016 02:30AM by nebbian.

Also, if it helps, when I was tuning retraction in Marlin, I was getting much slower retraction speeds than I was expecting. It turns out that this was limited in firmware to something like 15 mm/s (can't remember the exact number). When I bumped this up to 40 I ended up with fast retraction. The crazy thing was that when using the buttons in Pronterface, I would get fast retraction, but when running a GCode file, the retraction was slow, despite both of them running on the same printer with the same firmware version.

Maybe it might be a good test, try opening Pronterface and see if you can get fast 30 mm/s retraction by using the buttons. If you can get that fast retraction then investigate the firmware settings.

I do know that with 95 steps/mm, 1/16 microstepping, 1.8 degrees steppers, and a direct extruder, I was getting 30-40mm/s retraction without any firmware hacks. This was using Marlin.

Edited 1 time(s). Last edit at 07/05/2016 02:39AM by nebbian.

nebbian: Thanks for the info. What may be going on in the difference between Pronterface and the G-code is they could be using different acceleration value. The bug I'm thinking of is dependent on both the accel and the velocity.

I actually just exchanged e-mail with David Breem who wrote the post about this bug in 2013 and he pointed out that it's been fixed in most every fork of Marlin. I checked the original source code I was using which didn't, in fact, have the fix and finally discovered my problem. (Code with the fix makes use of the variable "step_loops_nominal" in stepper.cpp, which is not found in the unfixed code.)

I may be wrong here but as I recall, the pulse signal interrupt timer for the stepper motors runs at x4 - if a motor speed signal exceeds the system limits it will drop the interrupts to x2. This may explain the speed differential being described above.

Regarding the firmware limits, the 4th parameter in the line below determines your E axis speed. If the value you set here goes beyond the system limits during print/retract time, the interrupt reduction will kick in as i understand it

#define DEFAULT_MAX_FEEDRATE {300, 300, 5, 25} // (mm/sec)

Bear in mind also, the E axis acceleration values you use - there is no need to run this at the default 10k. If you want to try an interesting experiment, try reducing the the E axis acceleration to a point where it becomes noticeable that it is slowing the print down. You might be surprised how low you go before you notice it affecting your print speed.