Why am I having to run with an extrusion multiplier of 60%?
-
I have it in mind to support auto firmware retraction as Marlin does, i.e. identify retraction/un-retraction gcodes and use the firmware retraction parameters for them. But there is the possibility of mis-interpreting moves. So firmware retraction support in S3D would be better.
-
Just looking through the online documentation, it doesn't look like S3D can support 3 extruders either. Dual extruders but not 3 (unless someone can advise me otherwise).
Slic3r actually gives you the choice of 4 extruders (tools) to choose from if you define the printer as having 3 extruders. I guess the authors were aware that with a mixing hot end you can have any number of combinations. Shame it's giving me this problem because otherwise, it does everything I need (but at least I've found a workaround). -
Looking at my S3D Install it appears that it CAN support upto 6 Tools (Don't ask how you configure it) but you can select from tool 0 to tool 5.
Doug
-
About the 2 cubes, with the weird 1st layer print patterns.
It looks to me as if the bed isn't level. On the brim it looks as if the layer thickness in the foreground is better than in the background. The foreground looks squished while in the back it looks put down loosely on top.
That could account for the strange patterns in the first layer.Will not help you with the extrusion issues, tho.
Lykle
-
I'm not sure I understand - why can't you use software retraction? More generally, why should anyone prefer firmware retraction over software retraction?
Regardless, it might be interesting to print some experiments with Cura even if they have no retraction; maybe even some slic3r experiments without retraction to compare. The point is, is slic3r doing something wonky? (The bug in slic3r 1.2.9 is supposed to occur only when filling tiny gaps, which get overfilled.)
It can't hurt to check dimensional calibration on your printer. By this I mean the dimensions used by the motion system; extrusion problems will mess with any dimension by a fraction of an extrusion width, so you want to print the biggest part you can accurately measure. I also found it helpful to print both "outside" and "inside" dimensions to measure, so that they would be affected by extrusion wonkiness in opposite ways. I designed a part that should show what I mean: http://www.thingiverse.com/thing:1688991 (last object) That's for a (small) delta; on a Cartesian you'd make it rectangular. And to decrease the volume by 80% you'd only need to scale the axes by 93% each, so it wouldn't take all that much dimensional inaccuracy.
I should say, though, that I can print cubes sliced with slic3r 1.2.9 and get perfectly-reasonable-looking output with steps/mm calibrated to reality, filament diameter set to the measured 1.72 mm, and an extrusion multiplier of 1.0. So if there's some weird slicer bug, I don't see why it hits you alone.
-
About the 2 cubes, with the weird 1st layer print patterns.
It looks to me as if the bed isn't level. On the brim it looks as if the layer thickness in the foreground is better than in the background. The foreground looks squished while in the back it looks put down loosely on top.
That could account for the strange patterns in the first layer.Will not help you with the extrusion issues, tho.
Lykle
Hi Lykle.
Agree with that. Sorry, I mean to report back but got overtaken by other events. Bed had moved by 0.05mm. Not apparent when extruding normally but when the extruder was seriously under extruding that 0.05 makes a noticeable difference to the first layer.
Ian
-
@ peridot.
Firmware retraction is needed for mixing hot ends such as the diamond which I use. More accurately, it is necessary to retract all filaments simultaneously when they share the same nozzle. DC42s implementation of G10/G11 allows that to happen. If one only retracts one of the filaments, then all that happens is that filament is drawn from one of the other inputs, rather than from the nozzle tip.
Edit. As for your other suggestions (thanks for taking the time though), I'm fully aware that it could be, and most probably is, something specific to my machine. Obviously, when I first noticed the issue, that's the route I was taking (for several weeks). I've checked the dimensional accuracy numerous times as well as orthogonal accuracy and just about everything else I can think of. Speed, acceleration, jerk, temperature, (fast, slow, hot, cooler) - none of these make any significant difference. Fast speed is maybe slightly better than slow but not much in it. It was only after doing weeks of these sort of checks that I stumbled upon the fact that I could remedy the issue by lowering the extrusion amount.
I don't know if you saw this in one of my earlier posts https://drive.google.com/file/d/0B_MwtHtQR_ZvbkJoN0l1Y3FUYTQ/view?usp=sharing. The only difference between the two prints is that the one with the blobs and strings and lines in the layers was printed with an extrusion factor of 1.00 and the other at 0.80. It beats me….......
Ian
-
It's also handy because you can make adjustments to your retraction on the fly rather than having to make changes in the slicer and start over. This is very helpful when getting your retraction settings dialed in for a particular filament or when trying new extruders and hot ends.
@ peridot.
Firmware retraction is needed for mixing hot ends such as the diamond which I use. More accurately, it is necessary to retract all filaments simultaneously when they share the same nozzle. DC42s implementation of G10/G11 allows that to happen. If one only retracts one of the filaments, then all that happens is that filament is drawn from one of the other inputs, rather than from the nozzle tip.
-
I get the idea of tweaking the retraction while the print is running but the simultaneous retraction can be achieved by sending something like G1 E-1
-1 unfortunately slicers don't appear to support these constructs.As slicers can be configured to setup the correct firmware retraction based on the type of filament used in the start gcode, so it's all good.
-
Hi Deckingman,
I started reading this thread with much anticipation that there would be some answers, I've often wondered why apparently 'identical' extruders would have such differences in extrusion. I run at 0.8 flow, with much reduced e steps so I reckon I'm not far off at 60 or 70% less extrusion rate then the suggested number.I recently ran into a lot of problems with my titan/e3d set up. An apparently perfect set up randomly started to stop sticking prints to the surface. The first layer simply would not stick, despite using printbite and having it work perfectly for months. The first layer started at the perfect height but would be 'overextruded', yet the rest of the print showed perfect layer adhesion to tracks below it and next to it, and a 20mm cube would come out around 19.91mm on the calipers. This first layer issue proved to be a big problem, no print larger then 30mm2 surface area would stick. And then, a print the other day seriously failed. Somehow, the nozzle blocked but instead of jamming it continued to extrude and the resultant plastic oozed out everywhere like thick toothpaste. when I tentatively picked apart the mess, the thermistor wires had slightly broken and (maybe) one of the E motor wires had broken. In the end I've chalked this up to 4 possible problems, the E motor wires, the thermistor, partial blockage or XY travel not moving as far as it should, causing overextrusion or most likely a mix of 2 or more of them.
Perhaps the little differences add up to more then you think. I suggest you start looking at all the ways your printer might not be identical… Extrusion temps slightly off, a slightly longer melt zone due to nozzle hieghts, slight differences in gearing, filament diameter etc. Figuring out these differences, although it doesn't matter to your print quality (as you can obviously set the flow right down and achieve good results), finding out the answers is good scientific practice, and will almost definitely help in the future.
-
Looking at my S3D Install it appears that it CAN support upto 6 Tools (Don't ask how you configure it) but you can select from tool 0 to tool 5.
Doug
I don't know how to do mixing, but setting up several tools is fairly straightforward. For example, each color of feature you are printing is assigned its own process, each process specifies tools and other parameters specific to this tool. S3D website has a relatively large how-to section for more details.
I have been watching the thread as some of the most interesting information is included here, and also because I had similar problems with overextrusion and E3D Titan/V6/S3D on my ever-changing RM2 setup. As Ian, I had reduced extrusion parameters until it was printing with acceptable quality. However, I did not have time to investigate due completely rebuilding my printer and getting busy with school. Looking at this thread, I have a feeling that extruders other than Titan are not affected, thus I would suggest take another look at what's inside it.
-
@GeckoBox3D. All valid points and while I'm not discounting the fact that there could be one or more faults with my machine, most of the things you mention would lead to under extrusion rather than over extrusion. For info, I'm using a PT100 instead of a thermistor and have found, through lots of testing that 195 deg C is best for my particular machine/setup. This is at the low end of what most people use for PLA but if anything should lead to less ooze and at high speeds might lead to partial blocking of the nozzle which would manifest itself as under extrusion. The other thing is that the Diamond hot end is a 3 in 1 out mixing hot end, so the differences you mention don't apply. That is to say, there is only one heater and one nozzle. I get the same results with all 3 Titan extruders incidentally.
@ terabyte. That's interesting what you say about the use of tools with S3D - thanks for that. That's effectively how it is done with slic3r. For info mixing is done via the tool definition so if in config.g I have say tool4 defined to use 33% of all three filaments, then I just uses that tool for that part of the print. One thing I do a fair bit is have colours transitioning from one to another over the height of the print. This is done by using a single tool but then post processing the gcode to change the mixing ration on say every 2nd layer change. I have a little python script that I run on the gcode file to do this but it looks like I might be able to use S3D's native post processing feature to do that which might be a better way of doing it.
@All. It seems there are quite a few people having similar issues, many when they have switched to using Titan extruders. I have to say that I never had any of these issues with my old RRP Mendel to which I had also fitted a Diamond hot end. However, it wouldn't be fair to say that the issue is with the Titan extruders as there are too many other differences between the two machines.
I've been observing how the machine behaves during printing. From these observations it seems that the apparent over extrusion happens during infill more than perimeters or possibly that it only happens during infill. This is definitely noticeable on objects which have a thinnish wall and need a thin infill.
Yesterday I was printing an object which is effectively a box, about 300mm long with walls 2mm thick. In slic3r I set perimeters to 2 and am using a 0,5mm nozzle and I set all the speeds to the same 45mm/sec. So in theory, the walls shouldn't need any infill as 4 perimeters (2 on the inside and 2 on the outside) at 0.5mm is 2mm and the extruder should run at more or less the same speed during all print moves.
Watching this print, I only get 1 perimeter with infill in between. What's more to the point is that the extruder runs noticeably faster when doing this infill. Not just a little bit - at at guess, I'd say it's at least 50% faster. I've double checked, and triple checked the slic3r settings and the speeds are definitely set to be the same for both infill and perimeters. So, slic3r is definitely doing something flaky with the infill.
Just thinking out loud, maybe slic3r generates rapid but small extruder moves, especially during infill, and maybe a lot of extruders cant's keep up with these moves but the Titan can? It's pure conjecture on my part but it would explain why a lot of people seem to have similar issues when changing to Titan extruders.
I need to go and do something else for a while as I can feel my sanity slipping away again…........
EDIT. Thinking about, of course the extruder will need to run faster if the carriage is moving in both X and Y when it does these silly small infills.
SECOND EDIT - No it won't - the movement speed should be the same, so the extruder speed should be the same.
THIRD EDIT. Looking at the gcode file, as near as I can make out, this thin infill is achieved not by zig zag moves but by simply upping the extruder speed by 50%. Maybe this is the problem? Maybe a lot of extruders will skip steps so the print will look fine but the Titans don't? So maybe it only affect those with the slic3r/Titan combination?
-
@deckingman Have you seen there is a new version of S3D:
"Updated Dual Extrusion Wizard to support printers with 3 or more extruders"
-
@deckingman Have you seen there is a new version of S3D:
"Updated Dual Extrusion Wizard to support printers with 3 or more extruders"
Thanks,
I haven't actually seen that quote but it still bothers me. It kind of reads like you can have any 2 colours (extruders) our of 3 or more and not necessarily be able to do tri-colour printing. However, it seems there is probably a way to do it using multi part printing and assigning different processes to each part. Each process could then use a different tool.
-
…THIRD EDIT. Looking at the gcode file, as near as I can make out, this thin infill is achieved not by zig zag moves but by simply upping the extruder speed by 50%. Maybe this is the problem? Maybe a lot of extruders will skip steps so the print will look fine but the Titans don't? So maybe it only affect those with the slic3r/Titan combination?
This is an interesting observation; however, there is a couple of possible explanations for this. The most likely one is that the infill is printed 50% wider for strength by default, and therefore more filament is needed per length. On the other hand my Titan skips less than the old extruder, but that would not be noticeable at slower speed
-
Ian
If you are worried about your extruder skipping steps then drop your max speed to see if that makes a difference.
My original point that you are suffering from overextrusion not underextrusion, therefore skipped steps are not causing your original issue.
-
Hi Tony,
No skipped steps with the Titans - the point was that maybe lesser extruders might skip steps and so "mask" the problem.
No skipped steps that is until I get to the point where the Diamond hot end can't melt the filament fast enough. In other tests, I've determined this to be around 120mm/sec for PLA at 195 degC - much faster than I would normally print. Still no skipped steps but it does chew the filament.
If I print at what I consider to be fast (around 60mm/sec) then that problem infill situation will be printed running the extruder as if the print speed was 90. The Diamond/Titan combination can handle that without skipping steps or stripping filament but could lesser extruders? Probably yes but maybe not always?
-
THIRD EDIT. Looking at the gcode file, as near as I can make out, this thin infill is achieved not by zig zag moves but by simply upping the extruder speed by 50%. Maybe this is the problem? Maybe a lot of extruders will skip steps so the print will look fine but the Titans don't? So maybe it only affect those with the slic3r/Titan combination?
As I understand it, this is precisely the "gap fill" situation in which slic3r 1.2.9 has a bug. Is it possible for you to test these same parts with a different version of slic3r? I have not had any success compiling the development version of slic3r, but you might be able to find the previous version pre-compiled somewhere.
Also as I understand it, slic3r is trying to fill the gap exactly by extruding extra to make a really wide line of plastic, and the bug is a miscalculation of how much extra it needs to extrude.
-
I've been using the latest development versions of Slic3r with great success both on a Windows and Linux. Their build environment instructions are pretty spot on, what issues have you had?
I believe this is the guide I followed: https://github.com/alexrj/Slic3r/wiki/Running-Slic3r-from-git-on-Windows
-
I'm trying to compile and run it on Linux. I followed these instructions: https://github.com/alexrj/Slic3r/wiki/Running-Slic3r-from-git-on-GNU-Linux and wound up with something that just segfaulted. It's out of master, so it's possible I just picked a broken version.
