Wrong multi extruder handling of PS.

Version

found and tested solutions for 2.3.0, but found for 2.4.0 alpha 3 as well

Operating system type + version

Win10

3D printer brand / version + firmware version

Craftbot Flow IDEX XL

Behavior

Prusa slicer handles extruders of multi extruder printers differently depending on their numbering.
If a users defines multiple extruders and uses just one for a print, at start up a toolchange (custom or not) is written for all extruders except 0 . Especially, if a custom toolchange gcode is needed a double priming may happen for all extruders except 0 and wise versa. The only way to overcome it, is to define further single extruder printers for this purpose. Is this intended?? The reason lays in method: _void GCodeWriter::set_extruders(std::vector extruder_ids) lines: / we enable support for multiple extruder if any extruder greater than 0 is used (even if prints only uses that one) since we need to output Tx commands first extruder has index 0 / *this->multiple_extruders = (std::max_element(extruder_ids.begin(), extruderids.end())) > 0;** For just extruder 0 the clause results in false and for just extruder 1 or higher in true. For me it looks like a bug or at least a forced inconsistency to provide any feature, maybe for MMU support? In my opinion no extruder of a multi extruder printer should be in favor by the slicer, to keep the freedom for future developments. Further, I believe all multi extruder printers can handle a T0 at startup independed of the actual selection state. Is this behaviour somehow needed for single_extruder_multimaterial support? If not, please get consistant by tested solution 1 applicable in method: std::string GCode::set_extruder(unsigned int extruder_id, double print_z) line: if (!m_writer.multiple_extruders) { by changing it to: if (m_config.nozzle_diameter.values.size() <= 1) { If so, extend above to solution 2: if (m_config.nozzle_diameter.values.size() <= 1|| (m_config.single_extruder_multi_material && !m_writer.multiple_extruders )) {_ I have not added a pull request, since we are still implementing on 2.3.0. This is related to #6017 and different results with the PS 2.4 implementation compared to mine (partly missing sparse support below interfaces, etc.) . Thus until our agreement tests are not finished, we won't change. If you are interested in doing this change and like to see a pull request, please let me know. By the way, I am still waiting for any responce to my pull #6018 since Feb. (a change in same method). Another reason why I omitted a pull. Can you be as polite to answer this, somehow?

I solved this issue by with scripts so that none of the extruders are active after print ends, i.e the filament is pulled out after print. I do believe for single nozzle multiple extruders setups this is the preferred option. Main reason being that there is no longer filament oozing out of the print head as it is cooling. This is dangerous because the oozing filament can prevent bltouch from working in the next print because cooled oozed filament prevents lowering of z axis causing print head to park into heat bed. Fortunately polycarbonate build bed is easy to patch with soldering iron so the casualties were minor. For the time being this only works if relative e distances is enabled. If there was a gcode for inquiring currently active extruder there might be better options. It might be possible determine active tool with marlin by compairing current M114 with other tools. Also you could automate loading of filament by setting extruder current to some low value and pushing filament say 1m and then pulling it back retract length.

End g-code: G1 E-[retract_length_toolchange] ; pull filament out T0 ; change back to first extruder

After layer change g-code(a bit hackish): {if layer_z == first_layer_height} G1 E[retract_length_toolchange] ; push filament in {endif}

Dear AapoTahkola, nice to hear that other users suffer from similar problems. We of course work with a custom gcodes. To explain our major problem with above inconsistancy, I may show you an example of our toolchange code used for our IDEX printers: ; ;Toolchange ; {if layer_num > 0}M104 T{previous_extruder} S{(filament_type[previous_extruder] == "PVA" ? 170:temperature[previous_extruder]-20)}; set pause temperature{endif} T{next_extruder} S{(layer_num <= 0 ? first_layer_temperature[next_extruder]:temperature[next_extruder])} M109 T{next_extruder} S{(layer_num <= 0 ? first_layer_temperature[next_extruder]:temperature[next_extruder])} ;prepare against pause problems like soft clogging or feeder graving G92 E0 G0 E{retract_length_toolchange[next_extruder]} F{filament_max_volumetric_speed[next_extruder]25} ;unretract G92 E0 M83 ; set to relative distances for extrusion G0 E1 F{filament_max_volumetric_speed[next_extruder]25} G0 E-2 F{filament_max_volumetric_speed[next_extruder]25} G0 E3 F{filament_max_volumetric_speed[next_extruder]25} G0 E-2 F{filament_max_volumetric_speed[next_extruder]25} G0 E3 F{filament_max_volumetric_speed[next_extruder]25} G0 E-2 F{filament_max_volumetric_speed[next_extruder]25} G0 E3 F{filament_max_volumetric_speed[next_extruder]25} G0 E-2 F{filament_max_volumetric_speed[next_extruder]25} G0 E3 F{filament_max_volumetric_speed[next_extruder]25} M82 ; set to absolute distances for extrusion G92 E0 {if filament_type[next_extruder] == "PVA"}G0 E15 F{filament_max_volumetric_speed[next_extruder]25}; flush and prefill soluble nozzel {else}G0 E5 F{filament_max_volumetric_speed[next_extruder]25} ;prefill nozzel{endif} G4 S4 ;wait to homogenize pressure G92 E0 {if layer_num > 0}M106 S0 T{previous_extruder} ;turn off previous fan after some nozzle cooldown{previous_extruder+1}{endif} M106 S{(layer_num > disable_fan_first_layers[next_extruder]-1 ? max_fan_speed[next_extruder]2.55:0)} T{next_extruder}; needed for IDEX printers ;generate print pressure before sidewiping, this approximates missing back pressure {if filament_type[next_extruder] == "FLEX"} G0 E2 F{filament_max_volumetric_speed[next_extruder]25} {else}G0 E2 F{filament_max_volumetric_speed[next_extruder]50}{endif} G92 E0 {if next_extruder_extruded_volume > 0.};custom retract before travel; G0 E{-retract_length_toolchange[next_extruder]} F{filament_retract_speed[next_extruder]60} G92 E0 {else};slicer retracts before travel{endif}_ As you may see, our PS settings automatically adopt print speeds for different materials via max. volumetric speeds defined for each material. It enables us with plug and play material combinations for nearly any chosen print profile, eg. 60 mm/s outer contours, 120 mm/s contours and 160 mm/s infill, possible with our Craftbot Flow. One of the really nice features of PS. Since fan automatics of PS don't write a tool specific fan gcode for IDEX printers, we stear them ourselves. For us it is necessary to achieve a plug and play priming for large prints sliced by our less experienced engineers as well. Large means objects with 3-5 kg, 500-700 g BVOH support and 2-10 days print time. During 10 days support material in our Polyboxes still gets slidely moistured and starts to degenerate in the nozzle during pause time. Thus a proper priming is essential before a restart after toolchange. So far the above inconsistency is worked around, by a combined left/right head printer, as well as a single left and right head one. The above purge procedure ones is included in the start gcode for the virtual single printers and ones in the toolchange for the combined, just because of an omitted toolchange for only T0 prints. I checked the use of filament start gcodes for each filament as well, but most placeholder needed above are missing there. Unfortunately our engineers and myself often mix up with this 3 printer definitions, therefore we need to be avoid this now. With above solution in our actual PS 2.3.0 mod. the virtual printers can be omitted, since everything is done by a toolchange. Some of our problems are related to a missing real multi extruder printer support of PS concerning cooling after and preheating before toolchanges and the missing IDEX printer support. Just concider heating Craftbot from 170°C for soluble and from195°C for rigid to 215°C takes totally 2 minutes, which sums up to about 1 day for 1000 changes. Somewhere here I once saw a comment by bubnikv claiming PS people are working on a preheat feature for 2.4 release? Concerning fans, I think about about implementing some gcode flavors for common IDEX printers. Something like Marlin IDEX (BCN3D, Raise 3D) and Craftbot IDEX (Craftbot uses Tx instead of Px for fan select), lets see.

I experimented a bit with moving the tool change gcode to a post processing script. I like this approach because I just as well emulate cura type printer using the same techique. Later I will be making a move to octoprint plugin so that it just emulates printer that prusa slicer happens to like. Octoprint plugins can modify incoming gcode any way they like although the api is incomplete.

Would you really think that e.g chrome would let in patches to their branch that would hurt their bottom line of making money people using their browser. The situation here is not much different. These patch rejects are happening with most open source projects these days. It is going to interesting to see e.g how this browser war turns out in the long term. What I do not really understand spiky is why a company like Craftbot is promoting competitors products. Why not just do what just about everyone else is doing and fork the project. I personally have very little interest in new features prusa slicer is developing. I mean painting material changes in a slicer.. WTF??! What is this these days, paint brush?

In other news, Slic3r git has not moved in 4 months so I guess we can start to consider the project "finished" or "dead" depending on how you want to look at it. I thought prusa slicer was going to contribute bug fixes back to Slic3r... wait you guessed it.. that part was BS.

I thought prusa slicer was going to contribute bug fixes back to Slic3r... wait you guessed it.. that part was BS.

You might consider comparing the two codebases before explaining "the situation here". The time when bugfixes could be effortlessly exchanged is long gone, and everyone actually involved in the projects knows that. Thanks.

The real situation about "patch rejects" is more accurately described in https://github.com/prusa3d/PrusaSlicer/issues/7162#issuecomment-950662055 and https://github.com/prusa3d/PrusaSlicer/issues/1513#issuecomment-952048965. I don't think it needs more explanation.

The inadequate support of IDEX extruders is a known issue and it is on the long TODO list.

What I do not really understand spiky is why a company like Craftbot is promoting competitors products.

Maybe it came out wrong. I am not related with Craftbot. We just try to combine machine features of Craftbot IDEX printers with the nice features of PS allowing a smooth and simple (plug and play like) user experience. In #7162 bubnikv mentions Prusa in competition with multi-national corporates. Well I need to apologize to belong to a unit of such a corporate with a software team much larger than 8, but we are operating in completely different business sector.

The thing is, using workarounds like post processing or branches can solve things for a moment, but needs to be entered or adopted to all following PS Version releases. Included in the release, it is a simple update. We thought about spending a position to to do so, but is actually rejected since printer things develop to fast. At the moment FDM printing suits well for our prototyping, tomorrow it may be chinese 15" and bigger MSLA printers with DLP projection like Elegoo/Anycubic are pushing. I looks like multi-material and multi-color-gadged printing will stay the domain of FDM for a while. IDEX lets see, because it is complicated with core-xy and depends on the sucess of something like Mosaic Element/Array printers.

It is off topic, but bubnikv mentions SLA in #7162. A question: Why are nowadays slicers writing MSLA data containers including slice parameters and hundreds or thousends of pictures? So far, FDM slicing doesn't suffer on this due to intrisic data reduction by full track information in single lines and lower detail resolutions of FDM printers. There is no standard forcing pictures, thus writing containers including a slicing description and slice parameters together with cleaned up STL object and support data in general results in much smaller file sizes. And a cheap RasPy derivate inside a printer can easily do a secondary slicing to pictures on demand.

Coming back to the topic. As I posted this issue my fear was, that this single line change does somehow interfere. Especially, because the original solution makes a circumstance for multi extruder printers I don't understand. On the other hand, this change together with #6018 and a common gcode flavor for IDEX printers are workarounds on the actual code base, but big steps in direction to a somehow support of IDEX printers at the moment they are needed, as well. By the way I requested a firmware transition from Tx to Px for fan selection at Craftbot and supposed a selection by Tx and Px in the meantime. Lets see, if they move?

After watching the prusa XL presentation on Formnext I like to congratulate you first for this nice design. Core xy, big wheel extruder, analog load sensing, segmented bed and toolchanging are tremenduos steps in one maschine. I hope PS will follow up with its possibilities. Especially essential for a toolchanger for example with distinct extruders is, that none of it is favor as this issue points out. Further each of it will have a separate fan, like for IDEX printers , which needs to be controlled by gcode, if not multiplext. And the additional retraction added to each extruder for its first use needs to be erased as well. Means I am confident that a PS version with toolchanger support does it for IDEX printer very soon as well. Seeing Cubicore claiming to 20000 pieces a day with their large scale MSLA DLP printer, somehow confirmed me with my statment above and shows that European companies still stay at the front. I am really excited to test this new ceramic resins and the upcoming steel and aluminum ones. This will make printed parts with high accuracies much cheaper in price and energy than FDM, as well as SLS and DMLS can be.

prusa3d / PrusaSlicer