donmilne

This doesn't make sense to me. If the motor current doesn't change with load, why does it need to be limited? Also, my understanding of the "feeder motor skipping" problem is that when the draw exceeds the 1250mA current limit then the motor is reversed a bit to avoid grinding the filament (or destroying the motor?). An explanation which again IMHO makes no sense if current is constant. Likewise the partial remedy of using a higher hotend temp... does what exactly? - if not reduce the load and hence the load dependant current draw?

Sets the current? Again, that seems unlikely. I assume you would send the driver chip a series of TTL pulses, and the motor will take whatever current it needs, unless limited by the supply. Hmm. Maybe I should build myself a breadboard stepper controller to give my guesses a better chance of being right.

>Doesn't the stepper use as much [current] as is allowed? I'm open to being corrected by David, but I do have recent experience controlling a normal (not stepper) motor with an Arduino, and in that case the motor only draws peak current when it's overworked, i.e. load stuck. I'm not sure how stepper motors are driven - is it through an h-bridge chip? In which case measuring input current ought to be possible.

Given that the firmware has to monitor it continually, and since it's apparantly crucial to performance, is there any chance of getting a live view of feeder motor current draw say in the Tune menu? I'm asking for a way to view it, not necessarily an ability to change the limit. Basically, I want to be able the see how close I am to skipping, also the precise effect of higher operating temp, bearing mod on spool holder, PTFE bowden tube etc. Also if the number tends to grow over time then presumably I have a growing hot end blockage... etc etc. I'm kind of surprised it isn't there already, but I couldn't find it.

Good point. Thanks. Robert needs to do a version of his feeder with his dust wiper widget built into the top side.

Ok, if I have the calculations right then one mm of filament is about 6.3794mm3. Divide by 282 gives about 0.0226mm3 per step of the feeder motor. If the layer thickness is 0.1 and the nozzle diam is 0.4 then one step of the feeder motor provides enough filament to lay down a 0.56555mm line. You might see rounding errors if the line is any small multiple of that length. I guess there isn't much further to take this. I just found it odd that the UM2 could print out a large object with no extrusion problems at all, and then right after that fail on the small fiddly bits of this tiny thing I asked it to make.

Hmm. Spare parts... Good idea! I guess it's no good waiting until the feeder breaks before trying to print replacements. :smile: (Seriously: I still have the original feeder as a fallback, but all we know how awkward that is to fit). I might try making the spare copy out of XT though.

What are people making Robert's feeder out of? I've used standard Ultimaker PLA (white), but I'm concerned by reports I've read around here that PLA will sag when kept under constant load.

Well, that explains why I thought I remembered you claiming the design on these forums, but the only thing similar I could find was by some guy called Sneakypoo! Thanks for the design, and btw one reason I tried it was because I'd never printed an articulated object before. Very interesting! Anyway, regarding what you're saying about each feeder step being a ridiculously small volume. I agree that intuitively that seems correct. However there are details I don't have. For example, at what point is the volume requirement calculated and transferred to the motor function? I can imagine that for each "pen move" I can easily calculate a volume of filament required, but some of those will be ridiculously small volumes too. So I guess they must be aggregated somewhere. ISTM that if any short move is rounded down to 0 filament, and the same move cycle is repeated long enough, you will run short of material, and eventually won't have enough. Also, does Cura do these calculations to the same resolution as the feeder motor?

I gave you a link to the object on thingiverse, you can judge the complexity from that I suppose. Thanks for offering to look, but note that I didn't ask for help with the object itself, my question is about the inner workings of the firmware. I think I've done enough prints now to recognize underextrusion when it happens, I'm trying to get at why... especially since the same printer with the same filament had just got a perfect result with the cylinder extrusion test available elsewhere on this site. @Daid: the 1500mA setting is recommended in the feeder replacement discussion. It's done using a manually placed gcode. The proposition being that the present limit is too conservative and causes skipping and hence underextrusion. I assume the current limit was not relevant here since it's at the opposite end of the extrusion rate spectrum. I note your implied statement that 282 steps/mm is fine enough - I'll do some volume calcs on that tomorrow, however I notice that the question is still open: if <1 step was needed, would this be rounded down to 0?

Can someone with a knowledge of the UM2 firmware comment on this? Does the feeder advance filament in discrete steps, and if so, how does it cope with fractional steps? Particularly, a long sequence of fractional steps. Or is the question misplaced? Should I view the printer as a simple robot and refer the question to whatever generated the gcode, i.e. Cura?

I'm not entirely sure I'm in the right place. Marlin is the standard firmware used in the UM2, right? Anyway, I was printing out sneakypoo's filament dust filter thing from thingiverse - http://www.thingiverse.com/thing:190118 ... because I'd seen mention of it hereabouts. The print went well with my most reliable PLA right until the last couple of minutes: the print ends with a thin (~1.2mm?) wall that extends up several mm. I didn't get to the top of the wall before I started seeing signs of underextrusion. Now this was unexpected, because this thing is the size of a postage stamp - filament demand can't be excessive. Also I had set the feeder current limit to 1500mA, and the min layer time to 5 secs (from memory - long time since I set this). I looked round the back, where I have Robert's feeder, previously working well... and no gouge in the filament. However the feeder motor didn't seem to be moving much, if at all. It crossed my mind to wonder... does the gcode advance the feeder motor in n discrete steps based on a calculated filament volume? If so, what does it do if it requires <1 step? Does it round down to zero (underextrusion), round up to 1 (stringing?), or accumulate the residual until it reaches >= 1? (latter sounds good to me).

Well, I'd say it's because you have the spring tension too loose or too tight. I found it useful to make a small "coin" test print, say 25mm diameter and 2mm thick, .1mm layers, 55mm/s, 100% fill: it takes only a few minutes to print and each layer fill is a decent test of regular extrusion. I also used a loose length of filament say about a meter beyond the feeder, to eliminate spool binding as an influence. I backed off the spring screw to the min force then started off the print, tweaking it clockwise a quarter turn at a time until I got consistent fill. Once I was happy with the coin I returned to the above extrusion test and got perfect results all the way to the top. Oh, and it helps to take the time to get the bed levelling spot on. Otherwise that too could be an influence.

Damn! That was the thread I thought I was already posting into. How did I miss that. Somehow the fact that both are 36 pages or so fooled me into thinking it was the same discussion. I've moved the most relevant messages to the other discussion, and deleted them from here where it wouldn't disrupt the flow too much. Mods feel free to edit further. As to posting a picture of my feeder - it's the same as other pictures you've seen. My boxroom has poor lighting, so I expect I can't improve on the previous pictures, nor do I think a picture would have clarified the issue with the yoke anyway, since the important hole is hidden when the feeder is in situ.

Job done. However, while replacing the yoke I noticed that the feeder motor shaft has no flat on it. That seems like a mistake. It seems to me to invite problems whereby the knurled sleeve slips on the shaft, leading to inconsistent feed rates.

As help for anyone browsing this thread, I'd just like to point out a feature of IRobertL's design that may not be obvious to someone who hasn't tried it (it wasn't obvious to me at any rate). There has been some talk about reserving a motor mounting bolt, so it never has to be removed, thereby eliminating the problem of requiring 3+ hands to change the feeder. Someone did do a variant with 3 mounting points for that reason. Now while IRobertL's design does technically require all four mounts, in fact once the main body is in place I can't see why you'd ever need to remove it again. All the "problem" parts (yoke, arm, latch) can each be replaced by removing a single bolt. Or two bolts, if you wanted to to remove all of them at once.

Yes, I had noticed that the holes on either side had different sizes, but hadn't really understood the purpose. I had the same problem regarding M3 screw lengths btw. Actually, my printer is doing quite well at the moment, so perhaps now is the time to print a new yoke. Making sure the small hole is the perfect size. Mind you, I already stabbed myself getting the spring on once, I'm not looking forward to doing it again! :sad:

Copied from another thread: Ok, I've just gone back over the notes for IRobertL's feeder. I still don't see a discussion of how that idler bearing hub pin is supposed to be held in place. Surely it isn't just supposed to screw into the plastic of the yoke - or float loose? Help!

Yes, I had noticed that the holes on either side had different sizes, but hadn't really understood the purpose. I had the same problem regarding M3 screw lengths btw. Actually, my printer is doing quite well at the moment, so perhaps now is the time to print a new yoke. Making sure the small hole is the perfect size. Mind you, I already stabbed myself getting the spring on once, I'm not looking forward to doing it again! :-(

Ok, I've just gone back over the feeder notes. I still don't see a discussion of how that idler bear hub pin is supposed to be held in place. Surely it isn't just supposed to screw into the plastic of the yoke - or float loose? Help!

Well good heavens. Apparantly, having a wobbly idler bearing is counterproductive! I don't have a cure, I just reset the pin, and backed off the pressure a bit. I also edited the extrusion test gcode and set the feeder current limit to 1500mA. Below is a picture of the result. You can't see the fine detail, but I can tell you that even holding it up to the light, there is absolutely no underextrusion - it's uniform from bottom to top.

I'm beginning to think that perhaps I didn't construct IRobertL's feeder correctly. In particular, the idler bearing rotates around a pin (axle). The description doesn't mention this pin so I've assumed it's an M3 bolt again, except there is no nut on the other side of the yoke, and no room for one either. What am I missing?

Does Marlin have a reason to write to the SDcard? I guess it must, otherwise the card wouldn't be corrupted. I do believe that UM2's support for SDHC (i.e. anything >2GB) is flakey or non-existant. I had the printer regularly locking up while attempting to read an 8GB SDHC card, when I reverted to a 2GB SD card it was reliable again. I use that same 8GB card a lot, so I know there is nothing wrong with it. Speaking as am embedded developer myself, including support for SD and SDHC, I'm suspecting that the size of the FAT table may be a problem with the larger cards, depending on how it's processed.

I did check the head temperature after Nicolinux mentioned it, but I saw nothing wrong at that moment in the unrelated print I was doing. Temp sensor was showing within +/-1 of the setpoint (210C). When I have time I'll repeat the test and see if there's anything odd going on in the early layers - though nothing seems to happen until around z=5mm. I would have thought that was well past the fan turn-on event etc.

I'm using the gcode you posted (I'm not sure if anything else was ever available), so presumably my fan kicks in at the same time as yours? @nicolinux: I do occasionally hear a loud clunk which I associate with the reel binding and then jumping. Not too often though, and I haven't yet seen what it could possibly be binding on. The winding of the filament on the spool looks nice and uniform, no catches there. Still, I'll mark this mentally as a possibility. Strange that it's been so repeatable though.