Can't handle prints with Cura's cool_lift_head

[richfelker]

If Cura's cool_lift_head (lift head when minimum layer time can't be met within minimum speed constraint) feature is enabled, the estimator treats each layer as a distinct print (due to Z motion back down after the lift). I'm not sure if the same happens with normal Z hop, but there probably should be some way to get the estimator to treat the pattern "increase in Z, no extrusion, return to original Z" as a hop (and account for time of hops) rather than as starting a new print.

[dalegaard]

Hi @richfelker

Can you attach a gcode sample file?

I took an ultra quick look and from what I can tell Cura will insert a G4 when it does this lift head cooling thing. That will make estimate cut each layer into its own sequence, but post-process still works correctly.

Is this correctly understood?

I'm weary of adding stuff for handling special sequences because it's one of those "never ending chases" things. We could add a single sequence option to the estimate command, making it combine all sequences into a single one. Potentially even a version taking a number of sequences to allow, after which all later delays will be combined into the last sequence. Would that be enough to solve the issue?

Best regards,
Lasse

[richfelker]

Here is a sample: mintime_test_bad.gcode.txt

Yes, it inserts G4, but I actually have an open bug against CuraEngine that it shouldn't do the dwell when the time spent lifting the head is already greater than the time it wanted to dwell; without this change, the feature is unusably slow. I think "no extrusion" is better logic for "this is not a new sequence", especially since you probably want to tolerate normal Z-hop too.

Personally I'd be okay wth the "single sequence" option since I don't do any timing of multi-sequences anyway. But I think an automatic solution would be nicer here since Z-hop is a fairly widely used feature (even if lift head for cooling isn't) and knowing the precise time spent on "hops" would be useful.

[dalegaard]

Sorry fat fingers! Didn't mean to close :)

I'll implement a sequence limit, as it's a more general option people can use.

Normal z hops don't show this behavior because it's dwells that cause a new sequence to be created. Successive dwells are also combined, such that each segment contains at least one move.

Best regards
Lasse

[richfelker]

Ah, would it make sense for dwells just not to cause a new sequence anyway, as they're a sort of "travel" rather than "print" move?

[dalegaard]

The reason dwells cause a new sequence is actually mainly for temperature waits and such. The idea was that "unbounded waits" in the print start gcode would be counted outside of the "main run". I reckon we could probably separate G4 dwells, which are really more like delays, from these "unbounded dwells", and simply count them as part of the run they occur in. That should make the Cura feature work correctly as well.

I'd probably consider this a breaking change compared to the current behavior, so we'd need to do a major bump but that's not an issue.

Let me look it over in the code, I don't think it'll be much work to change.

Best regards,
Lasse

[richfelker]

Thanks!

[dalegaard]

Released in 2.0.0. The test file looks to give correct output, and also, wow, that's a lot of time used just waiting 😅

Best regards,
Lasse