Ultimaker / Cura

3D printer / slicing GUI built on top of the Uranium framework
GNU Lesser General Public License v3.0
6.18k stars 2.08k forks source link

Double Z Hop on Tool Change #4242

Closed vjapolitzer closed 1 year ago

vjapolitzer commented 6 years ago

Application Version 3.4.1

Platform Win10

Printer Custom, Multi-Extruder, RepRap Gcode flavor

Steps to Reproduce Enable Z Hop when retracted, as well as Skirt or Brim. Use a multi color model where at least the first two layers use only one color/extruder (I used the Low-Poly Eevee by FLOWALISTIK). Ensure the selected Build Plate Adhesion Extruder is the same as the extruder used for the first two layers of the model. For the Eevee, I used Extruder one for eevee...dual1.stl and Build Plate Adhesion, and Extruder two for eevee...dual2.stl. Then slice the model and export the Gcode.

Actual Results In the transition from the 0th to the 1st layer, when the tool is changed from the outer skirt/brim tool(s) back to the tool for the model, an additional Z Hop line is present, so a double Z Hop occurs. An example is in the Additional Information section.

Expected results Only one Z Hop should be present.

Additional Information Project File: CFDMP_eevee_lowpoly_flowalistik_dual.curaproject.curaproject.3mf.zip Example Gcode: ;TIME_ELAPSED:67.119864 ;LAYER:1 M140 S60 M106 S255 G0 X0.00 Y0.00 Z0.7 G1 F2700 E12.83334 G92 E0 T0 G92 E0 M109 S200 G0 F24000 X0.00 Y0.00 Z0.7 First expected Z Hop (2 * 0.3mm layers + 0.1mm hop) G0 X0.00 Y0.00 Z0.8 Unexpected second Z Hop G1 F2700 E-3.2 G0 F24000 X0.00 Y10 Z0.7 G1 F30000 Z0.7 G0 F24000 X-5.613 Y-9.448 ;TYPE:WALL-INNER G1 F30000 Z0.6 G1 F2700 E0 G1 F1950 X-4.688 Y-8.845 E0.05509

Ghostkeeper commented 6 years ago

When slicing this I get an assertion failure in CuraEngine.

2018-08-16 08:34:23,582 - DEBUG - [Thread-15] UM.Backend.Backend._backendLog [94]: [Backend] CuraEngine: /home/ruben/Projects/CuraEngine/src/LayerPlanBuffer.cpp:93: void cura::LayerPlanBuffer::addConnectingTravelMove(cura::LayerPlan*, const cura::LayerPlan*): Assertion "newest_layer->extruder_plans.front().extruder == prev_layer->extruder_plans.back().extruder" failed.

We don't show these assertion failures unless you're in debug mode, but something like this would cause weird results.

BagelOrb commented 6 years ago

I can't get my debugger to run :cry:

I can't continue working on this issue, so I'm leaving my findings for future developers who want to pick up the issue.

The problem is definitely there:

;LAYER:1
M140 S60
G1 F2700 E12.83336
G92 E0
T0
G92 E0
M106 S255
G0 F24000 X0.00 Y0.00 Z0.7
G0 X0.00 Y0.00 Z0.8
G1 F2700 E-3.2
G0 F24000 X0.00 Y10 Z0.7
G1 F30000 Z0.7
G0 F24000 X6.286 Y-12.249
;TYPE:WALL-INNER

It seems to be related to the fact that the machine doesn't need any action to switch extruder, which caused an empty extruder plan, which causes assertion failures in LayerPlanBuffer::addConnectingTravelMove.

The extruder plan is removed in LayerPlan::setExtruder if there are no travel/extrusion moves in the plan, but this causes problems with assertions.

Ghostkeeper commented 6 years ago

Two of our engineers have worked on this but couldn't fix the bug. We've decided to leave it in for now but provide a workaround: In the Extruder Start g-code of both extruders in the Machine Settings menu, put down this g-code:

M105

The disadvantage it that it'll switch to the other extruder and back unnecessarily at some points. If this is a no-op on your printer then you're fine but you will have some unnecessary heating and on some printers an unnecessary move.

github-actions[bot] commented 1 year ago

Hi 👋, We are cleaning our list of issues to improve our focus. This bug seems to be older than a year, which is at least three major Cura releases ago. It also received the label Deferred indicating that we did not have time to work on it back then and haven't found time to work on it since.

If this is still a problem for you in the current version of Cura, can you please leave a comment? We will have a fresh set of eyes to look at it.

If it is not a problem anymore, you don't have to do anything, and this issue will be automatically closed in 14 days.

github-actions[bot] commented 1 year ago

This issue was closed because it has been inactive for 14 days since being marked as stale. If you encounter this issue and still experience this to be a problem, you are welcome to make a fresh new issue with an updated description and screenshots.