Unretract before last travel move does not work

[richfelker]

Cura Version

5.7.0

Operating System

Any

Printer

Any

Reproduction steps

Slice a file/job with multiple disconnected parts and outer perimeters first, no infill or infill-after-perimeters, such that the first move of a layer is a travel to an outer perimeter.

Actual results

The travel move to the start of a new layer will unretract on the outer perimeter rather than on an inner one.

This happens as a consequence of my naive fix for Ultimaker/CuraEngine#1612 but without that fix, much worse things happen (the entire travel to the start of the new layer takes place unretracted!)

I don't understand this part of the code entirely but it looks like there is some merging of the path at the end of one layer and beginning of the next which breaks the logic.

Expected results

Unretract should take place on the inner perimeter before the final travel move to the outer perimeter.

[GregValiant]

Thanks for the report.
Please zip and post a project file that shows the problem.

[richfelker]

I don't use the frontend but CuraEngine directly. Would you be happy with an stl file and command line? Or should I go file the bug on the CuraEngine repo? My past experience was that reports posted there tended to get overlooked.

[GregValiant]

I print a lot and I know I don't have this problem but I always print Inside to Outside as I have experienced problems printing small holes when printing the outer wall first.
You have been making some changes to the code as well. In order to investigate any problem it has to be reproduceable so it can be chased down. Both retraction and Z-hops are affected by numerous settings so knowing how you set up the slice is important.

[richfelker]

On further investigation, unretracting on the inner wall has been fully broken since @jellespijker committed my fix. I can explain why the fix was wrong and must necessarily have broken it: final_travel_z_ and z_ are properties of the LayerPlan and are never equal except possibly for the last layer of the print. Changing the condition to path_idx != (paths.size() - 1) (i.e. not last path of the layer) fixes all but the first part in each layer. Apparently the initial travel of each layer has been merged into the last path of the previous layer.

[richfelker]

OK, the fix in the above comment (path_idx != (paths.size() - 1)) is correct but incomplete, because there's other logic intentionally breaking it.

The LayerPlan::addTravel bypass_combing code path is what's keeping the move to unretract inside the first part from happening. Removing that (never bypassing combing) would fix it, but LayerPlanBuffer::addConnectingTravelMove gratuitously asserts that there's no further travel at the start of the new layer. Removing those assertions seems to fix it with no adverse effect.

[jellespijker]

@wawanbreton and/or @rburema can either of you take a look at this?

[richfelker]

Updated the title because it wasn't working anywhere. My above attempt at fixing isn't quite right so I'll follow up with more in a bit.

[richfelker]

I have a new theory on why Ultimaker/CuraEngine#1612 happened and why my fix (which introduced the current bug) was needed.

The intent of the present code in CuraEngine was for LayerPlanBuffer::addConnectingTravelMove to be responsible for the travel path that would need "unretract before last travel" when the first part of the next layer is an outer perimeter. To do this, it calls prev_layer->addTravel to add a travel move to the start location of this perimeter. LayerPlan::addTravel then does the combing calculations to determine a point inside the combing boundary at the destination, and if that succeeds, marks the move as wanting an unretract before the last path component... but it did this calculation based on the layer-parts/comb-boundary of prev_layer, not the new layer being started! This means that the point it selects to unretract on may actually be outside the outer perimeter of the new layer.

I think the right fix is for addTravel to set first_travel_destination_ to the point inside the comb boundary it wants, and not skip adding an actual move for the first travel of the layer, but instead write a move to the final desired point with unretract_before_last_travel_ set on it. Also, addConnectingTravelMove should be revised to suppress unretract_before_last_travel_ on the path it adds to prev_layer, in case the combing miscalculation gets confused by using the wrong layer's parts for combing at the destination point.

I'll try to hack up a PoC for these changes and see if it works.

[richfelker]

PoC fix (against my tree, hopefully it doesn't have gratuitous conflicts):

diff --git a/src/LayerPlan.cpp b/src/LayerPlan.cpp
index e046fef16..bdc395817 100644
--- a/src/LayerPlan.cpp
+++ b/src/LayerPlan.cpp
@@ -399,7 +399,18 @@ GCodePath& LayerPlan::addTravel(const Point2LL& p, const bool force_retract, con
             path->retract = true;
             path->perform_z_hop = true;
         }
-        forceNewPathStart(); // force a new travel path after this first bogus move
+        if (is_inside_) {
+            // Find a suitable point inside the comb boundary for the connecting travel move to
+            // go to, and comb to the final destination here. This is necessary because the
+            // connecting travel move takes place in the previous layer and uses the previous
+            // layer's combing boundary, which might be outside the new layer's.
+            last_planned_position_ = p;
+            moveInsideCombBoundary(MM2INT(0.4), std::nullopt, path);
+            first_travel_destination_ = last_planned_position_;
+            bypass_combing = false;
+        } else {
+            forceNewPathStart(); // force a new travel path after this first bogus move
+        }
     }
     else if (force_retract && last_planned_position_ && ! shorterThen(*last_planned_position_ - p, retraction_config.retraction_min_travel_distance))
     {
@@ -2210,7 +2221,7 @@ void LayerPlan::writeGCode(GCodeExport& gcode)
                 {
                     gcode.writeTravel(path.points[point_idx], speed);
                 }
-                if (path.unretract_before_last_travel_move && final_travel_z_ == z_)
+                if (path.unretract_before_last_travel_move)
                 {
                     // We need to unretract before the last travel move of the path if the next path is an outer wall.
                     gcode.writeUnretractionAndPrime();
diff --git a/src/LayerPlanBuffer.cpp b/src/LayerPlanBuffer.cpp
index 7c6b69db7..2a3686b36 100644
--- a/src/LayerPlanBuffer.cpp
+++ b/src/LayerPlanBuffer.cpp
@@ -90,7 +90,6 @@ void LayerPlanBuffer::addConnectingTravelMove(LayerPlan* prev_layer, const Layer
 
     Point2LL first_location_new_layer = new_layer_destination_state->first;
 
-    assert(newest_layer->extruder_plans_.front().paths_[0].points.size() == 1);
     assert(newest_layer->extruder_plans_.front().paths_[0].points[0] == first_location_new_layer);
 
     // if the last planned position in the previous layer isn't the same as the first location of the new layer, travel to the new location
@@ -98,13 +97,18 @@ void LayerPlanBuffer::addConnectingTravelMove(LayerPlan* prev_layer, const Layer
     {
         const Settings& mesh_group_settings = Application::getInstance().current_slice_->scene.current_mesh_group->settings;
         const Settings& extruder_settings = Application::getInstance().current_slice_->scene.extruders[prev_layer->extruder_plans_.back().extruder_nr_].settings_;
-        prev_layer->setIsInside(new_layer_destination_state->second);
+        // Wherever we are travelling to, it is not inside any layer part of the previous layer,
+        // only potentially inside part of the new layer. Thus, for combing purposes within the
+        // previous layer, we are always moving to somewhere "outside" the layer parts.
+        prev_layer->setIsInside(false);
         const bool force_retract = extruder_settings.get<bool>("retract_at_layer_change")
                                 || (mesh_group_settings.get<bool>("travel_retract_before_outer_wall")
                                     && (mesh_group_settings.get<InsetDirection>("inset_direction") == InsetDirection::OUTSIDE_IN
                                         || mesh_group_settings.get<size_t>("wall_line_count") == 1)); // Moving towards an outer wall.
         prev_layer->final_travel_z_ = newest_layer->z_;
         GCodePath& path = prev_layer->addTravel(first_location_new_layer, force_retract);
+        // this must be cleared because it was calculated based on the wrong layer's combing boundaries
+        path.unretract_before_last_travel_move = false;
         if (force_retract && ! path.retract)
         {
             // addTravel() won't use retraction if the travel distance is less than retraction minimum travel setting

I have not run extensive tests on this, but based on my dive into reading/understanding this code, I think the concept is very sound, and it produces correct output for basic smoke tests.

[richfelker]

Note: I forgot to remove the hard-coded 0.4 mm from testing. Obviously that should be fixed to match the move-inside logic elsewhere based on innermost line width.