Rotary encoder to improve reliability
Stan Seibert
While waiting for my MakerBot in batch 10 to ship (go go go!), I've
been lurking on the list/forum/wiki/blogs and trying to educate myself
on various issues that seem to affect reliability. I think this might
be an important line of research for the community, both to reduce
frustration for new MakerBot users, as well as making it more
practical to do long prints and/or print multiple objects at once.
Variations in the assembly of the plastruder (either outright
mistakes, parts failure, or just differences in the thermal behavior
of the components) seem to be the number one problem. I'm not going
to talk about that in this post, though. :)
Some recent posts (on blogs and/or here, I lose track) have made me
wonder if loss of absolute positioning during a print is a problem.
As I understand it, the stepper motors run in open loop mode, and
therefore have no relative positioning feedback. You only know the
relative motion of the build platform and print head if you can assume
the shaft is free to move.
Obviously, this works pretty well in practice, but I'm curious how
often heavy MakerBot users blow a print due to one of the X-Y stage
motors jumping a step and offsetting layers. Is an offset layer a
symptom of something significant that requires user intervention, or
are they errors that could be automatically recovered from during a
long build? Would a rotary encoder on the motor help?
Thomas Charron
> Hi all,
>
> While waiting for my MakerBot in batch 10 to ship (go go go!)
I'll raise the pompoms with you. :-D Have the 25th marked on the
calender waiting for ours.
> Variations in the assembly of the plastruder (either outright
> mistakes, parts failure, or just differences in the thermal behavior
> of the components) seem to be the number one problem. I'm not going
> to talk about that in this post, though. :)
Actually, I think it's related. A proper encoder to ensure proper
feedrates would help immensely. It's ironic, but I have worked on a
system which feeds in nearly the exact same way, and we used a novel
method to actually track the plastic filiment which I'm going to try
to play with when I'm done building my Mendel.
> Some recent posts (on blogs and/or here, I lose track) have made me
> wonder if loss of absolute positioning during a print is a problem.
> As I understand it, the stepper motors run in open loop mode, and
> therefore have no relative positioning feedback. You only know the
> relative motion of the build platform and print head if you can assume
> the shaft is free to move.
Correct.
> Obviously, this works pretty well in practice, but I'm curious how
> often heavy MakerBot users blow a print due to one of the X-Y stage
> motors jumping a step and offsetting layers.
It's possible, however, when specing steppers, the rule of thumb is
2x as much torque as you'll ever need. Now, I'm not saying that the
motors on the Makerbot are speced this way, personally, I think they
should move to the new Lin motors steppers, capable of handling up to
2A in the same form factor as the existing motors.
> Is an offset layer a
> symptom of something significant that requires user intervention, or
> are they errors that could be automatically recovered from during a
> long build? Would a rotary encoder on the motor help?
If a stepper has lost steps, it means it couldn't move when it
wanted to. To correct for the problem would ignore it, and, again, if
properly speced, it means the motor was overcome which took twice as
much torque then the stepper should ever need.
What the encoders WOULD be good for is to be able to say, 'Ive had
an error, lets stop'. Many people use cheapo flag sensors, and while
moving, using the flags as an indicator that step loss has occured.
--
-- Thomas
MakerBlock
Since I got my belts properly tensioned I haven't gotten any XY motor
step jumps or offset layers. This has significantly improved my print
quality. (lots of close up photos of my prints on my site)
Congrats on buying your bot and good luck!
MakerBlock
Steven Dick
If my machine slips, its because the nozzle hit something, and I'd rather have it slip than put in a motor 2x as strong and have it break off the head.
Thomas Charron
It depends. When you're trying to print using an aggressive
pattern, I believe the current set does basically a fixed speed moves,
aka, no accel/deccel. This means then it's VERY likely that someones
going to have prints where the motor is legitimately losing steps,
which will cause the prints to gradually degrade in quality the longer
the print takes.
Personally, I'd rather have a fail safe where the hard stop sensors
cut all power to the motor entirely. :-D Have an opto endstop pull
the disable line on the stepper driver.
Of course, I haven't actually played with any Makerbot electronics
yet, I'm just using my real world experience and applying logic.
Two things are important.
1) More torque 4tw!
2) Safe Soft/Hard stops 4tw!
:-D
--
-- Thomas
Stan Seibert
> It depends. When you're trying to print using an aggressive
> pattern, I believe the current set does basically a fixed speed moves,
> aka, no accel/deccel. This means then it's VERY likely that someones
> going to have prints where the motor is legitimately losing steps,
> which will cause the prints to gradually degrade in quality the longer
> the print takes.
Can you elaborate on this? Can too much acceleration cause missed
steps, even in normal circumstances? Is the acceleration decided by
the microcontroller or is it adjustable at the GCode level?
Lawrence Harris
torque requirement will exceed the steppers ability to move the
mechanism. If you have position feedback you can compensate for this
and do a sort of lazy quick move. Without the feedback you have to
characterize the mechanism and ramp up and down at speeds you know to
be ok and hope there are no glitches or move at a safe constant
speed. We used to do this with floppy disk drives where the
manufacturers spec was something like 6ms per step but you could do
2ms as long as you double checked when you arrived that you were where
you thought you were and if not re-positioned again. Worked like a
charm and easily doubled the speed of access on short moves and close
to triple on the longer ones.
Rotary encoders would be a big improvement from a throughput issue but
I don't think the current software is there to use them. The idea
would be to take the distance requested by the G-Code, calculate a
acceleration profile (ramp up, constant speed, ramp down) verify the
position and adjust then start extruding again.
Lawrence
> --
> You received this message because you are subscribed to the Google
> Groups "MakerBot Operators" group.
> To post to this group, send email to make...@googlegroups.com.
> To unsubscribe from this group, send email to makerbot+u...@googlegroups.com
> .
> For more options, visit this group at http://groups.google.com/group/makerbot?hl=en
> .
>
Thomas Charron
> Can you elaborate on this? Can too much acceleration cause missed
> steps, even in normal circumstances? Is the acceleration decided by
> the microcontroller or is it adjustable at the GCode level?
<Big disclaimer, everyone feel free to clarify, I'm trying to do
something I really haven't done before. Try to explain WHY a stepper
motor works without going into the nitty gritty>
Yes. Look at it this way, it's the same as the acceleration in your
car. It takes more torque from the engine to accelerate to a speed,
then to maintain the speed. I believe that the current firmware (the
one that get's installed with the RepRap, specifically, Five5_GCode)
doesn't use accelerations at all. It simply starts stepping at the
given speed. This is certainly possible, it just hits torque.
Here's a simply explanation (kinda). A stepper motor is 'coerced'
into motion by magnetic fields pushing and pulling. The torque a
motor has is basically how much magnetic force can be exerted to be
where it needs to be. A typical stepper motor has 200 poles. This
means that you alternate the magnetic field 200 times, the motor will
make a full turn. But the motor isn't in 200 different configuration.
It's really only in 2. It just alternates 100 times. This is why
steppers are actually noisy. They are technically speaking, skipping
their way along. When you want constant movement, you simply have it
skip at a given speed. However, the stepper itself is really
constantly rolling down a hill. To make it keep moving, we're making
it want to roll in a given direction.
Now here's where it gets back to your car. When you accelerate your
car, you feel your body get pushed back. Your body, and the car
itself, doesn't WANT to move naturally. Acceleration allows you to
get up to speed while adding more energy over time. The Makerbot
firmware I've seen thus far appears to be not accelerating or
decelerating, but stepping at a fixed rate. This means the car is
instantly going 40 miles an hour. :-D Step loss is kinda like the
car peeling it's tires. :-D The tires don't KNOW they only went 10
feet instead of 20. Far as they know, they turned the number of times
to go 20.
--
-- Thomas
Rick Pollack
Thomas Charron
> There was a previous discussion along these lines. My bot, when tested a
> while ago, did not begin to skip until the feedrate and travel feedrate were
> set to 70, I normally print in the 40-45 range. What speeds do you guys
> normally use?
What about at lower rates, but with a 180 degree change in
direction? How where you measuring that it wouldn't miss a step?
Just curious.
--
-- Thomas
Rick Pollack
-- Thomas
Eric Smith
> It's possible, however, when specing steppers, the rule of thumb is
> 2x as much torque as you'll ever need. Now, I'm not saying that the
> motors on the Makerbot are speced this way, personally, I think they
> should move to the new Lin motors steppers, capable of handling up to
> 2A in the same form factor as the existing motors.
Who is the manufacturer and what is the part number of the Makerbot
stepper motors? I've never before seen stepper motors without a
proper label giving this information.
Rick Pollack
Steven Dick
It depends. When you're trying to print using an aggressive> If my machine slips, its because the nozzle hit something, and I'd rather
> have it slip than put in a motor 2x as strong and have it break off the
> head.
pattern, I believe the current set does basically a fixed speed moves,
aka, no accel/deccel. This means then it's VERY likely that someones
going to have prints where the motor is legitimately losing steps,
Of course, I haven't actually played with any Makerbot electronics
yet, I'm just using my real world experience and applying logic.
I think you're wrong here. You are assuming that the makerbot components are under rated. They are not.
If the voltage is set correctly, the makerbot stepper seems to be able to apply enough force to completely reverse direction without losing any steps at the top speed the software uses. If your system is loosing steps at top speed, you need to either raise the voltage or tell the software to lower the speed.
I was worried that when I added my (heavy) heated build platform, it would cause problems for the steppers loosing steps. It has not. I have not needed to even change the voltage for the heated platform or lower the speed.
Don't get me wrong -- I like optical encoders, and I've used them in the past. But adding them to the cupcake would add unnecessary redundant expense at very little gain. Optical encoders can't solve belt slip. At best, they might be able to detect a head crash, but they won't make the system more accurate.
For those people retrofitting CNC machines and the like, they probably already have optical encoders. Also, they probably have heavier systems that need acceleration curves in the motion control to get top speed without slipping. Also, for a bigger system (like a mendel) before I added optical encoders to stepper motors, I'd put in the acceleration curve, so you could get top speed when going from end to end, without worrying about skipping steps. If you're going to put in optical encoders, why are you bothering with heavy expensive power hungry stepper motors, when you could just use a DC motor and the optical encoder?
Having said that, I would like to see an optical encoder on the pinch wheel. The DC motor there I think may have some minor speed variation from build to build and maybe even from plastic to plastic. Also, it could prevent the plastic from stripping, as it stops moving before it strips.
Thomas Charron
> On Tue, Feb 2, 2010 at 6:01 PM, Thomas Charron <twa...@gmail.com> wrote:
> I think you're wrong here. You are assuming that the makerbot components
> are under rated. They are not.
Well, it really depends. I'm not sure HOW they where speced, based
on the torque required for given speeds and loads. I can say that I
personally really hate Kysan motors in general. I've found
historically that the characteristics of each motor are different from
batch to batch. Basically, I've found that they're cheap. But I want
to clarify that this is based on person experience, so take it with a
grain of salt. Maybe I just had some bad batches.
> If the voltage is set correctly, the makerbot stepper seems to be able to
> apply enough force to completely reverse direction without losing any steps
> at the top speed the software uses. If your system is loosing steps at top
> speed, you need to either raise the voltage or tell the software to lower
> the speed.
It's a little more complicated then that. As an example, if you
happen to hit a resonance across two axis, the motor can stall at low
speeds. Those sorts of stalls WOULD be sporadic. This is why you
want to OVER spec the motors, to ensure that even in those situations,
there will be plenty of torque available to overcome the resonate
vibrations which can hit the coils.
> Don't get me wrong -- I like optical encoders, and I've used them in the
> past. But adding them to the cupcake would add unnecessary redundant
> expense at very little gain. Optical encoders can't solve belt slip. At
> best, they might be able to detect a head crash, but they won't make the
> system more accurate.
I don't think adding encoders is really required. I just feel that
to provide better reliability, it would be a good idea to splurge the
couple of dollars more on at least the two axis, and put a motor in
there that has better performance.
> For those people retrofitting CNC machines and the like, they probably
> already have optical encoders. Also, they probably have heavier systems
> that need acceleration curves in the motion control to get top speed without
> slipping. Also, for a bigger system (like a mendel) before I added
> optical encoders to stepper motors, I'd put in the acceleration curve, so
> you could get top speed when going from end to end, without worrying about
> skipping steps. If you're going to put in optical encoders, why are you
> bothering with heavy expensive power hungry stepper motors, when you could
> just use a DC motor and the optical encoder?
Yup. Again, I don't think encoders would help anything, unless we
wanted to close the loop, which at that point, might as well be using
servos. :-D But an additional thing to note is that the larger CNC's
and the such are using higher performance stepper motors, running at
24-48 volts. The current motors max out at 14 volts.
> Having said that, I would like to see an optical encoder on the pinch
> wheel. The DC motor there I think may have some minor speed variation from
> build to build and maybe even from plastic to plastic. Also, it could
> prevent the plastic from stripping, as it stops moving before it strips.
I would like to see a rotary encoder on the non motor side of the
pinch wheel, with some gripping capability on that side. This may be
a better unit of measure to say how the filament itself is feeding.
--
-- Thomas
Steven Dick
> Having said that, I would like to see an optical encoder on the pinchI would like to see a rotary encoder on the non motor side of the
> wheel. The DC motor there I think may have some minor speed variation from
> build to build and maybe even from plastic to plastic. Also, it could
> prevent the plastic from stripping, as it stops moving before it strips.
pinch wheel, with some gripping capability on that side. This may be
a better unit of measure to say how the filament itself is feeding.
We are thinking along the same lines.
I don't know if you need to make the pinch wheel more grippy...but I suppose if you are putting in a high accuracy optical encoder, you don't want it slipping. (As is, we don't care.)