This can happen if the user enters invalid toolchange through the custom gcodes
Such toolchange is now simply ignored by the CoolingBuffer, exporting gcode is NOT stopped, a log error is emitted
- added an extra travel move after a toolchange
- wipe tower only sets temperatures with single extruder MM printers
- ooze prevention does not work with the wipe tower - added a check into Print::validate()
Linear advance is reset by filament start gcode after a toolchange. However, not all moves to the wipe tower
end with a toolchange (brim, empty grid) and it would therefore disable linear advance until the next toolchange
This should solve https://github.com/prusa3d/PrusaSlicer/issues/2770
The initial priming now does not assume anything about bed width and always uses the space it has
In case of circular beds it places the priming lines along the diameter
Custom beds are not supported (they are treated as circular with no extra checks whether it is sane)
Slight refactoring of the WipeTower class (constructor now gets reference to PrintConfig and not the individual values, same with set_extruder). This was legacy from times when the wipe tower was meant to be abstract and independent on the rest)
Added detection of empty layers so the wipe tower doesn't trip on them (it is not printable anyway).
This should improve wipe tower reliability with supports, objects standing on edges, etc.
I also turned an assert into exception throw to prevent hard crashes and nonsense output.
- wipe tower respects max volumetric flow, slowing down with PVA etc is not hardcoded anymore
- wipe tower is now allowed for multiple-extruder printers. single extruder stuff is not used in that case (ramming, cooling, etc.)
- start/end filament and toolchange custom gcodes are now inserted differently than before - see 41164a9
- some refactoring, e.g. the abstract WipeTower class was eradicated
These firmwares use M135 Tn and M108 Tn commands for changing active tool, which the analyzer did not recognize. The toolpaths were then rendered in wrong color, extruder offset etc. This surfaced in issue https://github.com/prusa3d/PrusaSlicer/issues/2566
- abstract class WipeTower and its descendant WipeTowerPrusaMM were merged into a single (non-abstract) WipeTower class
- all uses of WipeTower::xy struct were replaced by Eigen Vec2f (it is no longer necessary to be independent on libraries that PrusaSlicer uses)
- the WipeTowerPrusaMM.hpp/.cpp will be renamed in the next commit (hopefully it will retain its git history that way)
no longer necessary because the speed overrides that the enum controlled were recently removed
the comment in gcode is now just about appending the config string
The priming extrusions were handled separately from the rest of the wipe tower toolchanges. In order to be able to use the logic from previous commit for them (custom toolchange gcodes etc), some unpleasant code shuffling was needed
Each toolchange now emits:
- end filament custom gcode
- toolchange custom gcode; if not provided, a standard Tn command is inserted
- start filament gcode
Hopefully it is now consistent for SE/ME printers with/without the wipe tower
The priming line does not work - will be fixed in the next commit
- setting of the wipe tower parameters based od whether SE MM printer is selected is done in the WipeTowerPrusaMM constructor, so it does not distract in Print.cpp
- WipeTowerPrusaMM.cpp conditions checking for SE MM printer are now using a more descriptive const member variable, not the loading/unloading speeds (hopefully the functionality is the same)
The odd commands that lowered the speed override values for PVA, FLEX etc. were removed
Now the wipe tower backups user speed override, sets it to 100%, does what is needed
and restores the old value when finished. There are no special cases - lowering
the speed for certain materials can be achieved by lowering the volumetric flow.
There was a bug in unit tests that led to generating the wipe tower with non-normalized preset.
This caused out-of-bounds access into max_layer_height vector in fill_wipe_tower_partitions.
The problem surfaced in https://github.com/prusa3d/PrusaSlicer/issues/2288.
I quickly patched additional normalization of the preset to prevent this from happening.
Also, an assert in the same function turned out to trip on one of the tests.
This one was commented out for now and will (hopefully) be looked into later.
Function Print::apply_config was renamed to apply_config_perl_tests_only so everyone
sees its current purpose and does not mistake it for the more important Print::apply.
has been rewritten to be easier to parse.
Old format
; filament used = 19248.8mm (46.3cm3)
; filament used = 57.4
; filament cost = 1.5
; filament used = 8007.6mm (19.3cm3)
; filament used = 23.9
; filament cost = 0.6
; filament used = 0.0mm (0.0cm3)
; filament used = 0.0mm (0.0cm3)
; filament used = 0.0mm (0.0cm3)
; total filament cost = 2.1
New format
; filament used [mm] = 1600.7,1600.7,1600.7,1600.7,1600.7
; filament used [cm3] = 3.9,3.9,3.9,3.9,3.9
; filament used [g] = 4.8,4.8,4.8,4.8,4.8
; filament cost = 1.5,1.5,1.5,1.5,1.5
; total filament used [g] = 24.0
; total filament cost = 7.5
Where the non-printing extruders are filled in with zeros, and
the trailing non-printing extruders are not exported.
; filament used [g]
and
; filament cost
are only printed if non zero (material density and cost are defined)
