MatterControl - Incredibly slow support slicing
visuvius last edited by
I'm using a Pulse A-734 with MatterControl. My issue is that whenever I try to print larger items that require supports, MatterControl takes hours and hours to slice. I started slicing an item last night at midnight and its still going. The item is something like 1300 layers. This morning it was on layer 199.
I can print small items, and items that don't require supports just fine. But as soon as I try to print something large with supports, MatterControl can not finish preparing the G-Code. I'm not sure what to do from here. Since MatterControl is the only software that will work with my older Pulse, the printer is basically unusable for large items.
Any suggestions? I'm using a Microsoft Surface laptop.
I slice in SLIC3R and then run the gcode file through MC for the bed leveling and that works better that way also you can slice things on another computer without chancing on messing with the temp of the nozzle or the bed mid print. So Install Slic3R set the bed to 250x220 and slice there then click Export Gcode in mattercontrol then load the gcode file instead of the STL and hit print. Works in most cases. MC still will die if you slice multiple object in a different slicer thats a bug as it cant handle having the Z go to the same number multiple times. But you can work around that by combining them either before you make the stl or combine multiple stls into a single stl. As a bonus you get the neat extra features like Volumetric E (The pulse works much better with volumetric E) and variable layer width etc etc. On the down side you add at least one extra step. Well at least until Matterhackers makes MC usable for bigger more complicated things or somebody figures out how to do bed leveling with SLIC3R
visuvius last edited by
When you open the Slic3r gcode in MatterControl, do you immediatly just click "print" or do you try to slice it again? At what point does it add the leveling to the gcode?
I'm asking because I've tried what you're talking about but with Cura. I added the Pulse as a Prusa in Cura and saved the gcode for my model. Then I opened that gcode in mattercontrol and attempted to print. Unfortunately, when using the Cura gcode, MC would push the print head into the bed. I couldn't figure out how to get it to print level using gcode from another slicer.
Here is my config bundle - be warned that I use a .8 nozzle so if you import that and use a different nozzle you have some editing to do. The filaments preceeded with MH are Matterhackers the ones with HK are hobby king Bridge and 910 are taulman. Be also aware that most filaments have a max volumetric value set that too was tested with the .8 nozzle and I got a full all metal V6 .
As to work flow.
1.) select the proper filament and printer and print setting
2.) Load the STL (as I said if you load multiple STL's MC might die.
3.) Click Export Gcode in top right hand corner and save the gcode fiel
4.) on the computer connected to the printer (Does not have to be the same that runs SLIC3R) open MC and set a profile that is close at least in bed and nozzle temp so you don't have a potential cold extrusion if you pause a print or change filament.
5.) Instead of loading the STL load the .gcode file
6.) Hit print.
7.) It will give you a warning that you are running a gcode and that that might be bad - go run it anyway (I would not run someone elses gcode as it could have some nasty stuff in there like crashing the nozzle into your print bed etc. But its your gcode so you are not going to do that.
I think it either does the bed leveling when it loads the gcode file or on the fly but it will load a 25 mb gcode file in about a minute (on my Asus T100 Tablet with 1 gig of ram and a 1Ghz single core processor.)
Now you have 2 choices as to Z offset you can take care of that either in SLIC3R or MC you can still adjust the first layer on the fly by going into controls and hit the Z+ and Z- buttons as needed. If you want to print from an sd card you can export the gcode file from MC to another gcode file and check "apply bed leveling" and now you have a gcode file with bed leveling it will be much much bigger than the original one as MC breaks each move into multiple one to take care of the different Z offsets.
Multiple STLS sliced with any other slicer will crash MC.
IF you print a lot go out of MC every 3-4 prints - just close it - especially on a slow machine with little ram as it leaks ram and with each additional print it will get worse until you can have a cup of coffee in between gcode commands.
WARNING: Almost all my profiles use Volumetric E They are marked as something like Pulse C232 Volumetric 1mm Zhop
as some filaments need the printer set different. Those have the Line M200 D1.75 ; Volumetric set to 1.75mm filament i
in the start gcode - that has to be run with volumetric E checked. If you are interested in why I use volumetric E and what it is then watch me here
And just to make sure - I am just another guy printing and have no other connection to Matterhackers than sometimes I buy stuff from them
Slicing speed, particularly for support generation, has been significantly improved in the next release. Which should be out sometime in the next few weeks.
Are you guys going to do Volumetric E and variable layer widths anytime soon? And also fix the layer time estimation for small parts.
And while we are at it it would be great if each new version comes with a readme that tells you what was fixed and what was changed. So we don't have to call support for things like "where is the Z offset now" and "where is the supports option" etc. IOW when you remove, add or move something there should be something popping up saying "here is whats new in version ...." A Change log like any other software update does
ssweat last edited by
@larsbrubaker its still slow as hell and no layer preview wish they would fix this cura sucks too, just want to print stuff
@ssweat Are you sure it is the slicing that is slow? While slicing, it will say on the time slider what exactly it is doing. The slicing is usually one or two seconds, but writing to your media may be slow. Can you confirm?
spudnick1UK last edited by
@tinken Slicing has become very slow on models that are above 100 mm x 100m x100 using May release
This has been fixed in current releases