Open spiky2021 opened 2 years ago
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.
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