illuminarti
-
Posts
2,785 -
Joined
-
Last visited
-
Days Won
1
Content Type
Forums
Events
3D Prints
Posts posted by illuminarti
-
-
Since the printer starts every layer at 'exactly the right height', there's less scope for shrinkage in the z direction, although I guess it can happen a little bit.
The height is measured out a layer at a time, starting from the home position. So if your home position is fractionally off, that will affect your overall print height. Also, if you set a different first layer height in Cura, that will also affect you overall object height - I believe it slices the first layer as if it was the right height, and then just prints it fatter - causing everything else above it to move up slightly.
-
Excellent news! Thanks for facilitating this, Joergen. Let me know how to pay you for the postage etc.
Pulleys arrived today, and they will go out tomorrow via USPS (simple padded envelope)
-
If you have an UltiController, you can change it in Control -> Motion. It is the Acc setting. Any change will only last until you power-cycle the machine, unless you save the settings (Control -> Store Memory).
If not, then you can change it using a gcode that you send via Pronterface or similar, or include in your start gcode.
The command is M204 with an S parameter.
So, M204 S1500 would change your acceleration rate to 1500mm/s². The default is currently 5000. Used to be 3000.
All of that said, I don't think that you're overshooting due to acceleration. I think it's probably just the slicer coming up with a bad toolpath. I've seen that sometimes. If you'd care to post the gcode, I'd be interested to take a look.
-
Yes... but its hard coded to 5000 as the default in the UM fork of Marlin now. If you've previously saved your defaults into the EEPROM, then those are going to take precedence over the hard coded values, even after a firmware upgrade.
However, if you haven't ever written to the EEPROM, then you get whatever is coded in Marlin each time you boot up.
I'm actually running at 5000 at the moment, and not really having any problems. But I've got everything pretty well bedded in.
(The max acceleration doesn't really do much, btw. The acceleration you get is the lowest of the max acceleration for any axis involved in a move, and the 'one true' acceleration speed. Since the default max for x and y is 9,000 and the max for e is 10,000, in practice you get acceleration at the requested 5000 (or 3000) rate. Unless you also move in Z, which has very low acceleration, in which case you the low z rate applied to all axes).
I built a fresh Marlin within a few days of Christmas and my default accelerations are 3000 and max accel is 9000. These values have always worked fine for me. I increased my Z accel and speed since then.
-
Yes, it did - Daid changed it to 5000 in December for the Cura 12.12 firmware.
I wonder if that isn't a bit on the high side.... at least in conjunction with x/y/z moves as well. Might be something to try changing when troubleshooting skipped-step problems (once loose pulleys and gross mechanical issues have been ruled out).
I think it used to default to 3000 - but at some point got increased to 5000 as a default. I need to hunt that down, because I'm not sure that isn't a big part of the reason people are having more and more skipped steps issues....
-
I think it used to default to 3000 - but at some point got increased to 5000 as a default. I need to hunt that down, because I'm not sure that isn't a big part of the reason people are having more and more skipped steps issues....
Acceleration is set for 5000. I'll lower this to 3000 as an experiment and I'm going to make adjustments with pulleys and belt positions now - I'll report back and let you know. Thanks!
-
Well, it looks a lot better - up until the point where it stops looking better :-)
Its a bit hard to see the sides, but it seems pretty clean - the top looks like it might be under=extruded a bit, but it's hard to tell, as it was also the first layer going down over infill, and that never extrudes really well anyway.
Once you get the Bowden sorted out, do the print again, and post the results, and we'll advise further on any extra tweaks.
Well done for working through all the issues :-)
-
What's your acceleration setting show as in the UltiController? I think that's Control -> Motion -> Acc, if I remember correctly.
I think it defaults to 5000.... you might try lowering that to about 3000 if so, and see if that helps any. In general though, it sounds like you need to just clean things up a little with you mechanics, and get everything sliding around smoothly. The print problems that you're having are almost certainly a result of overtaxing the steppers on some fast moves, due to the binding and rubbing that you mentioned. (And yes, there could be some pulley slipping in there too!)
Regarding belt positions... you just want to make sure that the pulley on the motor and the corresponding one on the axis are directly in line, so the short belt can turn smoothly as it passes from one to the other, without rubbing against the sides of either pulley. And then the pulleys for the long belts need to be lined up on the path through the sliding blocks, so that the upper and lower sections of belt are directly one above the other, and again the belt travels in a constant plane, and isn't being deflected to the sides as it passes over the pulleys. I.e., the long belts need to remain parallel to the closest side of the UM frame at all points of their length - top, bottom, as they clamp into the sliding blocks, and as they pass around the pulleys on each end.
-
It looks like you are either missing steps, and/or having the pulleys slipping. Did you slice it with 'Duplicate Outlines' or 'Joris' enabled, by any chance?
I'd start by making sure that all of your pulleys are properly tightened. Use a sharpie to mark the pulley and rod that it's connected to, and make sure the pulleys aren't shifting on the rods. Even when they seem to be tight, the pulleys can sometimes move. If you got spare grub screws with your printer, you may need to swap out some of the screws with replacements if you can't tighten the existing screws enough to stop slipping.
Also, make sure that all the belts are running smoothly, and not catching on the frame, or running up the sides of any of the pulleys.
Then, with the printer off, try moving the head by hand. You should be able to move it with fairly light finger tip pressure on each pair of sliding blocks - and the required force in both X and Y should be the same. If you can't, then check i) that the end caps aren't too tight on the axis rods; ii) that the axes and cross rods are square and level; iii) lubricate the rods with a little light sewing machine oil.
Once that is all taken care of, try reducing the travel move speed in Cura to about 100 mm/s, and see if that helps things. You should be able to go faster than that, but it looks like it's probably the travel moves between layers that are failing somehow, so start by slowing them down, and see if it helps.
Also, if you have an Ulticontroller, under the control->motion menu - what are your current AmaxX and AmaxY settings?
-
Looks like the latest Steam Engine beta doesn't let you configure print order. But for this model at least, what you get is basically the same as 'loops, perimeter, infill' in the above example.
-
And so do you ... :-)
For the benefit of those following along at home... the STL was fine, and it printed pretty well for me at 75mm/s with 0.09mm layer height. Nick didn't have a gcode file he could share, so it's hard to know exactly what was going wrong - but something about the settings he used was evidently pushing the printer out of its comfort zone.
-
Also, a photo of the failed prints would be helpful for diagnosis.
-
Nick -
I think we can say with some certainty that there was nothing wrong with the gcode in and of itself. It's a very simple language, so almost certainly the gcode was a faithful representation of your model. So the fact that it failed means that one of two things happened - either there was something bizarre about the geometry of your model, or more likely, your settings were such that you were asking the printer to do something that was just beyond the bounds of its capabilities. If I had to guess, I'd say you probably had a non-printing x/y/z move that was faster than the printer could execute, resulting in skipped steps, which causes the printer to lose its place on the bed.
If you'd care to upload your gcode (or email it to me at gcode@fbrc8.com) I'd be happy to take a look and see if I see anything that might cause problems.
-
Just to clarify, by specifying the print order you can control the print order of loops, perimeter and infill, but not the order in which individual 'islands' get printed, which I think is what would probably make the most difference in Lewis's case, and what he was asking about.
To test this, I created a simple STL of a square block, with a square 'ring' around it, and then sliced it in Cura 13.04, with a.) loops, perimeter, infill and b.) perimeter, loops, infill. I used 0.8mm wall setting to give two passes around the walls, and I turned off the 'force first layer' option that overrides print order.
Here's what the first layer looks like viewed in Repetier host:
The numbering shows the print order, when requesting that loops print before perimeters. It starts with the inner pass of the ring's inner surface, then the inner pass of the rings outer surface. Then comes the ring's finished outer surface, followed by the ring's finished inner surface.
Then in does the infill for the ring, so that that part gets completed before it moves on to the inner block.
Then it does the inner pass around the skin of the block, followed by the outer surface of the block, and finally the block infill.
If you change the print order to perimeter, loops, infill, then it prints the finished surfaces first, followed by the interior passes along the skins. So, reusing the same numbers, the print order becomes: perimeters first - 3,4,7 - then the block loop, 6. Then the block infill, 8. Then it goes to finish the ring - doing the loops, 1, then 2. And finally the infill 5.
So the perimeters can be thought of as any finished surface that touches empty space (even if on the 'inside' of the object). Loops are any additional passes around the circumference of the print that touch other loops, or infill (or would touch infill if the infill % was greater than zero).
-
Yes - accented and non-English characters cause problems in the Skeinforge back-end that Cura currently uses. Several problems have been fixed, but not all yet. For now, best just avoid them.
-
Glad you got it figured out, it can be a little tricky at first. For anyone else finding this topic, and having problems, here's a video someone posted that shows how it works...
However, I recommend not using the UltiController to advance the filament - it can push it too quickly, and cause problems. Instead, just turn the big gear wheel by hand... it's hard to turn it faster than the nozzle can keep up with, and you can get a good feel for the resistance that builds up in the head if you do try to go too fast, and so can slow down a bit.
-
Welcome, Matthieu!! I wouldn't worry too much about having spare screws - I think you usually get a few extras! Good luck getting the last things in place, so that you can start printing!!
-
¿Recibiste la ayuda que necesitabas?
-
I'd guess that the problem with under extrusion on higher layers is due to pressure build up in the head. When you stop and restart the print, the pressure has some time to normalize as excess plastic oozes out. In the second video when the head does its travel move to start a new layer, you can see that it kinda globs out plastic. So I think maybe the excess pressure is causing under-extrusion (similar to what I discussed in my blog post). What extrusion width setting are you using in Kisslicer? Also what do you have set as the minimum and maximum extrusion rates?
-
When measuring your filament, I'd recommend always measuring in two perpendicular directions at each point, and then calculate the cross-sectional area at that point, compared to the nominal perfectly circular 2.89 mm diameter. Often the cross-sectional area will vary less than the maximum diameter, because often what is happening is that the filament is becoming slightly oval, not actually fatter all the way around. Within reason, a small amount of eccentricity in the shape isn't a problem - mostly you need a constant cross-sectional area.
That said - 3.09mm is probably enough to get your filament stuck in the Bowden tube - that could certainly cause extrusion problems. A 2.89 to 2.93mm variation in average diameter is unlikely to be noticeable by itself, but if the filament is getting stuck, then you're going to have more problems.
-
It's hard to tell the difference between old and new, since the 'old' on is rather out of focus in your photo.
The new doesn't look too bad all things considered. but on the extreme left it looks like there's some underextrusion. It may well be that the new filament is a smaller diameter - have you measured it?
What speed, layer height and wall thickness are you printing at?
-
Although blockages can be due to mechanical issues, a very common cause is trying to extrude at too high of a flow rate. The standard head can handle at most 8 - 10 cubic mm of plastic per second. Any more will cause a build-up of pressure in the hot end, and result in the filament grinding at the extruder end, and/or molten plastic squirting up into the cooler parts of the hot end, and solidifying there.
The volume per second can be calculated as layer height x nozzle width x print speed. E.g., with a 0.4 mm nozzle width and 0.2mm layer height, printing at 50mm/s, the volume per second is 0.4 x 0.2 x 50 = 4mm³/s.
Some things to watch out for are that increasing layer height - say to 0.3mm - can quickly increase the volume per second. Also, in Cura if you set a wall width that is not an exact multiple of your nozzle width then Cura will adjust your effective nozzle width (see my blog post for details - although the specific bugs discussed there are supposedly fixed in Cura 14.04 - such that the print path spacing is now correct).
So fo instance, if you have a nozzle width of 0.4mm but specify a wall width of 0.6mm, and a layer height of 0.3mm - then at 50mm/s the volume per second is now 0.6 x 0.3 x 50 = 9mm³/s - enough to potentially cause problems.
Another thing to watch out for is if you use the ulticontroller to advance the filament when changing filaments - the Ulticontroller tends to also advance the filament at a rate that is too fast for the nozzle to handle, and can cause instant jamming in my experience. I recommend advancing the filament by turning the gear wheel by hand - that way you will be able to feel the resistance when you try to turn too fast, and can adjust accordingly.
These issues may not be anything to do with the problems that you are both reporting, but it's something to be aware of, so I thought I'd mention it. :-)
-
Hi Mike -
Welcome to the forums, and to 3D printing!
Are you sure Cura hasn't sliced the base? I think the latest Cura doesn't necessarily show solid infill layers at the bottom of the print when showing all of it - it's a display efficiency optimization, I think. Use the slider on the right of the 3D view pane to step back to the first layers, and see if the base layers show up when just viewing the start of the print.
Currently Cura has a problem filling in small areas, such as the insides of small walls. For this print, I'd trying setting the wall width in Cura to 0.4mm - that will give a single pass along the perimeter of your object, and the slicer should then do a better job of correctly filing in the gaps. I'd be inclined to set a fairly high infill percent - at least 30% maybe more - in order to tie the walls together, and give a fairly well filled-in slab base that covers over easily. I'd also set the top/bottom thickness to 0.8mm or 1mm - to get 4 or even 5 (0.2mm) layers of solid plastic, so that any gaps in the infill have maximum chance to fill in correctly.
Personally, I wouldn't use a raft. I've never had much luck removing them. Assuming you're printing with PLA, I'd just cover the bed with the widest blue tape you can find, and wipe it down with isopropyl alcohol before you start printing. I'd try leaving the fan off for the whole print, or only start it on a high layer, after the base is printed. The challenge that you're going to have is that your print is likely to warp - the wide flat base is going to tend to curl up as it cools, pulling it off the print bed. Best case, this will leave the base of the print curved, worst case, the head will keep hitting the curling plastic and damage or detach the model. Using alcohol-wiped tape, and as little fan as possible will help to fix this.
(If you do this, you'll probably tear the tape when you take it off - in which case just sit the base of the model in a few mm of alcohol for 5-10mins when you're done, and the tape remains will slide right off.)
-
As George noted, I think a lot of your problem is mostly with the 'thin wall' problem that causes Cura to not fully infill small spaces. Making sure that your wall thickness = nozzle width may help with that.
To do that you'll need to enable the normal settings in Cura, not just the 'quickprint' settings, You can then enable retraction as George mentioned.
I think you are also under-extruding a little bit, so that the individual lines that you print don't really merge together into a solid. Make sure that you're extruder drive spring isn't too tight or too loose (the length of my spring is about 11mm - it shouldn't be totally compressed, nor too loose). Also, you need to measure the width of your filament, and use the real size, not the default of 2.89, in order to ensure that the slicer requests enough plastic to make the printed lines be the right size.
Print upon objects
in UltiMaker 3D printers
Posted
Yes, you would need to add support most likely if printing a cup upside down. The problem you are going to run into though is how to fix the cup firmly and correctly on the bed, after you've removed it, so that it will stay stable, and any further printing will be in the right place.
A better approach might be to assemble the finished object from separate pieces and then weld, glue or screw them together.
You can also put pauses into your gcode to allow you to e.g., change filament as the print is building up. You can also edit the gcode to allow you to rehome and start a new print on top of an old one - you jsut have to edit the z coordinates in the second print, and/or redefine the coordinates. The main problem is going to be if you have to take the print off the bed, and then re-attach it somehow.