Marlin: Printing slows right down randomly when using the second toolhead (Buffer problem)

[wywywywy]

Hi all,

This is the first time I use the second hotend on the E3D Chimera since Marlin RC8. My first hotend has a 0.4mm nozzle and works reliably. The second hotend has a 0.6mm nozzle.

I have not tried a print with both hotends at the same time yet.

The problem is, while printing (a calibration cube in this case) with the second hotend, it randomly slows down to less than 10mm/s for a few seconds. The extra heat would then obviously ruin the quality of the print.

Any ideas why this is?

I got a feeling it's something to the buffer being empty but I don't know how to check.

The gcode looks fine from what I can tell. Full gcode here - http://pastebin.com/dN2XfTiW The first layer works fine, the problem starts at the second layer.

I have tried rebooting the printer and Octoprint.

Using RC8 BugFix 30/12/16. MKS Gen 1.4 board. DRV8825 at 1/16 stepping. Sliced with Simplify3D. This is a VORON core-XY.

RC7 BugFix 24/10/16 worked fine.

I really don't get why toolhead0 works but not toolhead1.

Configuration.h here - http://pastebin.com/PUdsui8u

Thanks.

[FireBookDuo]

I can confirm that I'm having the same problem when using the second extruder under RC8. Printing with the primary extruder is fine, but when using the second extruder there will be random slowdown while printing.

Both speed and acceleration get very slow, and the jump back to full speed.

When using a 2 into 1 hotend config (i.e. e3d Cyclops hotend) the slowdowns do not manifest.

I went back to RC7, and the problem is no longer present.

Hardware:
Flashforge clone cartesian
Sainsmat 2in1 Board (RAMPS clone)
Allegro A4988 drivers in 1/16 mode
e3d Chimera

[wywywywy]

Just tried the latest RC8 BugFix 14/01/17. Same problem.

I've uploaded a one-minute video here to show the problem - https://www.youtube.com/watch?v=emRwJ5q1D3M

First slow down from 0:05 to 0:23
Second slow down from 0:31 to 0:40 (and stopped completely at 0:39)

The sound changes when it slows down.

[wywywywy]

I just disabled "#define SLOWDOWN" and completed the above g-code, without any problem.

So the problem is definitely related to the buffer.

But why does the problem happen only on toolhead1 but not toolhead0? Does it update the LCD more frequently when using toolhead1?

[cosmith71]

Same issue here with the latest RCBugfix. Disabling #define SLOWDOWN fixes. Is there a downside to doing this?

[thinkyhead]

Disabling SLOWDOWN is probably harmless. It's not even allowed for use on a delta.

Are you also using DISTINCT_E_FACTORS?

[cosmith71]

@thinkyhead, thanks for the reply. I am not using DISTINCT_E_FACTORS.

[cosmith71]

This problem reared its ugly head again, even with SLOWDOWN disabled. It started out OK, but started to slow down (just Tool 1, second head) on about the 3rd or 4th layer.

[Eagle2301]

I'm having the same problem when using the second extruder under RC8.
Printing with the primary, third or fourth extruder is fine.

Thanks.

[cosmith71]

Still present in the Bugfix downloaded today. Seems to only be during extrusion moves. Travel moves are at regular speed.

[thinkyhead]

Just the second extruder, and not the 3rd or 4th…. That is interesting. SLOWDOWN relates to the GCode buffer getting half full, and not to the active extruder, so there's definitely some strange crossover occurring. Maybe a buffer overflow. It will require some careful scrutiny of all SLOWDOWN-related code. (Which is this:)

// Slow down when the buffer starts to empty, rather than wait at the corner for a buffer refill
#if ENABLED(SLOWDOWN) || ENABLED(ULTRA_LCD) || defined(XY_FREQUENCY_LIMIT)
  unsigned long segment_time = lround(1000000.0 / inverse_mm_s);
#endif
#if ENABLED(SLOWDOWN)
  // Segment time im micro seconds
  if (moves_queued > 1 && moves_queued < (BLOCK_BUFFER_SIZE) / 2) {
    if (segment_time < min_segment_time) {
      // buffer is draining, add extra time.  The amount of time added increases if the buffer is still emptied more.
      inverse_mm_s = 1000000.0 / (segment_time + lround(2 * (min_segment_time - segment_time) / moves_queued));
      #if defined(XY_FREQUENCY_LIMIT) || ENABLED(ULTRA_LCD)
        segment_time = lround(1000000.0 / inverse_mm_s);
      #endif
    }
  }
#endif

[thinkyhead]

Try this and see if it makes a difference:

-       #if defined(XY_FREQUENCY_LIMIT) || ENABLED(ULTRA_LCD)
+       #if defined(XY_FREQUENCY_LIMIT)

[cosmith71]

I uncommented SLOWDOWN and gave this fix a try. It was intermittent and only for a few seconds at a time, up until layer 8 when it became constant (still only on extruder 2).

I'm testing with this:
http://www.thingiverse.com/thing:1560492

[cosmith71]

Does this fix address the fact that the slowdown occurs even with SLOWDOWN disabled?

[cosmith71]

Noticed today that the slowdown also occurs when _only_ using the second extruder, and with a two extruder job.

(Edited for clarity)

[rokpedler]

Hello,
I decided to join this forum after realizing that I'm having the exact same symptoms on my Makerfarm 10" i3V after installing an Itty Bitty dual extruder. Since that upgrade, I also changed out my power supply, RAMPS 1.4 board and changed to DRV8825 drivers. If reverting to RC7 eliminates the problem, that's fine. But I would rather move forward. I'm by no means a developer but you're welcome to anything I can send. Thank you for all your hard work.
Mike

[thinkyhead]

Still investigating. Hopefully we'll figure out the cause and have a solution soon. It's helpful to know that it's not specifically related to SLOWDOWN or DISTINCT_E_FACTORS.

Incidentally, does _enabling_ DISTINCT_E_FACTORS make any difference?

[rokpedler]

I haven’t tried because it didn’t apply to my situation, but I’ll give it a try and let you know.
Thank you,
Mike

[rokpedler]

Apparently it does. By enabling DISTINCT_E_FACTORS the slowing down stopped. I've been printing for about an hour on my second extruder and it's working great. My extruders are mirror images of each other, so I chose not to enable DISTINCT_E_FACTORS. Maybe a clarification regarding that item.
I've been dealing with this for a month. Thanks for putting me on the correct path.

[Eagle2301]

I have tried to print after enabling DISTINCT_E_FACTORS, but somethings wrong.
I have a printer with 4 extruders and when I sending G92 E0 following by G1 E-4.0000 F1800 (simply retract 4 mm) happen this:
If T0 is selected OK.
if T1 is selected X axis move forward about 40mm
if T2 is selected Y axis move forward about 40mm
if T3 is selected Z axis move down about 10mm

This is very strange !!!
In the firmware I have only de-commented the DISTINCT_E_FACTORS row in Configuration.h

Any suggestion ?

[Eagle2301]

Forget the previous message. my printer started to go crazy and finally is broke.

I think the RAMPS died, or (hopefully not) Arduino.
In the next few evenings I try again.

Sorry.

[thinkyhead]

@rokpedler It's interesting that DISTINCT_E_FACTORS helped your situation. It implies that we have a bug somewhere. When I went looking I did find one or two, which are now patched with #5971. Please give RCBugFix another test with DISTINCT_E_FACTORS disabled, and see if the issue has gone away.

[rokpedler]

It helped on tool 1 (second extruder), however thinking all was resolved, I tried a dual extrusion job. Tool 0 worked as expected and Tool 1 crashed both X and possibly Y axes. I killed the print before I found out. Both extruders work well individually but not together.
I downloaded "Marlin-32-Bit-RCBugFix-new.zip". Please forgive my ignorance as I haven't dealt with Marlin or Arduino at this level. If I got the correct file, will I be manually entering my parameters into the new "config.h"? Thanks,
Mike

[cosmith71]

Downloaded RCBugFix for today. I'm using the same configuration.h file as before, and with SLOWDOWN enabled. No DISTINCT_E_FACTORS. I'm 1.5 hours into a dual extrusion job and so far so good.

[rokpedler]

Apparently I'm not doing something right. During verification I get a compiling error for Arduino Mega 2560. I copied my config.h into the new download overwriting the original.
please advise.
Mike

[cosmith71]

I used the regular RCBugFix, not the 32 bit version.

[rokpedler]

Thanks for the guidance cosmith71, that was it. I have to agree, I'm on my second dual color print and everything seems to be working beautifully.
Thank you both for all the help. What a great community. I think I'll hang around for a while.
Mike

[cosmith71]

Awesome! I'm 7 hours in on a 2 color print and it's still going strong. Thinkyhead and the others do all the hard work, though. I just find things to gripe about. :grin:

[wywywywy]

I've been away since a few away weeks ago so haven't managed to try anything.

So is this definitely confirmed to be fixed now?

[thinkyhead]

Reports are looking positive that it is now fixed — probably caused by some sneaky bugs we just found hiding under the carpet.

[CarnufexG]

I have been following this thread... I just enabled DISTINCT_E_FACTORS in RC8 and it caused my Y axis to ram against its max stop while using just the 2nd single extruder (no dual extrusion model). Pardon my ignorance but is there a fix? I see thinkyhead issued a patch but do not know how to apply it. Just a pointer will do, thanks.

VORON CoreXY/S3D/using extruder #2. Extruder #1 functions fine. I am hoping I do not have to swap nozzles to get a working .4mm nozzle (#1 -> .6mm)

edit: strikethrough

[thinkyhead]

Presuming solved.