Printing layers in 60 microns - success

Hi all,

based on rayhicks clever suggestions tweaking the slic3r settings to circumvent problems while printing 0.12mm layers with the current firmware/ hardware I did some more tests with even finer layers. After tweaking some more settings in slic3r (settings for 0.12mm won't work) I could successfully print an object which I already did in 0.24mm and 0.12mm (see this thread) with layers as fine as 60 microns (or 0.06mm). For comparison: A hair has a diameter of about 20 to 180 microns/ micrometers.

As soon as I have found out which settings in slic3r are really crucial for printing such fine layers, I will post them in this thread. As you can see in the pictures there are still a lot of things to be improved.

Disclaimer: Printing 60 microns takes A LOT of time, it may be more suited to tweak the gcode in certain parts manually than printing the whole object with that sort of fine layers.

Following are some photos, first 0.24mm, then 0.12mm and then 0.06mm layers from the same object:







Markus

Edited 1 time(s). Last edit at 01/11/2014 10:47AM by markbee.

---

XBee & electronics blog: [lookmanowire.blogspot.com]

Markus, have you tried constraining the extrusion width (under advanced in print settings) - try setting default to 0.5 to start with, this prevents it overapplying infill (and has worked well at 0.24mm for me), and from my 0.06mm tests so far (which are on single perimiter shells with no infill), it works better than letting slic3r calculate the width, hopefully I'll get a photo up later and will send you my settings,

cheers

Ray

Hi Ray,

yes I reduced the extrusion width at least for the infill to about 60% because before I had problems with infill crossing the perimeter (because of overextrusion?) and then everything again began to rumble.
I also switched to concentric infill to avoid any crossing of the perimeter walls. Also increased the speed to 40mm/s for some of the travel distances.

Markus

Edited 1 time(s). Last edit at 01/11/2014 10:58AM by markbee.

---

XBee & electronics blog: [lookmanowire.blogspot.com]

Hi Marcus,

here are some photos of my 0.06mm prints - I've got definite banding occuring, which I think is due to irregularity in the z drive (maybe backlash in the gears or the thread or both, unfortunately can't eliminate this since the workaround involves winding Z up and down for each layer change).

The piece I'm printing at 0.06 is a 50mm X 50mm x 7mm tray with 0.5mm thick walls and base, the first photo shows one wall of the tray with a cylinder printed in black (with 0.24 steps) behind the wall:


you can see the banding, but otherwise the walls are pretty straight and well defined

the second picture is a close-up of the banding, you can see a few layers squished together at the bottom of the picture then a few at full height -this pattern repeats I think 8 times over the 7mm height:



I've used exactly the same settings (except for layer height) in the photo, it's 0.12mm blue wall 0.24 cylinder behind - the banding seems to be the same pitch:


I'll run the same print with 0.24 with raise-on-retraction on and off and see if the banding correlates with the winding or if it's something else...

Hi Ray,

your 0.06 looks awesome! The pattern looks suspicious like a slicc3r-, hard- or firmware issue? I haven't experienced banding at all. Did you print with repetier host? What were your slic3r settings (esp. for the infill)? Any change with the extruder settings?
Esp. in the 0.12mm print (last photo) it looks like 3/3 pattern and very periodical. I would definitely look at the infill settings.

[EDIT: Did you print it with the original gears?]

Markus

Edited 1 time(s). Last edit at 01/11/2014 12:10PM by markbee.

---

XBee & electronics blog: [lookmanowire.blogspot.com]

I'm fascinated and excited by these results, but what I can't get my mind round is the following:

The extruder feeds the PLA under stepper control so assuming no slip then a controlled amount of PLA is fed into the system which is presumably calculated from the z height increment (layer step) and the extruder tip velocity.

If this has any error then either a slight gap in the width extruded will occur as the filament being extruded is controlled in the z direction, or of too much is extruded then an overfill and bulging of the extruded filament will occur.

Is this assumption on how this part of the process works correct?

If so 'banding' may be related to slight over extrusion on the feed?

---

Ormerod #007 (shaken but not stirred!)

Hi Treth,

One has to have definitely an eye on what I call "overextrusion" - not sure if it is the right term though.

I adjusted some settings concerning this after having trouble in most of the test prints with fine layers. Not sure as stated above if they make sense:

Printer settings -> Retraction - > Length: changed this to 3mm // avoid dripping excess filament
Printer settings -> Retraction -> Speed: changed this to 45mm/s // avoid dripping excess filament
Print Settings -> Layers and Perimeters -> Advanced: Randomize starting points ticked (enabled) // avoid blobs at certain points
Print Settings -> Infill -> Fill pattern: concentric // avoid crossing the perimeter when overextruding
Print Settings -> Infill -> Speed for print moves -> Infill: changed to 40mm/s // more speed more extrusion accuracy?
Print Settings -> Infill -> Speed for print moves -> Solid Infill: changed to 40mm/s // more speed more extrusion accuracy?
Print Settings -> Advanced -> Extrusion width-> Infill: changed to 60% // thinner infill pattern, less danger of overextrusion, crossing perimeters

Markus

Edited 1 time(s). Last edit at 01/11/2014 12:22PM by markbee.

---

XBee & electronics blog: [lookmanowire.blogspot.com]

Hi Markus,

No infill at all - it's just printing the shell (1 perimeter), not exactly a real world print, but useful for removal of other sources of problems (like infill!) - I've just printed at 0.24 with lift on restraction and there's still banding, am now printing at 0.24 without.

I have the feeling that it's my Z-drive, I printed a new drive gear yesterday since the old one was pretty slack, this one probably needs a bit of filing, you can hear (and see) a difference in Z movement if you lift it say 10mm, there's a slowing and speeding up - the tighness of the gear and the wonkiness of the trheaded rod are probably contributing to teh banding I's say this file shows the 0.24mm print (with the 0.3mm lift on retraction):



Here's the one I printed while typing the above- this time no lift on retract, it still shows the banding, so looks like it's not really anyhting to do with the lifting ( really do suspect my z gears):

@Markus,

That is really useful and I didn't know such fun was on the horizon, indeed I hadn't considered just how many parameters there are!
Your post above should be a 'sticky', I have saved a shortcut to it, thanks.

---

Ormerod #007 (shaken but not stirred!)

@ treth, yes indeed I think you're right, but in this case the banding runs solidly around the four walls (and corners) of the print - if it was extrusion, it's hard to see how it would vary almost sinusoidally with height at the same pitch with different thickness layers.

The Slic3r manual suggest a method for fine tuning the extrusion (using a shell like the one I'm printing here) - you slice an object with no top layers, (say) two bottom layers, and a single thickness perimeter. Slicer then makes a lidless shell of whatever solid stl you feed it (in my case I'm using a solid cube). You then set the extrusion multiplier in "filament settings" to 1.0 (which is the default). look in the gcode, and among the first few lines you'll see slic3r tells you what the perimeter width is intended to be (say 0.8mm). Print the shell and measure the actual width (making sure that you don't over-estimate by including non-aligned layers!). You then ratio the intended width by the actual measurement (say you measure 1.0 mm, then the result would be 0.8) and you put that ratio into the "extrusion multiplier". This works as an adjunct to actually calibrating the filament feed length and diameter of course (which puts everything into the right ball park in the first place), and is intended to adjust slic3r's maths for your real-world machine

Ray

I've just done some tests on Z axis movement in small steps. I'm using the attached file, which moves the head between two XY positions repeatedly and raises the height by 0.1mm between each move. It seems to be working fine. I'm using direct print over USB with my firmware changes (which mimic printing from the SD card) and Pronterface patch.

Would you care to test it? If it works for you too, can you try to construct a Gcode file to demonstrate the Z axis problem you reported, preferably without extruding anything? Maybe you can start from the file you were trying to print, and remove the extrusion codes. If you can construct a file that reproduces the problem, I'll try to look at it tomorrow.

---

Large delta printer [miscsolutions.wordpress.com], E3D tool changer, Robotdigg SCARA printer, Crane Quad and Ormerod

Disclosure: I design Duet electronics and work on RepRapFirmware, [duet3d.com].

Will do DC - in the meantime, have you tried running your file from SD? It may prove enlightening...

Quote
rayhicks
Will do DC - in the meantime, have you tried running your file from SD? It may prove enlightening...

I just tried it from SD. It still works.

---

Large delta printer [miscsolutions.wordpress.com], E3D tool changer, Robotdigg SCARA printer, Crane Quad and Ormerod

Disclosure: I design Duet electronics and work on RepRapFirmware, [duet3d.com].

@ Markus,

I printed a new driven gear, and the whole thing runs more smoothly now, below is a photo of a wall with the same 0.24 mm cylinder behind [edit!] the picture on the left is post-gear change, the one on the right is the same as in the original post - I uploaded that in error originally![/edit],

also a close up of the same wall:


and some human hair (well mine anyway) at the same magnification

Edited 1 time(s). Last edit at 01/11/2014 06:03PM by rayhicks.

Hi Ray,

what was the extrusion width of your hair?

Print (photo 1) looks good but still a pattern of periodical banding?

Markus

---

XBee & electronics blog: [lookmanowire.blogspot.com]

@ dc - indeed your file worked fine via usb or from SD, I've attached gearfail.gcode a simple file that works over usb, but not from SD (the gears twitch when run from SD, but not from USB - note it seems to have always been the case that USB-based small Z steps worked), the gcodes file from the same stl file slic3d with a 0.3mm lift on retraction print properly from SD (ie the gears move properly)

not sure on the width, but it took a long time for them to extrude (and the extruder is failing rapidly!)

I put the wrong picture up (ie the original one) - I've edited the post to show the new one side by side - sigh it's getting late. Actually now the vertical rippling seems to dominate the artefacts - presumably due to vibration or maybe extrusion judder?

Excellent work in this thread, very impressed. I don't think I ever got below 0.1mm with my home-made printers. If you are trying to work out other layer heights to go for that are whole steps, use the "Optimal layer height for your Z axis" section of Josef Prusa's Calculator: [calculator.josefprusa.cz] Anyone for 4 micron layers?! That's 1 full step in Z...

Things you need to know: we use M5 rod with a 0.8mm pitch. Full motor steps per revolution = 200, microstepping = 16, gear ration is 1:1.

A couple of pointers that may help:
You can set the first layer height independently. So it may be worth setting it to 0.1 or 0.2mm (yes, these are full steps; 25 and 50) for the first layer, so you have a bit more on the bed to start with, and flatten out.

We supply M5 Bright Zinc Plated (BZP) studding for the Z leadscrew, and a BZP M5 nut. Before going the whole hog and getting some fancy machined ballscrew (£££), try M5 stainless steel (A2 or A4), with a brass M5 nut. The thread of the stainless should be better cut than BZP, and it slides more smoothly on the brass nut than BZP on BZP.

Get rid of as much backlash as possible in the Z gears. There's actually not much torque on these, but they can move. A drop or two of superglue on the motor shaft (but not so much it goes in the motor) and on the hex nut on the driven gear should hold them much better, if they're prone to moving.

Try doing a 'vase' print. This is like a spiral print, so the Z axis is in constant motion, upwards, except for the first couple of layers (though it may be a victim of the Z-small-move bug). There's a blog post on this here: [slic3r.org]

Hopefully, we won't take too long to update the firmware to remove the Z-small-move bug, whatever it is.

Ian
RepRapPro tech support

@Ian

Should have said that: I already use M5 A2 threaded rod with precision M5 nut almost from the beginning. Gears are filed for optimized smooth run both at z-axis and at the extruder drive. I don't use the original, supplied ones but printed them myself. The z-gears sit very tight on both the nut and the motor shaft. I also printed the z-nut-trap and didn't use the original x-rib because it was too fragile.

Thx for the other tips, will try them the next days.

Markus

---

XBee & electronics blog: [lookmanowire.blogspot.com]

Quote
rayhicks
@ dc - indeed your file worked fine via usb or from SD, I've attached [attachment 24590 gearfail.gcode] a simple file that works over usb, but not from SD (the gears twitch when run from SD, but not from USB - note it seems to have always been the case that USB-based small Z steps worked), the gcodes file from the same stl file slic3d with a 0.3mm lift on retraction print properly from SD (ie the gears move properly)

OK, that file fails for me printing over USB with lookahead enabled. It's driving the z-gear too fast. I think I can see a possible problem in the firmware.

---

Large delta printer [miscsolutions.wordpress.com], E3D tool changer, Robotdigg SCARA printer, Crane Quad and Ormerod

Disclosure: I design Duet electronics and work on RepRapFirmware, [duet3d.com].

Try this firmware - it fixes it for me.

---

Large delta printer [miscsolutions.wordpress.com], E3D tool changer, Robotdigg SCARA printer, Crane Quad and Ormerod

Disclosure: I design Duet electronics and work on RepRapFirmware, [duet3d.com].

Regarding potential backlash in the Z gears:
It looks as though the threaded rod could be relocated to come up through a new hole in the X axis rib - directly above the Z motor spindle, so enabling a direct drive (no backlash).
It looks to me resiting the threaded rod would not foul anything, and cause no restrictions on movements.
Thoughts?
Greg

---

Ormerod #17

That was quick! Have to see if I can nip into the office and try it out, hopefully Markus will try it also...
Cheers

Ray

@ gregl my thoughts exactly, I already printed a flex coupler, just need to take a deep breath and work out a nut trap position. It looks like it may foul the x-axis slide rod though (maybe a bar clamp with integral nut trap would work, but the head would no longer retract fully along x either. The other option would be to move the motor, but that's a lot of work. (Edit) one other consideration is the thrust, presumably this is why the gears are used (to remove the weight of the axis from the motor spindle and onto the bearing under the driven gear, of course a thrust bearing could be used on the face of the motor body to support the coupler and shaft (/edit)


Ray

Edited 2 time(s). Last edit at 01/12/2014 06:38AM by rayhicks.

Hm I was already into a touch screen solution for controlling the Ormerod independently. Should I revisit the micron-layer-thing?

Markus

---

XBee & electronics blog: [lookmanowire.blogspot.com]

@ ian

Quote
droftarts
Try doing a 'vase' print. This is like a spiral print, so the Z axis is in constant motion, upwards, except for the first couple of layers (though it may be a victim of the Z-small-move bug). There's a blog post on this here: [slic3r.org]

I've tried that, it did suffer from the problem Slic3r 1 rc2 has a tick box option for spiral vase now by the way, so pretty easy to slice them

I'll be trying a brass or delrin nut and seeing what stud stock I've got (though I think it's mainly M2 - M4 in brass and stainless, and these are probably too whippy for lifting the x axis). Graphite (eg lock lube) might be more of a "best of both" solution - high pressure anti-gall, but dry and little dust gathering (oils/greases tend to trap dust including worn metal shavings, which can turn into a grinding paste quite quickly unless it gets flushed out by fresh oil).

I actually have some scrap ball screws and nuts that I'd considered trying, but they have a pretty large pitch and were designed for servos, not sure the stepper has enough torque to lift the axis without a lot of mechanical advantage from a low pitch thread - also the ball screws I have wouldn't hold the x-axis up if the motor was off (the pitch is high enough that you can slide the nut along with very little force, spinning the leadscrew - the motor would have to resist this torque or the axis would drop, it could probably do this when energised, but the axis would drop when power was cut ).



Ray

Quote
rayhicks
@ ian

Quote
droftarts
Try doing a 'vase' print. This is like a spiral print, so the Z axis is in constant motion, upwards, except for the first couple of layers (though it may be a victim of the Z-small-move bug). There's a blog post on this here: [slic3r.org]

I've tried that, it did suffer from the problem Slic3r 1 rc2 has a tick box option for spiral vase now by the way, so pretty easy to slice them
Ray

It's actually a different problem, although the symptom may be the same. Unlike the vase print, your gearfail.gcode file doesn't contain XYZ (or XZ, or YZ) moves. What is does contain is extruder-only moves adjacent to Z-only moves, and the lookahead stuff (which used to be used only for the SD card, but I've enabled for direct USB print too) was adjusting the z speeds to silly values. That is what I fixed in my firmware build.

EDIT: I've just updated the build here to also speed up uploading to the SD card (needs the Pronterface patch as well to work at full speed).

Edited 6 time(s). Last edit at 01/12/2014 07:19AM by dc42.

---

Large delta printer [miscsolutions.wordpress.com], E3D tool changer, Robotdigg SCARA printer, Crane Quad and Ormerod

Disclosure: I design Duet electronics and work on RepRapFirmware, [duet3d.com].

It might be fun to try something like the threadless ball screw designs for the Z axis: [www.thingiverse.com]

Ian
RepRapPro tech support

@dc42 - just trying your updated (12:15) build, and it runs gearfail.gcode perfectly from SD! Thanks for the fix, now we can fine print via sd without the workaround (the workaround of making bigger moves by lifting the head on filament retraction is more prone to backlash in gears and thread/nut wobble - now the gears and thread are loaded in the same direction constantly). Thanks also for the USB work : - printing direct from USB makes for a faster turnaround (and if the upload to SD is also sped up by your latest fix, then it means less turnaround time for SD-based pritning too).

Printing many test files from SD has highlighted another problem (which may be repetier host-based, or may be a limitation of the the firmware) - once I get 24 files in the gcode directory, I need to pop the SD out and delete some using my mac - there seems to be a limit of 24 files (as I say it might be repetier's problem) and deleting via repetier doesn't work (there's a delete icon, but it isn't active) - I guess I should check using pronterface...

Cheers

Ray

Quote
droftarts
It might be fun to try something like the threadless ball screw designs for the Z axis: [www.thingiverse.com]

Ian

Very interesting! - gotta be worth a go

Ray