illuminarti
-
Posts
2,785 -
Joined
-
Last visited
-
Days Won
1
Content Type
Forums
Events
3D Prints
Posts posted by illuminarti
-
-
I pretty much never have first layer adhesion problems, and if I did, I'd probably start the print over anyway, so for me there would definitely be a use case for the faster solid infill layers on the base layer only, as I described. Sure, it can be done with plugins (are plugins working in the beta?) but equally, since I think it's a distinct (if often overlooked) area of the print where a different speed might be very useful, I'd urge you to consider adding it as a part of the slicing profile.
And regarding the new gcodes, I still think that there may be value in having a systematic way to tell the firmware what type of path it is printing... comments are an ok workaround for post-processing plugins (although not ideal), but you wouldn't want the firmware to have to parse comments. I think it would open up a lot of opportunities for print-time optimizations if the firmware knew what it was printing.
While slicing is a very quick and easy thing to do (now, thanks for the hard work on the new Engine - it's a huge improvement!) - printing still takes a very long time. For that reason, it's not the same as a 2D printer, where you don't have any reason to care about the language that the computer use to talk to the printer. Yes, they can all just be pixels to a 2D printer, because you don't tweak the print on the fly - it's all quick enough that if it doesn't come out perfect, you just start over, and can do all the refinement on the computer end of things.
As a result, I think it makes sense for the printer operator to have as much control over the print process as possible, and be able to change speeds, temps etc selectively as the print progresses, with more granularity than the all-or-nothing control that we currently have. Separate gcodes for different parts of the print would be a huge step forward in this regard.
-
I've never heard the 'bunching up' theory. Which isn't to say it isn't true (although I suspect it's more likely some sort of mechanical resonance). Where did you read about that?
-
Yes, definitely. The very bottom layer is critical for quite a few of my projects. The solid layers immediately behind (above) it are usually less critical though, and just need to be there for strength.
Also, if you print an iphone case you want the bottom layer to come out as the best layer. Sometimes you *do* care about the bottom layer more than other layers.
-
I'd want to be able to do the first layer at one speed - probably slow, to get it to stick.
Then do the subsequent solid infill on the next layers really fast (because you can, and no one ever sees them). But keep the perimeters at a reasonably slow speed (because they are seen).
And then once the bottom thickness is done, change to the main infill speed for the infill in the rest of the print.
You mean like, the "initial layer speed" from the advanced settings?
-
And while I'm wish listing, I'd be really interested in being able to selectively slice/print the (second and subsequent) base layers at a different speed from the rest of the print.
It's typically one of the most time-intensive parts of a print, with lots of solid infill, but it's also super-easy to print since it's perfectly supported by the bed and solid layers below. And, apart from the very bottom layer, no one sees it anyway.
I find I can print these base layers very, very fast (subject to throughput volume limitations), but I wouldn't want to do all solid infill at that speed - for upper layers that are going to be visible and/or print over sparse infill, I'd want to print at more reasonable speeds to ensure a nice finish.
So, being able to control the speed of the base separately would be helpful.
-
Ok, thanks! Look forward to testing it out.
One thing I've often wondered about is whether it might be worthwhile to have multiple different G-codes for different styles of printing: expanding the G0/G1 fast/controlled move idea, to allow for different G codes to indicate perimeters, loops, sparse infill, solid infill, exposed infill, etc.
Obviously this would have to be an optional feature in the slicer, and require firmware support. But it seems like it might make it easier to post process gcode, and also allow the firmware to make smarter decisions about how certain paths are drawn at print time, and/or allow for more fine-grained live-tuning by the operator.
I'll make an incremental release somewhere this week.
As for the order at which things are printed. This is a separate piece of code. It's called the "pathOrderOptimizer", this piece of code is given a whole bunch of polygons or lines for the infill, and then figures out in which order to print them.
Each line of the infill is seen as a separate entity for printing order. The current implementation just picks the closest next thing to print. This could be made a lot smarter, but it currently works pretty nice. (In the end, it's a traveling salesman problem which is difficult to solve properly)
Note that sparse and full infill lines are handled the same and as 1 group. There is no special code in place for the order of any of the infill lines, everything is handled by the same piece of code which has no knowledge of the infill routine.
-
I'm glad to hear you're getting better results. Prints are looking pretty nice now, and everything is pretty much where it's supposed to be on each layer (which is a good sign!) :-)
Not sure about the corners... might be a little bit of ooze and over extrusion... perhaps due to printing the perimeters a bit too fast, causing pent-up pressure which oozes out as the printer slows down for the direction change.
Maybe try printing a touch slower, and/or cooler, and see how that effects the results?
-
Thanks for tracking it down, Daid! Will there be another incremental release soon?
Here's another thing I've seen with the new slicer, when slicing a large flat piece.... (say a rounded rectangle 20 cm x 5, diagonally oriented on the bed)...
The printer usually ends up at one end of the shape, and needs to do a long fast travel move all the way back to the opposite end, in order to start the next layer. I've found that sometimes - especially when printing the first layer or two, there can sometimes be a little roughness in the layers - due probably to the bed level being fractionally off, so that there's a bit of an excess pressure build up in the head, leading to a touch of over extrusion on the next layer... and particularly visible as the head slows and accelerates again at the end of infill passes. That's not the problem, though.
The problem is that those long travel moves can end up catching on the over-extrusion - at the least this damages the print surface, and sounds awful. At worst, I've had it cause skipped steps.
Even without the physical catching, in previous (SF) versions of Cura, I'd often end up with ugly scars across the inside bottom of cups and bowls due to travel moves over the surface - even with retraction. Not sure if that is still a problem with the new slicer...
Another less than perfect thing has historically been that if infill starts in the middle (longest diagonal of a square, for instance) and works to one corner, and goes to the corner, and then goes back to the middle to work to the other corner, you can often end up with quite visible differences where the two halves touch, due to gradual variations in filament color, temp, etc which then get positioned next to one another.
This all leads me to a couple of thoughts....
1) I think that for some moves at least, it would be good to consider raising the z - especially for moves over large areas of solid infill on the bottom of the print (where z-height issues might still be working themselves out) and for layers that represent finished horizontal surfaces. This will avoid catching and scars.
2) On finished horizontal surfaces, make sure that the solid infill is printed continuously wherever possible - work from one corner to the opposite one, rather than starting in the middle and working outwards. I.e., for exposed layers, pick a toolpath that emphasizes aesthetics over efficiency, if you have a choice.
-
Try powering off the machine and moving the head by hand, using light fingertip pressure on the sliding blocks. Both axes should move fairly easily and smoothly, and with equal pressure for both. Is there more friction in that corner of the bed?
-
Welcome, anykey! Thanks, for sharing your first impressions and experiences. I can still remember my own first experiences with the printer. Although I was perhaps extra-wowed because it was my first ever 3D printer, I remember being really impressed with the quality of my first ever print as well. I'm sure you'll continue to have a lot of positive experiences with it... and if you do run into any problem, the folks here on the forum are pretty helpful, and we'll do what we can to help you fix things. :-)
-
??, Lars?
??
-
Your axis rod is bent? So if you roll it on a flat surface, it moves up and down? If so, that's going to cause no end of problems I think. I'd get in touch with Ultimaker Support via their web site, and talk to them about getting a replacement.
-
This look to be related to the z-screw - are the bands 3mm apart - the pitch of the z-screw?
If so, I'd check if the z-screw is seated properly into the coupling, and is vertical. Watch as you use the ulticotroller or computer link to run the platform up and down - is the top of the z-screw wobbling noticeably?It should be straight and not wobble, and be well seated into the coupler, otherwise the bed is going ot shift slightly as the screw rotates.
It's hard to totally remove all traces of the z-screw pitch effects, but this is particularly bad in your case, judging from the photos.
-
You generally can't take a single 2D picture and turn it into a 3D object - there's not enough information about the relative depths of the parts. But if you have lots of pictures taken from different angles, in theory you can get a 3D object using software like 123D Catch. Although I don't know anyone who has gotten particularly good results using it.
An alternative approach is to use various 3D scanners - you can use something like a Microsoft Kinect with suitable software (e.g., Skanect, ReconstructMe, or kScan3D) to capture a 3D model directly. These can then be printed very nicely with an Ultimaker.
Here's a couple of scans and prints I made recently - the larger one using KScan3D and a Kinect; the smaller a Carmine v1.09 and Skanect.
Both printed on an Ultimaker.
-
Yes, Bob is right - it sounds like you need to adjust the top z-limit switch (on the top of the back panel, on the left as viewed from the front - behind the left most z-axis guide rod).
Regarding the problem with the plexiglass not moving up with the springs - make sure that the washers under the bed aren't getting caught in the keyhole slots. I don't know exactly what the current shipping configuration is, but when I first got mine, about a year ago, the washers were too small, and would partially catch in the slots, making bed leveling a nightmare. Adding slightly bigger washers on top of the existing ones made a huge difference. I too used to dread taking the bed off - now I do it all the time, and don't need to re-level afterwards.
Then adjust your z=0 level. With the power off, move the head to it's home x-y position, and screw all of the bed-leveling screws about half-way in, and then turn the coupler on the z-axis to move the bed, until the bed is just touching the tip of the nozzle (doesn't have to be perfect). Then adjust the z-axis limit switch so that it is just triggered in this position. Be careful not to strip the threads on the switch - they can be weak. This will give you the right z-axis home, and enough room to adjust the screws to get the bed level.
To level the bed, heat the head, and then auto-home it. Release the steppers if needed, and then move the head by hand to near the front left leveling screw (but leave yourself room to get to the screw with the driver). Slide a sheet of paper under the head in that position. Tighten the screw until you don't feel any tension on the paper as you move it around. Then unscrew it slowly, until you just start to feel the head catching on the paper. Then give an extra 1/8 turn out to make up for the thickness of the paper. You want your z=0 position to be literally with the head just touching the bed, but not deflecting the springs any further. Repeat this in all four corners, moving the head each time, and then go back and check the first corner, and continue until all are just touching.
-
13.05 is the semi-closed beta for the new Steam Engine slicer. Details here:
http://umforum.ultimaker.com/index.php?/topic/2008-looking-for-beta-testers/?p=14856
Cura saves its full slice settings embedded in every file it slices. So the easy way to see what the settings are is to slice a file with quickprint, and then change to full settings mode, and 'Load Settings from GCode' from the File menu.
-
Yes... you were getting a temperature reading of 386 because of the loose wires, which is beyond the safety limits built into the Marlin firmware, so it shut down the heater. Now that you've tightened things up it should be good to go again.
-
No, its not really enough code to see what's going on - just a layer and a bit. Can you email me the full file to gcode@fbrc8.com?
Thanks!
-
Yeah, that doesn't sound right...
-
I've often thought it would be a good idea for UM to add some small slots in the walls in line with the rods and belts, to make it easier to align everything by sighting directly along the axes, rather than having to squint from a little bit off center.
-
Generally the right most set of slots (as viewed from the front) are where the feeder goes. Until fairly recently, these were the only set of slots. The other set are to add a second extruder, to feed a second print head (Which was announced as an upgrade 'coming soon' at Maker Faire).
-
Check that the end caps aren't too tight on the axis rods, preventing them from turning smoothly.
-
THanks, I'll look at the code...
Btw, if you click the 'more reply options' on the bottom right when replying, then you get to a more fully featured interface that should give you the option to attach files to the post.
-
Retraction is working for me in 13.05.1 on a Mac. Indeed, if anything it's working too well...
I have a print that has a 10cm long, 2mm thick 'thin wall'. With a 30% infill setting (and my non-standard 0.65mm nozzle), I end up with infill sections that are roughly 0.75mm long, and spaced about 2.5mm apart. And it does a retraction between each of them.... the extruder gear goes crazy filing in the wall - constant back and forth....
The net advance of the filament in between retractions is only about 1.75 microns - enough to extrude about 1/10mm³. After a while, it just gets too much, and it starts to grind the filament.
Not exactly sure what to do about it - maybe infill in thin wall sections could be done differently - longer diagonal moves, maybe? Maybe there needs to be some sort of minimum incremental extrusion since the last retraction, before another one can happen?
A crude solution would be the ability to set the minimum move distance for retractions to happen - but that seems to be missing currently.
Looking for beta testers.
in UltiMaker Cura
Posted
Thinking about custom gcodes made me realize something... In the new slicing engine, I see that you are using G0 for the moves. Which is a good step forward in terms of the logic differentiation of different types of moves, so thanks... except...
Isn't it technically wrong to use G0 for these? Because while in Marlin they are the same as G1's, as I understand it the point of G0 is that in theory the axes don't have to move in lock-step with one another. This means the path doesn't have to be a straight line, right? Which means that all of your carefully planned travel paths may not be going where you think they are...?