Page MenuHomeAleph Objects Inc

double layer stacking - dual extrusion artifact
Closed, ResolvedPublic


While dual printing, Cura will print 2 layers each tool change vs 1 layer per tool.
Slic3r will switch back to the other tool at the layer change
Here are some pictures of the artifact in question which only occurs while 2 extruders are in use

Here is the same model sliced in Slic3r and printed on the same machine

My hypothesis is that perhaps a layer time that is too short isn't allowing the material below the new layer to cool enough before another layer is applied. My reasoning for this is Slic3r's way of doing it allows more time for the layer to cool before another layer is applied by switching to the other tool/part before applying the next layer.
Another theory I have heard from @kent is that the backlash isn't being compensated for properly when z move occurs without a tool change. He may be able to explain that better.

Perhaps applying this change would mean more frequent tool changes and/or an increase in print time, and may shorten the life of the actuators on quiver.

Event Timeline

logan created this task.Jan 7 2019, 12:31 PM
logan added a comment.Jan 7 2019, 2:28 PM

I also noticed Cura prints the second layer faster before changing tool heads, is there a way to control this behavior?

Steven added a comment.Jan 8 2019, 7:43 AM

Wouldn't you see the same issue with a single tool head then?

logan added a comment.Jan 8 2019, 8:17 AM

@Steven perhaps that was stated incorrectly,

Another theory I have heard from @kent is that the backlash isn't being compensated for properly when z move occurs with a tool change.

If it is backlash related I can theorize why we'd be seeing it only while 2 colors are printing; because the machine must compensate for up and down Z moves during the tool change whereas when printing with one color the Z axis is moving consistently up. Minus the moves for auto bed leveling of course. Anyway, @kent may have more on that.

The second layer being applied faster than the first I think is a large contributing factor. In a single extruder scenario the individual layers behave more similarly to each other; walls one speed, infill another, etc. In Curas current layer stacking for dual extrusion, one layer is printed noticeably faster than the other so the outer walls are being printed at a different speed every other layer.

alexei triaged this task as High priority.Jan 9 2019, 2:07 PM
alexei changed the edit policy from "All Users" to "Cura LulzBot Edition (Project)".
logan added a comment.Jan 9 2019, 2:34 PM

Here is a video showing the model above being printed, sliced with v3.6.2

logan added a comment.Jan 9 2019, 4:00 PM

karrad moved this task from Backlog to Next Release (3.6) on the Cura LulzBot Edition board.

For some reason, we are seeing an increase in speed after moving up a layer, and using the same tool head. Right at about 26 seconds in the video above, the tool head goes to the next layer and speeds up. Looking at the gcode, we cannot see what/why it is inserting the increased feed rate after that positive Z move

adam added a subscriber: adam.Jan 10 2019, 12:14 PM

I'm seeing the same behavior in quiver 12 with the second layer that's printed on E2 printing much faster than the layer before.

anolen added a subscriber: anolen.Jan 10 2019, 3:06 PM

Same here, confirmed issue on my Quivers as well.
Firmware = .68
Cura = 3.6.3

karrad added a subscriber: Yahuba.Jan 11 2019, 1:08 PM

@Yahuba Can you test this on a TAZ 6 v3 dual extruder?

@Yahuba Here you go, sorry about missing those earlier

Im not sure I was able to replicate this. I did not notice any difference in print speed between layers or extruders. I loaded the two stl files and merged them into the cube on CuraLE 3.6.3 using a Taz6 with Dual v3 extruder.

I don't see any of the artifact in the above picture. When it does speed up I feel it is quite noticeable. So perhaps this is only happening on quiver? Seems odd

@karrad Is there any test results on taz 7 with backlash compensation disabled? M425 is only command in gcode that applied on layer change and may change speed.

I don't think we have yet, but we will give it a shot.

@marcio Please generate a rev of FW for Q that has backlash compensation disabled.

@west @tutley @logan Please give this a try once FW is ready

@karrad Try to slice using M425 disabled
Test with acceleration control enabled

anolen added a comment.Feb 1 2019, 8:49 AM

Thought yall would find this interesting.
When I turned Zhop ON, the alternating layer issue stopped so I pulled both the gcodes into Meld, see bellow.

Z hop ON

Z hop OFF

Zhop ON - LEFT

Can anyone else repeat?

kent added a comment.EditedFeb 1 2019, 12:39 PM

This to me means that it's hysterisis related -- the difference between actual and target position depends on which direction the carriage was last traveling.

The way slic3r handles dual extrusion is sort of like this:

move z up
T0 layer (n-1)
T1 layer (n-1)
move z up
T0 layer n
T1 layer n
move z up
T0 layer (n+1)
T1 layer (n+1)
move z up

however, in cura with quiver it's more like this:

move z down
T0 layer (n-1)
move z up
T0 layer n
move z down
T1 layer (n-1)
move z up
T1 layer n
move z up
move z down
T0 layer (n+1)
move z up
T0 layer (n+2)
move z up
move z down
T1 layer (n+1)
move z up
T1 layer (n+2)

so for each tool head every other layer is printed after the z axis moves up, while all the rest of the layers are printed after the z axis moves down.

The reason we don't see the artifact when z-hop is enabled is that every layer is printed after a downwards z-axis move.

Steven added a comment.Feb 1 2019, 1:50 PM

@kent I'm not sure that explains the increase in acceleration that is occurring and the visually noticeable increase in print speed on the second layer. I think this is still an issue in Cura that needs to be figured out. It is possible what you are claiming is part of the issue too FWIW.

I loaded "Q_CubeOff_PLA.gcode" into, and it shows extrusion speeds in different colors. There is definitely a pattern of alternating extrusion speeds in the GCODE from layer to layer and a difference in extrusion speeds between the top half and the bottom half of the part.

marcio added a comment.EditedFeb 12 2019, 8:39 AM

What follows is an excerpt of "Q_CubeOff_PLA.gcode", showing just layers 20 and layers 21, with the FILL sections excluded.

If you look at the gcode with "", you see the half of the cube are plotted in the following order, top then bottom, followed by bottom then top.

If you cross reference this against the code you get the following feedrates:

Layer 20:

WALL_INNER: F1800    ; Top half
WALL_OUTER: F1800  ; Top half
WALL_INNER: F600     ; Bottom half
WALL_OUTER: F600   ; Bottom half

Layer 21:

WALL_INNER: F1800 ; Bottom half
WALL_OUTER: F1800 ; Bottom half
WALL_INNER: F600 ; Top half
WALL_OUTER: F600 ; Top half

So, the alternating speeds are specified in the GCODE. All that needs to be done is to understand why Cura is alternating between F600 and F1800.

@marcio Can you detail the steps you used to generate the gcode? @victor_larchenko is having a hard time duplicating on his end

@karrad: I didn't generate the code. I downloaded @logan's "Q_CubeOff_PLA.gcode" from the post with timestamp Jan 9 2019, 4:00 PM

@logan Can we get the steps used to generate that gcode, or @anolen Any of the ones you are seeing this on?

@karrad Nothing other than normal slicing procedure for a dual print using any profile/settings, if he's using quiver it is every print where both nozzles are used, with no exceptions.

Add quiver machine
Add models
Specify which extruder to use for each part
merge models

@karrad @marcio @logan Looks like it caused by "Minimal Layer Time" option, printer slow down second nozzle to get minimal 30sec that set in PLA profile. When I set it to 1sec for both extruders, all model is printed on the same speed. This bug don't happen on TAZ6, because this option is set to 10sec on it.

@victor_larchenko I have been running a lot of tests for this issue and I wasnt seeing the increased speed but my profiles use a max of 15 s for the min layer time so this makes a lot of sense to me. I will test this out and try a repeat, thank you!!!!

@anolen Do you have results on this one from testing?

kent added a comment.EditedFeb 20 2019, 10:17 AM

@karrad @anolen sent me this data, I haven't done any analysis on it yet though.

Edit: I looked and there is evidently an alternating layer height mechanically, even though the gcode created by cura is calling for a consistent layer height. I don't think this is a design problem, but a combination of a characteristic of all linear motion systems (lash) and our motion control strategy. My recommendation is to find a way to ensure that the z gantry will always approach the target position from the same direction, i.e. always after a downwards move, or always after an upwards move. Turning a small z-hop on for all quiver profiles seems like the most efficient method of addressing this issue. We could also mitigate this effect by keeping lash compensation for the z axis on for the entirety of the print. The concern with the second approach is that it could introduce a different artifact. More information here: T5664

anolen added a comment.EditedFeb 20 2019, 4:14 PM

It appears that @victor_larchenko's "min layer time" find is a good fix for the alternating layer speed issue, so I think this ticket can be closed.

The visual patterning is not entirely caused by that, however.
I ran tests (using FW .81) comparing several machines, materials, and a comparison of z hop on vs off, all with the corrected Min Layer Time.

Data here:
Data Consolidation here:
Complete visual Archive for Data Here:

The remaining patterning was isolated to a machine issue (Lenny), we noticed that there was a nozzle offset issue.
I could visually tell that one layer was printing a hair too high and then next would be too thin, even when we reset, flashed, and watched perfect calibrations. It did this over and over on every other layer, creating that pattern.

The following data can be found here:
I flashed FW to .88
Then @kent asked me to use a Dial Indicator to measure z movement. I measured the Z movements during a print and plotted them on "Lenny_1", then for Comparison I used the same gcode on a different printer and plotted in "Barb". Then @west manually adjusted the nozzles on Lenny and I reprinted the same test and recorded it again on the page Lenny_2 in that document, this seemed to help. I then Flashed the FW to .91, reset to default, auto calibrated, and reprinted, recording the z moves on "Lenny_3" in the document. The new FW (.91) improved my results greatly.

We have determined that the alternating layer speed has been solved through setting changes but there is still a factor causing issues with the nozzle offset (mechanical or firmware). The cause is yet to be determined, and I am unsure as to why some machines have the issue more while others have it less or not at all. Could it be a combination of bad connections and nozzle offset calibration errors? So some machines could have an old FW which is not calibrating as accurately but there are no poor connections so the calibration is pretty close. Then other machines could have a newer FW which provides more accurate calibrations but it has a poor connection somewhere causing calibration errors. Then also, we could have machines with great connections that get flashed regularly and these wouldn't show an issue at all. This could account for our inconsistency with repeat ability.

I have noticed that when the layer time goes bellow the "minimum layer time" setting the alternating layer speed still does a slow and then faster layer. So a lower setting does not fix this issue, only isolates it to the top or smaller print areas/layers. Thoughts?

Is there a way we could just have it behave like slic3r?

layer 1 E1 > tool change > layer 1 E2 > tool change > layer 2 E1 > tool change > layer 2 E2
layer 1 E1 > layer 2 E1 > tool change > layer 1 E2 > layer 2 E2

Because the cube sliced with slic3r did not exhibit this artifact, as seen in the original post.

anolen added a comment.Mar 8 2019, 9:44 AM

There is another issue that I am only noticing now that could be important here, it seems isolated to the "Cooling" settings. When the layer goes bellow the minimum layer time (smaller parts) the layers begin to alternate in speeds still but they ALSO get dramatically different fan speeds. The 1st layer for that nozzle (the slower layer) gets the full max fan speed and the second layer (faster layer) goes to the min fan speed settings. Then the nozzles switch and it starts over for the other nozzle.

When Minimum Layer Time is set to 0 the layers both print at the faster speed but the fan setting still alternates "max" then "min".

Steven added a comment.Mar 8 2019, 1:17 PM

@victor_larchenko please see additional information from @anolen

anolen added a comment.Mar 8 2019, 2:48 PM

I agree with @logan on the process order change, aside from this issue we are having, alternating each layer instead of every other layer would provide better accuracy. I am unsure of how much work would have to go into changing that process for cura tho.

@anolen @logan if minimum layer time is set to 0, there is also option called "Regular/Maximum Fan Speed Threshold" that alternates fan speeds.
Also there is no layer speed alternating, it's extruder speeds alternating(two extruders printing on different speeds, but it still one layer).
Cura changes extruders only one time at layer so it looks like:
layer1: E1 -> E2, layer2: E2 -> E1, layer3: E1 - > E2, layer4: E2 -> E1, etc... So changing speed happens when printer ends one layer with E2, and starts new layer from E2(and similar for E1).
If layer time goes below minimal value cura slows second extruder in each layer(for layer1 it is E2, for layer2 it is E1, etc) so you see that effect.
But cura not accelerating extruders it only slows it(in this case "faster speed = printing speed", and "slower speed = 30-40% of printing speed").
There is no need of changing engine algorithm(it's very hard), only need to set right combination of "printing speed", "minimal layer time" and "Regular/Maximum Fan Speed Threshold" to fix it.

I think there is some confusion as to what the issue is here. We aren't getting the alternating speeds on the same layer with the different tool heads, we are getting alternating speeds on alternating layers with the same tool head.
I made a visual example when @karrad and @Steven were talking about it:

We came to the idea that somehow when the tool head changes layers but doesn't switch nozzles, it counts the previous layer time as part of the time for the next layer. This causes the "minimum layer time" to think that the layer is bigger than it is and it doesn't kick in and slow down this layer.
The fan seems to also be affected by the measured layer time as well and on the 1st slower layer I get the max fan speed but when it moves up in z for the 2nd layer for that nozzle, it brings the fan all the way down to the min fan speed. These changes happen when the model does not have a time difference between layers, all layers are the same amount of time. I attached a video bellow, Sorry its a little blurry, I wanted to get the LCD in the frame so you can see the fan change in between 0% and 30%.

Here are the finished prints, you can clearly see the double stacking artifacts.

Here is another video of the process, I was having a hard time viewing the above link.

It does look like it is not resetting the "layer time counter" after moving up in Z, but instead resets the timer when making a T0/T1 move. Both of these squares are the same size and infill, and should not have any change in layer time per layer.

@anolen @karrad What I found:

  1. min_layer_time is set for each extruder and time is counted also for each extruder in layer.
  2. force slowing of extruder was triggered only for last extruder in layer(fixed by above commit in T5146 branch). Now it counted for all extruders and should work.

@victor_larchenko Ahh thank you! Re-running the two tower test above, we are getting no speed changes when moving up in layers.

@anolen Can you get a test on this as well before we move to merge to master?

I am running a test now and it appears that the speeds and fan % are behaving like normal now, no alternating pattern.

karrad reassigned this task from victor_larchenko to alexei.Mar 18 2019, 2:32 PM
karrad added subscribers: alexei, victor_larchenko.

@alexei Ready for review and merge. We would like to get this into a build asap, as we are sending out beta units today

alexei closed this task as Resolved.Mar 21 2019, 11:28 AM

Merged to master.