Dynamic speedup? (autospeed, pressure advance, ..)

Dear Slic3r-users,

we own a Kossel Mini printer (bowden extruder) and observe strange printing behavior during larger-area jobs [1]: While doing solid infill, the printing speed continuously increases and decreases within longer paths. The extruder feed speeds up and down simultaneously. It seems as if Slic3r wants to spare time. The problem: when decelerating again, too much filament is coming out, resulting in overflowing infill and awfully failing prints!

Now I cannot find a setting associated with such behaviour. Pressure advance (we use a parameter value of 0.2) should only pre-advance filament. Autospeed should just prevent varying extrusion speeds! All extrusion widths are set to 0.4 (= nozzle diameter) by now.

It would be nice if someone could help!

[1] [www.thingiverse.com], the front1.stl

I suspect that the behaviour is caused by your printer's controller rather than Slic3r. I'm not sure how the acceleration parameter works on a Delta printer - whether it relates to the motors or the head. If it relates to the motors, I think that speed change due to acceleration and deceleration will be exacerbated the further the head is from the centre of the bed. Perhaps try playing with the acceleration settings to see if you can get an improvement.

Dave

Hi Dave,

thanks for your reply! I will look for the acceleration parameters and report back when I could validate your suspection.

Regards
ribaldos

We made a few tests: the strange behavior does not seem to be caused by the acceleration parameters. The default acceleration is 9000 mm/s², which I suspect is the end-effector acceleration. We tried 11000 mm/s² but it brought no improvement.
What is really weird: there are circumstances in which the trajectory is driven off cleanly and without speed changes. We observe the strange behavior mainly on the first layer (200% extrusion width and 30% speed) and "thick infill". The latter means infill with only one path but broader extrusion width (which Slic3r uses when perimeters seem too narrow for other infill techniques).

We uploaded a video to clarify the behavior [1]. Even circles get screwed by the sudden acceleration, but only when in outer bed areas.

We appreciate any help.

[1] [youtu.be]

Ah, I think I know what this is.
What drivers are in your controller, Drv8825 or a4998?

---

My printer: Raptosaur - Large Format Delta - [www.paulwanamaker.wordpress.com]
Can you answer questions about Calibration, Printing issues, Mechanics? Write it up and improve the Wiki!

The printer is from think3dprint3d, I think they used the A4982 driver for our Kossel Mini rev 2.
Still, could it really be the driver? The extruder speed seems to adapt to the strange acceleration phenomena, which in turn means that Slic3r or the firmware knows about them. However, the stepper circuit is feed-forward only.
If it helps I will recheck the driver chip this evening.

If it's a rev 2 Mini Kossel then it has Arduino/RAMPS electronics and Marlin firmware. I don't think pressure advance has ever worked properly in Marlin, so try turning it off. Also, if you are printing over USB, try printing from the SD card instead.

---

Large delta printer [miscsolutions.wordpress.com], E3D tool changer, Robotdigg SCARA printer, Crane Quad and Ormerod

Disclosure: I design Duet electronics and work on RepRapFirmware, [duet3d.com].

Okay, I will try to disable pressure advance. However, shouldn't this option only affect the extruder speed? Furthermore it's already compiled by Slic3r. So you mean the Arduino is just too slow to process the commands created by pressure advance?

Edit: we already print using SD card

Edited 1 time(s). Last edit at 01/06/2016 05:06AM by ribaldos.

I very much doubt that it is a Slic3r issue. Check the G-code, but I think you will find that each straight line is printed using a single command (with a single speed and extrusion distance), in which case the varying speed over the line must be caused by your controller.

Dave

We tried disabling pressure advance but without any improvement. PA only seems to insert a few additional extruder feeds.
I uploaded a new video showing the acceleration while printing a skirt [1]. This time I filmed the extruder wheel which accompanies the strange head acceleration. I also attached the gcode used for the print on the video: indeed the feedrate seems not to be changed during the print, however I am not very proficient with gcode.

Currently the matter doesn't make sense for me. The acceleration of single steppers is way below maximum acceleration. The extruder feedrate adapts to the ominous speed changes, so at least the firmware knows about something..

3D-printer Sherlock, please help!

[1] [youtu.be]

OK, I've analyzed the gcode in my debugger.

All the print moves in that snippet are printing at 3 mms, yes, that slow. If you're using 1.75mm filament, the average volume per second (mm3/sec) is 0.80. That's very minimal.

To see the print speed used for instance, take this line at the beginning:

G1 X-23.258 Y87.338 E9.43297 F180.000

The F180 = 180 mm/min, so 3mm/second. If you are seeing speeds over that for the first layer, it's not coming from the gcode! It sure seems to be printing much faster than 3mm/sec in places.

At just 3 mm/s for the print moves: normal acceleration settings would make little difference.

Moves are at 145mms.

You can ignore this:
Just for the heck of it I'll mention: If you had Drv8825 drivers then I've seen a video that shows similar behavior. I've linked it on the Shifted Layers / Offset Layers / Missed Steps Wiki page I compiled. See problem 29, and the link on the right side. So I think it would still be worth while knowing for sure if you have Drv8825 drivers or not.

Having said that, pay attention to this:
- It's time to attach your firmware's config file.
- Your printer is slowing way down when it has many tiny segments to print, and speeds up on the long segments.
- Also, just wondering if you have a graphic display?
- Preliminarily, I think your firm firmware is quite messed up. If it was me I would get a copy of Repetier, and see if someone has a configuration.h for your model printer to get a head start.

---

My printer: Raptosaur - Large Format Delta - [www.paulwanamaker.wordpress.com]
Can you answer questions about Calibration, Printing issues, Mechanics? Write it up and improve the Wiki!

A slowdown on many short segments is usually due to either a slow interface (e.g. printing directly via USB or serial) or the printer's controller having a relatively slow CPU that is unable to process the commands as fast as they are executed.

Dave

Thanks for your answers! We did some further investigation. The firmware is the same as the latest git commit from Think3DPrint3D [1] except the calibration parameters. I rolled out the firmware anew while using the latest Arduino (1.6.7), switching to GCC -O3 optimization and overwriting EEPROM with default settings. However, we've still the same behavior.

As for the theory with computation of the many small segments: at the beginning of the long segment in the above example, the printer is still slow. Then it accelerates during the the same move-operation! Also, our printer is able to print very fine detail (finely grainded honeycomb infill) quite fast without slowing down.

Then I did a few tests explicitly exposing the really weird (!) behavior. I used Pronterface to re-run the long trajectory from the gcode manually. First I only moved (no extrusion) with the 180 mm/min. Everything fine! Then I re-run it with the same amount of filament used above. This could reproduce the behavior! I reduced the amount of plastic for the same trajectory and it was better again!
Okay, so it must be something mechanical (plastic hardening > friction with nozzle). But Nope! Doing the same with a Z-Offset (4 mm) gave the same behavior. I recorded it on video, please have a look [2] (also take note of the sound and the jerking). When using a very high extrusion rate, the effector moves constantly fast right from the beginning instead of accelerating in the middle of the plate.

It should be clear now that the problem has nothing to do with Slic3r. It seems as if the extruder feed somehow interferes with the speed of the other motors. However, it doesn't seem to take place on hardware level. The firmware seems to "know" about it because there is no loss of steps and both speeds, effector and extrusion, are scaled simultaneously. Thats why I named the thread "Autospeed" (feature) in the first place.

Some further thoughts: prints usually run fine except on trajectories with high extrusion width. This includes first the layer and broad single-path infills. This observation would match the upper phenomenon of speed interference with extrusion rate. But when it's not the hardware itself while no one else is having these problems with the same software [1], could some electrical resonances, e.g. from the stepper drivers accelerate the ATmega clock?! A globally higher CPU-speed could explain the behavior.

Does someone else have an idea?

[1] [github.com]
[2] [youtu.be]

You've done some very good detective work there.

I should always say "I think", or "it appears" when diagnosing, there's always something new...

Observations:
a) "It appears" the slowdown happens when printing out near the edge of the build plate.
b) That version of Marlin is 2829 commits behind the main MarlinFirmware. All bets are off...

A few questions:
1) Please post the exact gcode you used in pronterface
2) Can you repeat the test, make it start at the edge again, but make it stop near the middle of the build plate? Does it slowdown near the end?
3) Please attach your configuration file. I know it's virtually identical to the github version, but still would like to check things.
4) Are you using a graphic lcd, or a regular 4 line lcd?

Your first videos had a long line that stopped nearer the middle, and that line did not have the big slowdown at the end. That still makes me think it's not an acceleration issue in firmware - and indeed the firmware's accel values are fine.

Hi Paul,

I used "G92 E0", moved to the outer left and started testing by alternating use of "G1 X-57 Y51 E17 F180" and "G1 X84 Y-45 E17 F180". The "E17" was replced by "E7" or "E30" or similar to test varying extruder feed.
I also just tested your point 2) by issuing "G1 X0 Y0 E8 F180" from the outer left. The same behavior as before, except that it suddenly stops in the middle without decelerating again. I want to note again that the fast speed is abnormal, not the slow one in the beginning.
We use a 4 line lcd, not a graphical one. I attached our current Marlin Configuration.h.

Thanks for looking into this!

You're doing an awesome job testing.

Quote
ribaldos
The same behavior as before, except that it suddenly stops in the middle without decelerating again.

This completely confirms my suspicion. It has nothing whatever to do with acceleration.

Quote
ribaldos
I want to note again that the fast speed is abnormal, not the slow one in the beginning.

Yes, that's quite right.

So here's what "I think" is happening. Out near the edge there is much more calculation happening, and an 8-bit microcontroller at 16 or 20 mhz doesn't do 16 or 32 bit (don't recall witch) square roots very fast... I think it's getting behind, and then catching up.

So for your next test, change:
#define DELTA_SEGMENTS_PER_SECOND 200
to
#define DELTA_SEGMENTS_PER_SECOND 50

Do the original test, from far outside to outside and let's see what happens. If that fixes the problem you will want to try increasing that value until you find the point that it starts failing, and then back it off.

For a good discussion of this see this thread:
[forums.reprap.org]

I thought of the DELTA_SEGMENTS parameter as well, but it wouldn't explain the speed-up. Except there is a "catching up" mechanism in Merlin as you mentioned but I rather don't think so. However, I gave it a try using values of 50, 40 and even lower but it still showed the same behavior. I also tested removing the stepper driver for the extruder to check for electrical feedback but it still showed the acceleration. Without the extruder running, everything is fine (as written earlier). So it seems to be rather a software issue. However, the guys from T3P3 have read this thread after I emailed them and never observed such behavior before with the same software. So they suggested replacing the Mega board (which they will send from GB tomorrow, thanks!). Corrupted memory indeed could account for the weird behavior. I wonder if there is any memcheck for AVR?

Apart from that I've run out of ideas by now. I hope it's "only" the Mega board. It could also be a defect RAMPS electronic with crosstalking stepper paths or similar..

Edit: it's the A4982 driver

Edited 1 time(s). Last edit at 01/10/2016 01:30PM by ribaldos.

Well I hope a new board fixes it.
If it doesn't you could try the latest version of Marlin - do a file compare and transfer your settings to the newer config file.
Over 2800 commits is a lot of bug fixes.

Is there a separate acceleration parameter set for the extruder? If so, and it is too low, that would explain everything. All speeds have to be made relative to the most restricted axis. If the extruder reaches its acceleration limit it would have the effect of slowing all the other moves.

Dave

Quote
dmould
Is there a separate acceleration parameter set for the extruder? If so, and it is too low, that would explain everything

I think this has been ruled out for the following reasons. What do you think?
- The config file shows all acceleration settings are the same (the config is attached above)
- The manual test he performed starting at the outside and going to the center shows that acceleration is not involved: "it suddenly stops in the middle without decelerating again". In this test the same acceleration must be present at both ends of the segment (since there is no prior or subsequent segment).
- Note that the feedrate is only 6 mm/sec. At the accel he has set (3000mm/min^2 for all axes) it will only take 0.12 seconds to reach that speed (not counting J.D.).
- The feedrate is increasing above the 6mm/sec that was commanded by the time it reaches the center (it appears to be catching up).
- This only happens at low speed - the opposite of what you would expect if a low extruder accel was involved.

The mysterium continues.. The replacement Mega2560 arrived today and I tested it... Same behavior.
I cloned the latest RC3 Marlin firmware and transferred the settings... Same behavior.
Currently I am trying to exchange PIN_E1 and PIN_E0 in firmware as well as the drivers and connections on RAMPS to test the board. However, it shows really weird behavior e.g. z moving up when giving an extrusion command. I will conduct further tests when I have time.

Any other ideas?

You've eliminated a lot of possibilities, and replaced the controller... except the Ramps, and the firmware type (still Marlin, but up-to-date).

You used the new Config file and transferred your settings, right?

Quote
ribaldos
Currently I am trying to exchange PIN_E1 and PIN_E0 in firmware as well as the drivers and connections on RAMPS to test the board. However, it shows really weird behavior e.g. z moving up when giving an extrusion command. I will conduct further tests when I have time.

That's odd. I wonder about interference. Do you have all the wires from the controller bundled together (bad), or shielded? See [forums.reprap.org]

Not too many things left...
Repetier has a nice configuration tool for creating a custom config file and download bundle on their website. That might make it easier to migrate if you need to.

---

My printer: Raptosaur - Large Format Delta - [www.paulwanamaker.wordpress.com]
Can you answer questions about Calibration, Printing issues, Mechanics? Write it up and improve the Wiki!

Okay, the behavior from my previous post resulted from the jumpers I didn't transfer to the new E1 port. Now it works........ like before

The wiring is exactly as suggested in the T3P3-Documentation. Both electronic boards are not exposed to excessive EM.

The longer I think about it, the more I assume it's the RAMPS board allowing some cross-talking between the stepper drivers. When you again look at the last video, before acceleration it starts jerking a bit whereas the fast speed is kind of a "continuous jerk". I remember, in Q3/2015, when we bought the printer set, one stepper driver has been defect (sometimes working, sometimes jerking, sometimes not working). Maybe it has something to do with it.

Okay, here are the news.

First: the new RAMPS + stepper drivers I got from T3P3 didn't do it. We had exactly the same behavior as before.

I remembered that the printers user interface (Panel One) sometimes did respond very slowly when using the knob. So I produced the upper "bug" and tried to navigate the marlin menu. I observed that during the accelerated periods, the cursor was not responsive. When the movement was going back to "slow" again (in the outer areas), menu navigation had zero lag.

Then I gave the DELTA_SEGMENTS_PER_SECOND (DSPS) another try, setting it to as low as 20. Indeed, everything now worked better and it was "slow" the whole time. I tried 30 and there was the same behavior again (even with O3-optimization).

As a consequence: it seems to be "Marlins fault".

I didn't think that the value needs a TENTH of the suggested value of 200. Anyway, this kind of acceleration problem seems to be more like a bug than anything else. For 16 MHz (16 MIPS with AVR!), 30 additional square roots per second are not *that* much. And the fact that it depends on the extrusion speed? Extrusion pulses to the stepper currently rather seem to be implemented in software than using the Megas periphery (timer/counter).

I made a few additional tests: the abnormal behavior begins when the extrusion is higher than 5 mm within a distance of 60 mm @ 180 mm/min. When beginning in the middle of the bed, the speed is accelerated right from the beginning, so it has not much to do with "outer bed areas".

I really wonder why nobody else is mentioning this. All I read is that on too high DSPS, there is a buffer underflow, resulting in stuttering. In our case, however, things get *faster*! I suspect that lowering the DSPS only indirectly compensates this "bug" by freeing CPU time.

What now? Is printing at DSPS=20 the way to go? Try Repetier? Issue a bug report?

This is a tough one. I've been thinking about it, and I think it's a bug also, however:

- Have you made sure you have the Marlin specific library settings in the Arduino IDE, and the IDE version they are using?
[github.com]

- Have you tried it with the PanelOne commented out? Perhaps the code for that display has a delay in it.

- When I used Marlin first, and then Repetier years ago I found that Repetier's step rate was considerably better, using their quad-stepping feature.

I didn't use the Marlin definitions for Arduino before. It is never mentioned in any tutorial, including t3p3's. However, using them now with Arduino 1.6.7 didn't help me.
I also disabled the Panel One. However, still the same behavior.

So should we use Repetier?

Could someone try to reproduce this bug on his Mega-Marlin-RAMPS-Delta? Go into x-direction by 60 mm using 180 mm/min and extrude 7 mm of filament. And have DELTA_SEGMENTS_PER_SECOND at least at 30.

Edit: I just tried printing the big part mentioned in my first post: it even shows the behavior with DSPS = 20

Edited 1 time(s). Last edit at 01/31/2016 10:20AM by ribaldos.

YES, I recommend using Repetier. I will cost you nothing but a little time.
Since you know all your delta parameters, their web page wizzard will make it easy to input them, and it will create a customized setup. Then just compile it and go. Use the quad stepping feature too.

I have a Smoothieboard so I can not test with marlin. You may be able to have someone test this through the Marlin github site.

After a few more tests I've posted a bug report on github [1]. I hope, someone can confirm the bug soon.

In between I tried to move to Repetier, however it's not that easy. What would be the best approach to use the PanelOne from t3p3 with Repetier? Is there a firmware-side library for similar panels which just needs adjustment of Pins?
Generally, is it okay to just define Ramps and look if it works or do I have to conduct a pin-wise check of all periphery (Steppers, Heaters, Fans)?

[1] [github.com]

Repetier may get you further than Marlin, but if you are serious about running a delta printer, consider buying a 32-bit controller board. T3P3 switched to Duet electronics for their Rev 3 Mini Kossel.

---

Large delta printer [miscsolutions.wordpress.com], E3D tool changer, Robotdigg SCARA printer, Crane Quad and Ormerod

Disclosure: I design Duet electronics and work on RepRapFirmware, [duet3d.com].