Extruder Rate (request for crackpot ideas)

Quote

This wasn't intended to sound mean or confrontational, by the way.

No offence taken. The call was for "crackpot" ideas .

Quote

It would only work with large parts, or multiple small identical parts, so it lacks a certain flexibility.

I think you could do the medium sized parts. Instead of extruding an entire layer in one go, you would use it more like a inkjet printer (rather than the plotter style now used).

It would scan back and forth over the current layer and turn on or off the extruder at the point where the plastic is needed.

There are several problems I can immediately think of (but probably could be overcome).

The first is that you would have lots of "spider webbing" unless you were able to rapidly halt the plastic from the extruder.

The second is that the output might be a bit "blobby", again, this would be a symptom of starting and stopping the extruder.

The third is that there might be more cooling between layers and this might effect the lamination of the product.

Quote

but you have to make a tougher and more rigid frame to bear the extra weight and the motors to push it around, and then deliver that much more power to the final device to keep those big motors going and all those extruders hot...

Yeah, that's the real killer I suppose. It wouldn't work on the current RepRap design, but might be for a type of spin off design. I'll let evolution handle that one .

Larry_Pfeffer Wrote:
-------------------------------------------------------

> Similarly, it would probably be helpful to be able
> to measure the pressure of the melted plastic
> (that is about to transit the orifice.) Sensing
> that would probably facilitate controlling the
> flow rate.
> However, I don't know how to measure the pressure
> of hot, viscose melted plastic? (Especially
> without significantly complicating the extruder.
> I'd be interested in any ideas on good way to
> measure this.

As we are working with wild ideas here:
The 3d probe mentioned by Viktor here( [forums.reprap.org] ) might be usable for this, if the probe is placed on a small arm so its tip can be inserted in the fluid stream at intervals (preferably when it

What if a small wheel hooked to a simple rotary encoder was pressed against the backside of the filament where it sets against the threaded rod in the extruder? It would be a simple way of seeing how fast your filament is being pushed into the mechanism - it should be possible to extrapolate your extrusion rate based on that. It might not even be too hard for someone with a reprap or other RP machine capable of making the extruder body to prototype and just eyeball check w/o an encoder to see if it makes sense.

Quote

It would be a simple way of seeing how fast your filament is being pushed into the mechanism

But wouldn't the motor encoder already do this? It wouldn't work in circumstances where the filament was not being moved by the drive screw, if the extruder housing wasn't forcing the filament onto the screw hard enough, for example.

Aside from that case, you know that one tick of the encoder represents a rotation of some known amount of the drivescrew, which translates to the downward motion of some amount of filament that you could work out with a bit of maths.

It seems somewhat simpler to nail the encoder to the motor, which is what's being done... there's a higher chance of the filament slipping past a wheel intended to read its motion than there is of the filament slipping past the drive screw, no?

Ru Wrote:
there's a
> higher chance of the filament slipping past a
> wheel intended to read its motion than there is of
> the filament slipping past the drive screw, no?

I don't think it'd work out that way.
If an idler wheel had only an encoder on it, it would present very little load (force) on the filament. Assuming the (perpendicular) contact force on the idler was sufficient to avoid slip, such a wheel should measure filament motion quite well. Assuming a good encoder (low friction), an idler really shouldn't slip much.

On the other hand, the drivescrew is operating at much higher force levels, and can slip when the spring setting isn't just right -- or the filament is uneven in shape/diameter where the screw (tries to) bite into the filament. An encoder tied to the screw won't "see" the difference between the slipping and good engagement.

-- Larry

The drive screw cuts a thread in the filament and propels it. If it slips then it strips the thread in the plastic and generally does not recover from this without manual intervention.

Having the encoder on a wheel against the filament would allow you to detect this situation, but probably not be able to recover from it. So the drive has to be 100% reliable, therefor there is no advantage to moving the encoder to another wheel, but there is another possible source of error (wheel slipping).

---

[www.hydraraptor.blogspot.com]

... use a gear with needle-like tips or insert needles in a milled encoder-wheel with small radial v-grooves for inserting steel-needles - then the encoder wouldn't slip ...

Viktor

Another problem with this idea is that the filament moves very slowly, so unless you have a very high resolution encoder you only get feedback relatively infrequently. That makes it harder to get a stable feedback loop as there is a big lag between changing the motor PWM and seeing its effect.

---

[www.hydraraptor.blogspot.com]

nophead Wrote:
-------------------------------------------------------
> Another problem with this idea is that the
> filament moves very slowly, so unless you have a
> very high resolution encoder you only get feedback
> relatively infrequently. That makes it harder to
> get a stable feedback loop as there is a big lag
> between changing the motor PWM and seeing its
> effect.

It could work with a lower resolution encoder with a really small wheel (or perhaps one of those low-resolution encoders with a high mechanical advantage gear train that I described elsewhere).

Anyway, though, I do think the extra wheel with an encoder is a bit redundant, as it doesn't seem that you could get a "partial" slippage and still extrude (the thread gets stripped, as Nop said).

It could be interesting to put an encoder on the filament supply spindle and compare that with the drive screw rotation. Might show some interesting variations. Interesting, but not necessarily useful .
It's always cool to have a bunch of extra inputs that give you tons of information (until you realize you have no input pins left for the inputs you really need...).

Quote

Another problem with this idea is that the filament moves very slowly, so unless you have a very high resolution encoder you only get feedback relatively infrequently

I'm curious; how much resolution do you actually need? The magnetic encoder board seems fairly high-res at 1024 steps, if I remember correctly. This is the direct motor output which is then geared down by quite a bit, and used to turn the screw which is going to feed in, say, a mm of feedstock per revolution. So you're getting thousands of ticks from the encoder for a few mm of extruded filament.

Sure, the more the merrier, but presumably there's some level of acceptable accuracy, beyond which you just won't notice any more detail because the mechanisms of he extruder simply aren't precise enough.

This kinda ties in with another thread regarding cheap extruders, I guess. Can you get away with an encoder which has only 10s of counts per revolution instead of hundreds?

Quote

It could work with a lower resolution encoder with a really small wheel (or perhaps one of those low-resolution encoders with a high mechanical advantage gear train that I described elsewhere).

But that in turn increases the chance of slippage, I imagine

I use an 816 step encoder. I don't need anything like that accuracy but getting updates so rapidly allows me to use a very simple control loop. Just the P part of PID. I haven't tried it yet, but I expect with less steps, i.e. an RP encoder, I will need the I and D terms because the more lag there is in the control loop the more likely it is to oscillate.

---

[www.hydraraptor.blogspot.com]

It seems like having something that can see if you have serious slippage might be useful anyway, even if not the way I'd thought XD... being able to pause and set off an alert when the extruder isn't pushing out plastic could help rescue print jobs that run into the problem, couldn't it? Nophead, when you lose the thread on the filament, what do you have to do to recover extrusion - could you resume the print if you caught it quickly? If not coming up with a design that allows that might be something we should think about.


Also, sense we're on crackpot ideas, my other one was that you could mark the filament in alternating light and dark bands and watch those going by... It'd be interesting trying to convince a supplier to sell ABS coils that alternate between white and black.

Quote

Nophead, when you lose the thread on the filament, what do you have to do to recover extrusion - could you resume the print if you caught it quickly?

Sometimes it can be restarted by gripping the filament above the extruder with a pair of pliers and pushing it for a while until the stripped bit has passed through. Other times I have to strip down the extruder. It would always spoil the print as I don't cater for restarts in my software and I think the RepRap host can only pause between layers. However, once the spring tension is set correctly, it never happens so I don't find that it is a problem that needs a solution.

It may be possibly to detect feed failure by monitoring the motor current as it should go down once the thread has been stripped but it is probably too late to recover by then. An encoder would detect slippage earlier and the software could be modified to pause and restart. That would allow prints to be saved for any kind of feed failure : stock exhausted, motor worn out, etc. IMHO, a lot of extra complication for things that don't happen very often and shouldn't happen at all with a well designed extruder. Could be worth doing if people want to print large objects that take 100's of hours each.

---

[www.hydraraptor.blogspot.com]

Corwin Wrote:


> my other one
> was that you could mark the filament in
> alternating light and dark bands and watch those
> going by... It'd be interesting trying to convince
> a supplier to sell ABS coils that alternate
> between white and black.

Yup, for the short-term, at least, that's unlikely. But the pattern only has to be on the surface, so printing might do. As reprap consumption of plastic grows, it might cost only a small incremental amount to have such lines printed onto the surface of the filament. (And if the "ink" was an IR-only pigment, it might not even impact the color.) Electrical wire's insulation is often printed upon, a longer repeating pattern. Sometimes the *eggs* I get at the market have some psrt of code printed onto them -- and that's a surface with compound, variable curvature. I'd love to see how they do that!

-- Larry

Quote

Sometimes the *eggs* I get at the market have some psrt of code printed onto them

Pretty much all the ones here do... I'm not sure whether that particular piece of bureaucratic idiocy is the fault of the UK government or the EU. A quick look at a handy egg shows the print has significant distortion (so no cunning flxible print heads or contour following), and looks dot-matrixed. I imagine it is shot on from a very close distance, like a low resolution inkjet.

Printing markings onto filament would seem to be a pretty tedious and time consuming process, and you'd require some machine designed for the purpose to do the job. Much like having alternating filament colours, it would add so much additional time and/or expense that I don't see it ever being worthwhile.

Hi! I've been following RR for over a year, but this is one of my first post. I understand that this thread is for brainstorming, so sorry if I sound a little too science fiction, or ignorant.
I think that an set of RepRap working together is a good idea, but the cartesian robot feels like a limited arrengement for this purpose. I know that a robot arm has been discussed (but I can't remember why finally a cartesian robot was choosen). I can visualize a robot arm RepRap printing an object. Half printing, this friend of mine come to my home with his robot arm RepRap (which, maybe, is different from mine), so we put his robot next to mine. Automagically, the robots recognizes each other existence (position, size, speed, every single property), and start working as a team, like those cars factory. Of course, this would require a very advanced control, and probably some strict protocols, but I think it has some interesting properties. First, you could add a lot of robot arms, working together... as many as the work area allow it. Second, each arm is an independent RepRap itself, probably a different model too. You don't need an special arrengement. So the design effort could be invest in the controls or protocols, instead of mechanical design, which I find maybe more appropriated (easier, cheaper) for an open source project.

joining in the crackpot spirit of the thread; with accurate temperature measurement it should be possible to detect loss of feed.

The energy going in to heating the head is known, as it is controlled by the PWM of the heater. The energy out is made up of convection, conduction and radiation losses and in melting the plastic. For a given temperature the conduction and radiation losses should be fairly constant. I imagine the convection loss won't vary much either, but its possible that the head moving around or a breeze could effect it. If it does have an effect it will most likely result in more heating being needed. This leaves the volume of plastic passing through as the main variable effecting the extruders temperature, and the only one likely to reduce the heating needed. If the temp rises with only low heating levels then it's likely no plastic is being melted.

Quote

joining in the crackpot spirit of the thread; with accurate temperature measurement it should be possible to detect loss of feed.

That's true, although there'd be a small lag between the feed halting and the power drain of the heater decreasing, and so the print might still be screwed once the jam has been sorted out.

Perhaps you could work out some cunning logic to backtrack a bit to resume the print where it left off, but this would be hard to make reliable. I guess this would be nice as an emergency stop mechanism, perhaps.