Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
VanessaE opened this issue Mar 13, 2020 · 20 comments
Closed

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

VanessaE opened this issue Mar 13, 2020 · 20 comments

Comments

@VanessaE
Copy link

VanessaE commented Mar 13, 2020

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:

Screenshot_2020-03-13_12-24-29

"No sparse layers" mode:

Screenshot_2020-03-13_12-25-26

(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

@VanessaE VanessaE changed the title "No sparse layers" on purge block/wipe leaves a midair artifact "No sparse layers" on purge block/wipe tower leaves a midair artifact Mar 13, 2020
@lukasmatena
Copy link
Collaborator

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
Copy link
Author

VanessaE commented Mar 16, 2020

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

image

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

@bubnikv
Copy link
Collaborator

bubnikv commented Mar 16, 2020

I am not seeing it with your 3MF

image

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

@bubnikv bubnikv reopened this Mar 16, 2020
@bubnikv
Copy link
Collaborator

bubnikv commented Mar 16, 2020

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
Copy link
Collaborator

bubnikv commented Mar 16, 2020

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
Copy link
Author

VanessaE commented Mar 16, 2020

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:

image

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

@bubnikv
Copy link
Collaborator

bubnikv commented Mar 16, 2020

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

@VanessaE
Copy link
Author

I'm using the official rc4 appimage.

@VanessaE
Copy link
Author

VanessaE commented Mar 16, 2020

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

Prusaslicer-config-20200316.ini.zip

@VanessaE
Copy link
Author

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

@bubnikv
Copy link
Collaborator

bubnikv commented Mar 16, 2020

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

image

@VanessaE
Copy link
Author

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
Copy link
Author

VanessaE commented Mar 16, 2020

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
Copy link
Collaborator

bubnikv commented Mar 16, 2020 via email

@VanessaE
Copy link
Author

VanessaE commented Mar 16, 2020

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
Copy link
Collaborator

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
Copy link
Author

VanessaE commented Mar 17, 2020

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
Copy link
Collaborator

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 lukasmatena reopened this Mar 17, 2020
lukasmatena added a commit that referenced this issue Mar 5, 2021
This always contains the actual print_z of the toolchange, while layer_z contains the print_z
of the print. The two differ in case that wipe tower without sparse layers is used.

Related to #3834.
@lukasmatena
Copy link
Collaborator

@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
Copy link
Collaborator

bubnikv commented Jun 3, 2021

implemented on master with c25c435. Closing.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants