"No sparse layers" on purge block/wipe tower leaves a midair artifact

[VanessaE]

Version

git commit 45e0079

Operating system type + version

Debian sid

3D printer brand / version + firmware version (if known)

Hypercube with two extruders feeding a Y splitter (NOT MMU).

Behavior

Setting "no sparse layers" on the purge block creates a single, midair purge layer above the block at approximately the "normal" height of the block.

Normal mode:

"No sparse layers" mode:

(yeah, I know the block is large compared to the model. I've only just started experimenting with multi-color printing and have not tuned the filament switches well)

When viewed in Pronterface, that floating bit appears to be the very last thing printed, after the final layer of the object, so I'd think it would be sufficient to simply eliminate it, rather than trying to track down the underlying bug.

Project File (.3MF) where problem occurs

3DBenchy_-_Dualprint.3mf.zip

[lukasmatena]

This is intentional. See whichever of FAQ, #3593, #3533, #3116, #2412, #1355, #2088, #1616, #1070, #1268, #1423, #1386, #663, #1581 or #2612.

Please, search the tracker before filing a new one issue. Closing.

[VanessaE]

@lukasmatena OK, so one floating top layer may be intentional, but surely THIS is not:

This is with 2.2.0-rc4, with the same dual-print benchy mentioned earlier.

[bubnikv]

I am not seeing it with your 3MF

Just a wild guess, but it may be a floating point numeric issue,

[bubnikv]

it may be an OpenGL driver issue (not enough GPU memory?)
or some slicing service update issue after parameter changes?

The last one is easily ruled off if you yourself cannot reproduce the issue after saving a 3MF, closing slicer, reopening slicer with that 3MF and reslicing. If the issue is not there, than the issue is likely caused by the slicing core update by a parameter change.

[bubnikv]

I don't have your fancy print bed texture. Does the issue disappear if you disable the print bed texture? That would indicate low GPU memory issue.

[VanessaE]

My GPU has 3GB, and can handle far more graphics detail than is shown there. Besides, it works in 2.2.0-rc3, and in fact, I had several 2-color parts on the plate under 2.2.0-rc3 to test something. There was around 5 times as much on display, and it was fine.

I also tried just loading the original Benchy files instead of the 3mf. Same issue.

In fact, on watching closely: I can see it render the entire purge block as it would exist if "no sparse layers" were turned off. A moment after the full block appears, it then erases the parts that wouldn't be needed, it just doesn't "compact it down" like normal.

I then exported the broken-looking result to g-code, then loaded it into Pronterface:

Since it looks the same in Pronterface, it is clearly a toolpaths/g-code issue, NOT a GPU memory issue.

[bubnikv]

rc4 self compiled or our AppImage?
Do you see it with our AppImage as well?

[VanessaE]

I'm using the official rc4 appimage.

[VanessaE]

If it matters, here is my configuration under rc4 (from File -> Export -> Export Config):

Prusaslicer-config-20200316.ini.zip

[VanessaE]

Well I'd say that rules-out anything specific to my setup 😁

[bubnikv]

I don't see it running on Linux in virtual box either.

[VanessaE]

But I do note an issue on yours, @bubnikv: the gunwale and other details are supposed to be orange in that 3mf. Not white.

[VanessaE]

I tried removing the texture and model from the bed and just setting it back to a plain rectangle, 200x200 size. No change.

*keeps tinkering*

AH HAH!

I'd forgotten about a workaround I had to add to the tool change g-code:

; "tool change" code goes here

; force the correct temp for the hotend after toolchange
{if current_extruder == 0}
    M104 T0 S[temperature_0]
    M104 T1 S[temperature_1]
{elsif current_extruder == 1 }
    M104 T1 S[temperature_1]
    M104 T0 S[temperature_0]
{endif}

; force Z to stay at the proper height after toolchange
T[next_extruder]
G1 Z[layer_z]

; end of "tool change" code

Deleting those last two "force Z" commands is enough to make the purge tower work, BUT they're a workaround for #3848.

[bubnikv]

now that explains everything. Would you please attach the 3mf with your workaround integrated, so that we can retest? po 16. 3. 2020 v 15:45 odesílatel Vanessa Dannenberg < [email protected]> napsal:

…

I tried removing the texture and model from the bed and just setting it back to a plain rectangle, 200x200 size. No change. *keeps tinkering* AH HAH! I'd forgotten about a workaround I had to add to the tool change g-code: ; "tool change" code goes here ; force the correct temp for the hotend after toolchange {if current_extruder == 0} M104 T0 S[temperature_0] M104 T1 S[temperature_1] {elsif current_extruder == 1 } M104 T1 S[temperature_1] M104 T0 S[temperature_0] {endif} ; force Z to stay at the proper height after toolchange T[next_extruder] G1 Z[layer_z] ; end of "tool change" code Deleting those last two commands is enough to make the purge tower work, BUT they're a workaround for #3848 <#3848>. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#3834 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABMPSI7BI2TSBMKUCISI2QTRHY3PFANCNFSM4LHGA7NA> .

[VanessaE]

This should do: 3DBenchy_-_Dualprint, 2.2.0-rc4 with Z workaround.3mf.zip

Just to be clear, I started RC4, added the 2-part Benchy from the original files (i.e. not using my previous 3mf), set the two filaments, sliced, saved the g-code to a temp file (not that this part matters), then saved the 3mf project file.

[lukasmatena]

Ok, so what is the problem? Your custom g-code tells the printer to move to some height.... and it moves to that height. What are we supposed to do?

[VanessaE]

Did you read #3848? Without the above workaround, which obviously doesn't work well enough 😕, the first E1 usage is at the wrong height, which luckily so far has resulted merely in poor bed adhesion of that tool's filament due to it just loosely being laid down from too high. Fix that and I can lose the workaround entirely.

Though I suppose layer_z is not updated when moving to the purge tower, since that's where Prusaslicer puts the nozzle just before the tool change.

[lukasmatena]

I did read #3848 and I don't know yet how justified the claim is and whether any workaround is or isn't needed. But that is another issue.

Now that I think about it a bit, you are probably right that the layer_z placeholder should contain actual z-height of the toolchange. I think that should indeed be fixed.

[lukasmatena]

@VanessaE There is a new placeholder toolchange_z available in custom toolchange gcode since c25c435. It should allow you to do what you need. The layer_z still contains the z of the print that triggered the toolchange, the new one contains the actual z where the toolchange takes place.

Does it solve your issue?

[bubnikv]

implemented on master with c25c435. Closing.