Blobs produced at end of long straight lines on every layer when doing spiral mode

[davidjdixon]

OrcaSlicer Version

1.9.0-beta

OS version

macOS 14.2

Additional system information

No response

Printer

Bambu Lab X1 Carbon

How to reproduce

Note: this does not appear to the spiral fix added to 1.9.0 since this occured in 1.8.1 AND 1.9.0-beta (with 'smooth spiral' enabled)

In my example:

1. Use a 0.8mm nozzle, set line-height to 0.8mm, outer wall width to 2mm (this is an extreme setting, but works in the right circumstances).
2. Add an object with a straight edge of around 13mm followed by a curved corner (a simple curved rectangle would be fine)
3. Set print to work in spiralised (vase) mode with zero bottom layers
4. Start print and watch results at the junction of the long straight line and the curve.

Actual results

At each layer, the print head will pause for a fraction of a second and purge excess material at the exact same position. This is not a traditional seam line as the print head isnt jumping to a new layer, but instead it seems to pause to finish an extrusion is believes hasnt fully completed.

Note, this only happens at the end of long straight lines, by adding a tiny curve along the long line, it stops this purging behaviour.

Expected results

The print head should not be pausing or creating such excessive extrusion.

Note: within the slicer, there is no indication that this pause is occurring, and no visible seem or change in extrusion is shown in the rendered output in any of the visualisation modes.

Project file & Debug log uploads

example-blobs.3mf.zip

Checklist of files to include

• [ ] Log file
• [✓ ] Project file

[Naninani]

I wonder if these 2 are related: https://github.com/SoftFever/OrcaSlicer/issues/3450 - Im also seeing blobs where the wall is a single perimeter. But im not printing in vase mode.

[igiannakas]

The only thing I see in the gcode that may be causing this is the twice change of accelerations before starting the new layer. It may be causing the printer to stutter. It first sets it to 10k for the travel moves and then to 5k for the print move but they happen one after the other (line 2131 & 2134).

Can you set your accelerations as the below please - 5k for all of them. This removes the extra travel acceleration command.

If this fixes it then we know what the root cause is. If not there is something else going on that is not visible on the gcode (as there is no retraction move there in the gcode and also there is no change in flow which would signal a blob forming).

[davidjdixon]

Sorry for the delayed reply, I think i must have had email notifications turned off. I have tweaked the acceleration as suggested, but unfortunately, this did not affect the print

[igiannakas]

No worries, I think this has been fixed in the latest nightly. Maybe give this a try?

[davidjdixon]

Thanks for the fast reply. I would love to say that the latest nightly fixed it, alas it doesn't appear to have made any difference with the issue. For sanity, I've uploaded the profile with consistent acceleration and a 0.8mm width / 2mm height profile settings being tested. example-blobs.3mf.zip

[davidjdixon]

Im not sure if it helps, but i've also uploaded a small video of the issue, showing the behaviour once it completes the long straight lines.

https://github.com/SoftFever/OrcaSlicer/assets/452007/26c2d411-7bff-4226-8f06-7614ac65ddd9

[davidjdixon]

For additional comparison, I've added a new plate to the 3MF which has the exact same model with small negative cylinders added to create a tiny "bump" in the long lines. This "hack" stops all blobbing for a reason I cant fathom.

example-blobs.3mf.zip

[davidjdixon]

@igiannakas For further information. I have attempted to replicate the issue on Bambu Slicer. Since that slicer has hard limits on line height, for all layers (bar the first) I am unable to push the line height above 0.64mm on a 0.8mm hotend. With this line height, I am unable to replicate the issue. However on the bottom layer, a 0.8mm line height is possible, and on THAT layer, I do see exactly the same issue. This leads me to believe its a problem somewhere in the extrusion calculation that breaks down after the previously enforced line height.

In case its of use, I've attached the 3MF generated from Bambu Studio that shows the above behaviour. example-blobs-bambu-studio.3mf.zip

[igiannakas]

I think you can change the max layer height on BBS in the printer settings - extruder.

However in general you are limited to 80% of your nozzle size as the max layer height. What have you set it to orca? Beyond that you’ll get trouble with layer separation.

[davidjdixon]

The max layer height on the extruder does not do what you would expect it to do as the internal coding has hard limits applied which were removed in Orca Slicer (for note, i have max layer height set to 0.8mm on the extruder and it makes no difference in Bambu Slicer).

For note, the differences in the slicer code base on this can be viewed here (Bambu): https://github.com/bambulab/BambuStudio/blob/f6930bb6ab5005184dab3c0fb060394d2fb2f3dc/src/slic3r/GUI/ConfigManipulation.cpp#L183

and here (Orca): https://github.com/SoftFever/OrcaSlicer/blob/951fc8e98a0d5ca0ccb254315646ce7889a44836/src/slic3r/GUI/ConfigManipulation.cpp#L189

I have successfully printed well above 80% limits (and this has also been well documented to be a false understanding of limits https://www.youtube.com/watch?v=0DAP5Zm1jvk), the only difference is I'm printing circular objects with these higher line heights (without any problems), and it's ONLY on long straight lines that this problem presents itself (as I mention above, the error can be largely hidden by with a hack of adding a very small (almost imperceptible) 'dip' in the middle of the long lines.

Hopefully that helps to understand the issue more.

[davidjdixon]

Hi, curious to know if there's been any movement on this, has it been verified?

[davidjdixon]

Any chance this could get a look at @igiannakas ?

[davidjdixon]

@SoftFever it would be great if someone would be able to assist with this.

[SoftFever]

I see nothing wrong in the gcode. I noticed you set the line width to 2mm and 0.8 layer height, this setting is "out-of-range" for a 0.8mm nozzle to perform well. especially the layer height. Have you tried to reduce it to 1.2mm and try again?

[davidjdixon]

Hi @SoftFever, thanks very much for your response. I know my settings are quite extreme, but the actions of the printer when used are indicating an actual pause rather than some under-extrusion issue (as you can see in the video) so I can't figure this out. As noted above, this happens with long straight lines only and not circular lines (or weird hacks where I introduce the subtlest of "bumps" in a long line).

It only occurs on the extreme settings, but I can see nowhere in the coding that described this "out of range" you mention, and I assume you're referring to 'common knowledge' rather than a setting in the slicer around this? Those limits were also pushed beyond those commonly accepted boundaries by Lost in Tech youtube.com/watch?v=0DAP5Zm1jvk, and as I mentioned, on circular objects, this issue doesn't present - which leads me to believe its a factor of the acceleration/speed and extrusion that's creating these pauses - but for the life of me, I don't know what these are or what is causing them.

My concern here is that it's a slicer limitation/issue which means when I (eventually) get a 1.4mm nozzle via Biqu/E3D, it will hit those issues due to a software limitation (that Bambu etc have introduced to their limit of 0.8mm nozzles).

Would you suggest this is more an issue in the printer/firmware side of the equation than the slicer if the GCODE is looking fine? I just want to make sure that the GCODE itself is not setting some limitations to the printer that are overriding my own settings.

[SoftFever]

Hi @SoftFever, thanks very much for your response. I know my settings are quite extreme, but the actions of the printer when used are indicating an actual pause rather than some under-extrusion issue (as you can see in the video) so I can't figure this out. As noted above, this happens with long straight lines only and not circular lines (or weird hacks where I introduce the subtlest of "bumps" in a long line).

It only occurs on the extreme settings, but I can see nowhere in the coding that described this "out of range" you mention, and I assume you're referring to 'common knowledge' rather than a setting in the slicer around this? Those limits were also pushed beyond those commonly accepted boundaries by Lost in Tech youtube.com/watch?v=0DAP5Zm1jvk, and as I mentioned, on circular objects, this issue doesn't present - which leads me to believe its a factor of the acceleration/speed and extrusion that's creating these pauses - but for the life of me, I don't know what these are or what is causing them.

My concern here is that it's a slicer limitation/issue which means when I (eventually) get a 1.4mm nozzle via Biqu/E3D, it will hit those issues due to a software limitation (that Bambu etc have introduced to their limit of 0.8mm nozzles).

I’m speaking in terms of widely accepted practices. Although one may have found success in particular situations, it doesn’t align with what’s considered good practice by the majority of 3D printing users during the actual printing. Therefore, in my view, it shouldn’t be regarded as a norm or endorsed as a standard approach.

Would you suggest this is more an issue in the printer/firmware side of the equation than the slicer if the GCODE is looking fine? I just want to make sure that the GCODE itself is not setting some limitations to the printer that are overriding my own settings.

It really seems like the issue is with the firmware or the printer itself. Watching your video, it looks like the printhead pauses for a moment to let the extruder complete its job before moving to the next point.(this happens especially you have a closed loop motor). You might want to try reducing the print speed a bit more to see if that makes a difference.

But honestly, the best move is to get in touch with the manufacturer's customer service. They can take a look at your machine's logs, and it should be pretty straightforward for them to figure out what's going on from there.

[mxbng]

Hello everyone,

Is there a solution to this problem? I have the same

[github-actions[bot]]

Orca bot: this issue is stale because it has been open for 90 days with no activity.

[github-actions[bot]]

Orca bot: This issue was closed because it has been inactive for 7 days since being marked as stale.