invalid "PURGING FINISHED" comment line in generated gcode.

[vintagepc]

Version

2.0.0 Linux64

Operating system type + version

OpenSuSE 42.3

3D printer brand / version + firmware version (if known)

Mk3S/MMU2

Behavior

penguin.gcode.zip

I am developing a posprocessing script for toolchanges and enountered this while trying to parse out wipe-to-object/wipe-to-infill: There is a stray ;PURGING FINISHED comment on a layer where there is, infact, no area on the object to wipe to (it is the last bottom solid layer).
Toolchange in question is Toolchange #6 (T3) on line 3413 of the attached gcode.
The bad line is on 4037.

I realize it's low priority since it's only a comment and it's throwing something of mine for a loop but I did want to point it out in case it's a symptom of an underlying bug.

Is this a new feature request?
No

Project File (.3MF) where problem occurs

gcode attached, I've seen this with any wipe-to-infill MMU2 print I've made. If you'd like me to re-produce a 3mf for the attached gcode I'll do so, just let me know.

[lukasmatena]

I doubt this is a bug. The comment is emitted at the point where the active extruder is about to print extrusions that were not part of infill/object wiping. It is emitted on every layer where some extrusions were overridden, regardless of whether active extruder actually took part in that.

In other words, it marks places where current extruder is supposed to be completely purged after last toolchange. That's what the comment is for - to be able to verify that PrusaSlicer respects the wiping volumes by gcode post-processing. Yes, it is sometimes redundant, but I don't think it makes any harm.

[vintagepc]

It's definitely a bug as this is one specific instance of this comment in a region where there is no volume that can be purged in (last bottom infill layer), unless I'm misunderstanding the nuances of when this comment gets inserted.

[lukasmatena]

I believe I just explained the nuances. The comment simply means "I think current extruder is purged at this point so I will now print stuff whose colour you care about". It does not check whether there was some infill purging or any purging at all. And like I said, it can be injected more often than is necessary.

I can look at your 3MF should you post one, but like I said, I don't see anything wrong.

[vintagepc]

Sure, there isn't anything technically wrong (it's just a comment after all) but it's rather a nuisance when trying to parse out object available purge volumes in a gcode file, and unusual because it doens't happen for all solid layers.

I'm working around it by checking if the layer is less than the #bottom solid layers, so overall I'm not particularly disappointed if it's not worth pursuing further, and I fully recognize that fixing something this minor doesn't even register on the priority scale.

[lukasmatena]

Just out of curiosity.. What are you trying to do with your post-processing script?

[vintagepc]

I've been working on a purge bucket mod as an alternative to a wipe tower (reduced waste and minimal build volume loss) and was looking to support wipe-to-infill/object, for which I need to calculate the print's available purge volume.

https://forum.prusaprinters.org/forum/original-prusa-i3-mmu2s-mmu2-general-discussion-announcements-and-releases/the-mmu2-purge-bucket-thread-mod-wip/#post-158053

[lukasmatena]

There is a minimum volume that PS will purge to the tower, but I'm guessing it will purge $total_purge-volume - $purge volume of objects/infill to the tower. We can't easily determine that last parameter without being tapped into the actual slicing process, or making the code massively complicated.

I don't exactly understand why you want to calculate volume in the wipe-to-infill/objects and subtract from the total_purge_volume. If you are able to parse the gcode and sum the extruded volume, you can as well do it directly on the wipe tower wiping to get exactly what you need, can't you?

[vintagepc]

This is true... I just went with the first idea I had, since longer term we have plans to try integrating into a fork of PS directly. We're currently at a functional prototype so perhaps it's not too crazy to start considering that more seriously...

[lukasmatena]

I think I'll close this. The comment is not a symptom of an underlying bug, it is only emitted for debugging purposes. It was never meant to be used for things like this.

If there is a need to provide some extra information about how much is wiped on the tower, it can be arranged. Easiest might be to output the volume that the tower intends to waste on itself (maybe in the summary before each toolchange). Anyone who then post-processes the wipe tower away could just read it, without having to go ahead of itself and look for some mark that wipe into infill is finished.

[vintagepc]

Yes, I have an associated pull requests in #3573 and #3576 that could be adapted for what you suggested.