0.12mm layer printing - success

Hi,

still not successful printing with 0.12mm layer after some time now, rayhicks and I were chatting about different reasons for the unusual behaviour when going lower than 0.24mm.
In this thread there is some more insight, the findings and the workaround rayhicks suggested. So with this workaround printing in 0.12mm is now possible - here a comparison of my first successful print in 0.12mm. There are still some settings to tweak (overextrusion, temperature, retraction length) but at least it works.

Overview (left 0.24mm, right 0.12mm):



Direct comparison



Markus

P.S. I started a new thread to compare photos from different users in 0.12mm rather than digging into details about the firmware/ hardware issues which can be done in the other thread.

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

---

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

0.12mm prints look great - far far better than what I'm currently getting. Any chance you would mind sharing your slic3r settings/any modifications you've made markbee?

The trick is to tell the ormerod to make big moves in Z - it seems to only twitch the z motor if you tell it to do something less than .24 mm. So, in slic3r you tell it to retract the filament on layer change, and also to raise Z on retraction, I (and I think Markus) told it to raise Z by 0.3. This makes it wind Z up by .42, retract the filament by whatever length you have set, and then lower z by 0.3 (giving a net change of 0.12).

We should be able to go lower than 0.12 (we decided that 0.12 would be sensibe since it works out to be an integer of steps for the motor and didn't want t oconfuse issues while we homed in on what the helll the settings should be) but neither of us had the time after we hit the workaround to try out much more [edit] what may screw this up is the backlash in the z drive gears, but I plan to try a flexible shaft coupler to directly drive the threaded rod/ studding to remove the backlash, while still not over-constraining the drive - the studding is pretty bendy and having a rigid coupling to the motor would probably cause missed steps or total binding[/edit]

Ray

Edited 1 time(s). Last edit at 01/10/2014 05:36PM by rayhicks.

Quote
rayhicks
The trick is to tell the ormerod to make big moves in Z - it seems to only twitch the z motor if you tell it to do something less than .24 mm.

From your earlier post, I presume you mean that this is only a problem when printing from SD?

Have you looked at the gcode to see what Z-axis command slic3r is actually generating?

---

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].

yep,for <0.24mm it tells it to move the right amount at the right speed (0.12mm @30mm/sec), the firmware then moves it the wrong amount (just a twitch) if the command is read off SD, or the right amount (1/8 turn) if sent by USB. Testing various speeds, it still twitches from SD and moves the right distance from USB commands (unfortunately every thing else is screwed when printing over usb).

For 0.24mm or above, Z moves are good either way.

it's embarrassing that it's taken more than a couple of weeks to come up with a workaround (tell it to move up more than 0.24 then move down more than 0.24) but what the heck, I have a job to do as well - Ian promised on the 5th to provide some settings that work but we'd already discussed this with him before christmas in irc.

Quote
rayhicks
yep,for <0.24mm it tells it to move the right amount at the right speed (0.12mm @30mm/sec), the firmware then moves it the wrong amount (just a twitch) if the command is read off SD, or the right amount (1/8 turn) if sent by USB. Testing various speeds, it still twitches from SD and moves the right distance from USB commands (unfortunately every thing else is screwed when printing over usb).

So are you saying the command in the file on the SD card is G1 Zxxx F30, where xxx is 0.12mm above the current Z position; and that the same command works OK as a USB command?

I'm currently examining the lookahead code in the firmware, which is active only when printing from SD. I'm thinking that it should be disabled for Z-axis moves.

EDIT: 30mm/sec is wrong, the max rate supported is 3mm/sec. But the firmware should be limiting it anyway.

Edited 2 time(s). Last edit at 01/10/2014 05:54PM 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].

Hi Markus

I think I said I'd try to look at it! But clearly, something is going wrong here. We had (another) meeting about the firmware on Tuesday, and I talked to Adrian about the problem of skipping steps in Z (in combined XYZ moves), but hadn't got around to trying any low layer heights. This absolutely should work robustly - it's fundamental - I will email Adrian now to get his view on it.

Ian
RepRapPro tech support

PS Nice prints!

Edited 3 time(s). Last edit at 01/10/2014 06:17PM by droftarts.

@dc42, I think F3600 is 60mm/s and 30mm/sec is F1800, but I'm not sure cos I'm not at my machine, whatever the F value is, they're identical when using the same file sent live over usb or from SD, if there are limits, maybe one of the methods ignores the limit (my guess would be the SD, and the motor twitches cos it sends all the pulses in one go). By default (and I don't think there's a workaround) Slic3r uses one speed for all axis moves when not extruding (look thpough any of your gcodes). it's pretty much irrelevant though - it's not the speed, but the magnitude that causes the problem - if the movement is too small it causes twitching at any speed from SD, which is why the workaround is to make it move further (say) 0.36 up then move back 0.24 down to give a net 0.12 move at any given speed, it will do this reliably from SD. Telling it from SD to move just 0.12 it will twitch. Telling it to move 0.12 from usb (either directly using manual input with varying speeds, or by sending it print job over usb direct rather than getting it to run the same file from SD) it doesn't twitch, but moves the right amount.

@Ian great

Ray

@Ian
No problem at all. I know you still have to be very busy with supporting ppl who are currently building the Ormerod. It was just we were chatting and thinking about going lower in layer height and rayhicks came up with a clever solution Maybe this discussion helps to get the firmware right, too.

Markus

---

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

Congrats on your fine print !

regards
Andy

---

Ormerod #318
www.zoomworks.org - Free and Open Source Stuff

Nice prints Markus !