Z drive firmware issue

Markbee and I have both been trying to print fine layers (ideally somewhere around 0.1mm), but have totally failed. Today I started looking at the Z drive and realised that the driven gear wasn't turning as much as I'd expected - I printed a new drive gear (since I thought mine was slipping and wasn't able to turn the driven gear), but no improvement.

We've both just tried various slicing thicknesses and it's apparent that the Z motor doesn't turn properly running fine prints off SD card (interestingly it DOES work properly, ie move 1/8 of a revolution for 0.12mm layers) when the gcode is fed over USB, but pretty much just twitches when the same gcode is run from SD card.

To test wether it's an inertia thing I've been running the files with the driven gear removed and have been observing the drive gear rotating.

It'd be handy to get this fixed since USB printing sucks as far as movement in the other axes and extrusion go ...


Ray

Have you oiled the Z screw thread? Also check the gear teeth are smooth, and tidy with a needle file if not.

Dave

Its good to have narrowed it down any way! Perhaps the stepper timing is diiferent between reading the SDcard and the USB serial port. It would explain why printing fine layers drags stuff about for dure!

regards
Andy

---

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

@dmould

I have exactly the same observations as rayhicks with the same twitching gears. Mine are normally running very smoothly so no problem with that.

I peeked at the code and saw that inputs from serial are handled different fromt those from web or sd card. There is an additional condition where it is checked whether an html file is uploaded. This and the "slow" 115kbps could add to the observations made with "blobby" prints.

Markus

---

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

@ dmould - the observations above were with the driven gear removed - the drive gear wasn't meshed and there's no thread involved

@kwikius, indeed - I guess there's something different in the firmware, and hopefully it'll get fixed.

talking it through furhter with Markus made me hit on the idea of getting slic3r to raise the nozzle on retraction - I set it to 0.3 mm, so each new layer it raises 0.42, retracts then drops 0.3, and it seems to be working fine so far!!!! Unfortunately this IS just a workaround, since now it raises the issue of backlash in the gearing, a firmware fix would be essential to get the best performance. I've started on a hardware fix for the (pretty poor) gear/stud comination, which would be a flexible shaft coupler (printed of course!) to drive Z direct off the motor - the gears don't do anyhting useful, other than offset the drive and introduce backlash and the chance to bind up they both have the same number of teeth.


Ray

There is indeed a difference between printing via SD and printing via USB. See this post and the following ones. However, the thought was that printing from SD was correct, and printing via USB was wrong, because printing via USB doesn't work very well. Perhaps this needs to be looked at again.

---

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

for the sake of completeness, this thread is pretty much a branch-off from one started by Markus recently : [forums.reprap.org]

The different handling of code pointed out by markus and dc42 above make me wonder if the web-based printing is immune from this glitch, I don't use the defualt web interface because I like the comfort of repetier, but will try it out (and then try out iamburny's new interface [forums.reprap.org]) and dc42's firmware!

Ray

The only printing currently available via the web interface is print from SD. I doubt that it will behave any differently from printing from SD commanded via USB, because it almost certainly uses the same code.

I'm currently testing the print-through-USB firmware mods suggested by 3D-ES, along with some of my own. I'll make a new firmware build available if it seems to be working well.

In this post Ian says that RRP have 0.3mm nozzles for sale - maybe that would work better with thin layers?

Did you try reducing the extrusion factor in slic3r, which I suggested in the other thread?

---

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

One other thing to check: does the gcode emitted by slic3r contain any combined XZ or YZ moves? I remember reading the the firmware doesn't always implement these properly.

What extruder retraction setting are you using? I had to increase it to 4mm to get good print quality. The slic3r manual mentions that Bowden-type extruders need greater retraction.

Also bear in mind that if you have upgraded to the 0.53 firmware, you probably need to reduce the extruder temp about 12C from whatever worked well before then.

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

LOL - poor Markus trying to separate the printing from the issue! - just got back from his thread and saw this

I tried various extrusion settings (layer width control and extrusion ratio, the latter as you'd suggested) - all to no avail, I also tired print move speed changes, everything ended up as apparent overextrusion, and with lop-sided effects

Initially I was using a simple ring as a test print object, but decided that printing a single-layer shell (no fill, single perimeter, no top layer) cube would be best (since this is what slic3r recommend for calculating extrusion ratio, and because it constrains movement to x or y or z - I don't use compensation for these tests). These all ended up as lumpy ramps if sliced thinly.

received opinion (well something that nophead, I think mentioned in thin-slicing threads I looked up previously when trying to work out what the ormerod's issue was) says that nozzle diameter doesn't govern layer height (have you tried ringing reprappro's sales hotline by the way? I did when I couldn't raise them via email or emaker forum that they send you to before I discovered this forum, and it rings a long time - good luck buying a nozzle)

It's discouraging that the web interface uses the SD file - but USB does differ in Z (from our tests) from SD - ironically in a good way compared to extrusion and x/y motion - I'd love to try your improvements though and wish I could contribute in this direction.

Extruder retraction on my system is something I've not messed with too much recently - in the past I've found that going over 1mm makes for something more like sputtering rather than extrusion (over-retraction then juddering on extrusion) so I keep mine to 0.9mm or less (I DO have calibrated feed rate - by measuring suing calipers the amount of feed per pulse and I HAVE calibrated slic3r based on their instructions too) - I don't get much stringing or overfeeding when printing at 0.24 or higher, and now that I found the cure for my <0.24 slicing, it looks pretty damn good too.

As an aside, because I have quite a level bed so don't need bed compensation (and because I wondered if the weight of the head wasn't providing enough down-force to extrude thin layers) , I printed out a bearing holder today that mounts using the screw holes intended for the Z probe, and takes a 6mm id 19mm OD bearing and acts in the same way as the runner bearing on the back of the X rib - both of them seem to roll without pinching - and the head is held at a pretty constant angle -the upright of this might be a good place to mount a force sensor for the Z probe you're considering I've attached an stl if you're interestedbearingrod.stl - mine printed pretty flat (I layed it down on one side for the g-code) but seems to work ...

Cheers

Ray

Ray

@dc42
On my machine, the brass end to the Bowden tube has about 1mm slack in vertical movement where it goes into the extruder - it is not held tightly by the tongue.
I guess this will affect the extraction process.
An improved tongue might be in order.
Greg

---

Ormerod #17

Another thought. While messing about with sending GCODE commands by hand, I accidentally set baud rate to 1152000 rather than 115200 (extra zero) at which speed it worked ok and didnt seem to complain . Anyway .. Could see if changing baud rate messes up the z movement.

regards
Andy

Edited 1 time(s). Last edit at 01/11/2014 04:18AM by kwikius.

---

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

Quote
GregL
@dc42
On my machine, the brass end to the Bowden tube has about 1mm slack in vertical movement where it goes into the extruder - it is not held tightly by the tongue.
I guess this will affect the extraction process.
An improved tongue might be in order.
Greg

Yes, I think you need to sort that out to get good results. I don't have any slack at all in mine.

---

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