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

Zero extrusion print moves and overlapping regions in first layer #184

Closed
DrLex0 opened this issue Mar 13, 2017 · 4 comments
Closed

Zero extrusion print moves and overlapping regions in first layer #184

DrLex0 opened this issue Mar 13, 2017 · 4 comments
Labels

Comments

@DrLex0
Copy link

DrLex0 commented Mar 13, 2017

Version

1.33.8-prusa3d

Operating system type + version

Mac OS X 10.11.6

Behavior

  • When enabling the new type of supports on a particular model, the first layer contains many print moves that do not extrude anything, as well as other moves that are incorrect.
  • Steps needed to reproduce the problem
    • Slice the attached STL with the attached config. (The attached STL is a cleaned version with non-manifold triangles removed, but this makes no difference in the sliced result.) Look at the generated G-code file.
  • Expected Results
    • Nothing weird happens.
  • Actual Results
    • The skirt is ‘printed’ with all E0.0000 values (which is why gcode.ws shows those moves as travel moves), and the extruder also pretends to print parts of the support structure while the E coordinate is stuck at E32.47074. A different structure is then actually printed, overlapping with this non-printed area. If you look carefully, the area with zero extrusion is what should have been printed. The one that was really printed is wrong, it does not leave the requested 0.2mm Z distance with the object.

layer1-halfway

layer1-complete

STL/Config (.ZIP) where problem occurs

Config_and_STL.zip

@nub2
Copy link

nub2 commented Mar 14, 2017

Same skirt problem here with the geodude
Please try to enable Support material -> Syncronize with object layers
For me it helps...

@bubnikv
Copy link
Collaborator

bubnikv commented Mar 24, 2017

Thanks, I am seeing the issue.

bubnikv added a commit that referenced this issue Mar 27, 2017
#184

No E distances generated when support is selected. bug?
#175
@bubnikv
Copy link
Collaborator

bubnikv commented Mar 27, 2017

This is a duplicate of #175

Hopefully fixed by 640698d

@bubnikv
Copy link
Collaborator

bubnikv commented Mar 30, 2017

Fixed in 1.34.0

@bubnikv bubnikv closed this as completed Mar 30, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants