[Emc-users] Encoders

[Robert Pabon]

Where do you guys buy yours? Looking for affordable, quality units. Need .25" hollow shaft quadrature encoder, 2000ppr with L-D output. Anyone know a good source?
Rob

[Jon Elson]

Post by Robert Pabon
Where do you guys buy yours? Looking for affordable, quality units. Need .25" hollow shaft quadrature encoder, 2000ppr with L-D output. Anyone know a good source

Avago, US Digital and Renco come to mind. By hollow-shaft, do you mean
"kit" encoders?
Real hollow-shaft encoders with bearings are quite expensive, BEI and
Danaher come to mind.
The Kit encoders have a free-floating wheel that is supported by a shaft
on the motor or machine,
and have no bearings. They are much cheaper due to this. You can
search on Digi-Key, Mouser
and Avnet. Renco has been bought out by Heidenhain, but they are still
available.

Watch out for the CUI AMT-10x encoders at Digi-Key, they have a lag
responding to acceleration, and
may not be well-suited to CNC systems such as EMC2.

Jon

[Tom Easterday]

Post by Jon Elson
Watch out for the CUI AMT-10x encoders at Digi-Key, they have a lag
responding to acceleration, and
may not be well-suited to CNC systems such as EMC2.

Jon,
We are using these encoders on a gantry machine and are currently trying to debug a small spike (0.001) of error we see on start and stop of the motor. I wonder if this is related to the lag you refer to. How and why does this present itself in these encoders? How would be see it?
Thanks,
Tom

[Jon Elson]

Post by Tom Easterday

Post by Jon Elson
Watch out for the CUI AMT-10x encoders at Digi-Key, they have a lag
responding to acceleration, and
may not be well-suited to CNC systems such as EMC2.

Jon,
We are using these encoders on a gantry machine and are currently trying to debug a small spike (0.001) of error we see on start and stop of the motor. I wonder if this is related to the lag you refer to. How and why does this present itself in these encoders? How would be see it?

Yes, that is EXACTLY the kind of problem I saw. This encoder is highly
interpolated, so
it has a tracking counter that is incremented or decremented by an
estimate of the current
velocity. If you don't do these computations correctly, there is a lag
in responding to
changes in velocity. As far as I can tell, the interpolator in such
devices as the Analog
Devices AD2S1200 has a really fine 2nd or 3rd order filter to make this
work well.
Obviously, CUI did not go to the trouble of such mathematics.

After never being happy with these encoders and having a bit of customer
feedback,
I decided to compare to a standard HP optical encoder (with no
interpolation.)
So, I put the optical encoder on the other end of the motor, and fed
both to encoder
inputs on my PWM controller board. Most useful was to plot velocity
derived from
both encoders at the same time. This comes up often enough, I have the
plots
permanently on my web site. See
Loading Image...

The red trace is the CUI encoder, which was controlling the motor
(badly). The white
trace is the HP encoder. Both are providing 4000 counts/rev. You can
clearly see
the velocity peaks of the CUI encoder are higher, and if you look
closely at the
slopes, you can see the CUI is slow to react to velocity changes, and
then has to
overshoot significantly so the position can catch up. This of course
accounts for
the bad servo behavior. As the Halscope is set for 20 ms/div, the
velocity lag
is easily 3-5 ms in duration!

If you have a plain optical encoder handy, you could easily set up the same
arrangement to compare the encoders.

Jon

[Tom Easterday]

Thanks for the info Jon. We are seeing a small (about 0.001) position error just on initial acceleration and deceleration that we cannot account for. It may be due to the encoder. Since this is mainly a plasma machine we will probably live with it. If we need to do better we'll look at replacing the encoders. We now know the string attached to our cheap encoder :-)
-Tom

Post by Jon Elson
Yes, that is EXACTLY the kind of problem I saw. This encoder is highly
interpolated, so
it has a tracking counter that is incremented or decremented by an
estimate of the current
velocity. If you don't do these computations correctly, there is a lag
in responding to
changes in velocity. As far as I can tell, the interpolator in such
devices as the Analog
Devices AD2S1200 has a really fine 2nd or 3rd order filter to make this
work well.
Obviously, CUI did not go to the trouble of such mathematics.
After never being happy with these encoders and having a bit of customer
feedback,
I decided to compare to a standard HP optical encoder (with no
interpolation.)
So, I put the optical encoder on the other end of the motor, and fed
both to encoder
inputs on my PWM controller board. Most useful was to plot velocity
derived from
both encoders at the same time. This comes up often enough, I have the
plots
permanently on my web site. See
http://pico-systems.com/images/compare_encoder2.png
The red trace is the CUI encoder, which was controlling the motor
(badly). The white
trace is the HP encoder. Both are providing 4000 counts/rev. You can
clearly see
the velocity peaks of the CUI encoder are higher, and if you look
closely at the
slopes, you can see the CUI is slow to react to velocity changes, and
then has to
overshoot significantly so the position can catch up. This of course
accounts for
the bad servo behavior. As the Halscope is set for 20 ms/div, the
velocity lag
is easily 3-5 ms in duration!
If you have a plain optical encoder handy, you could easily set up the same
arrangement to compare the encoders.
Jon

[Peter C. Wallace]

Date: Tue, 13 Dec 2011 11:45:41 -0500
Reply-To: "Enhanced Machine Controller (EMC)"
Subject: Re: [Emc-users] Encoders
Thanks for the info Jon. We are seeing a small (about 0.001) position error
just on initial acceleration and deceleration that we cannot account for.
It may be due to the encoder. Since this is mainly a plasma machine we will
probably live with it. If we need to do better we'll look at replacing the
encoders. We now know the string attached to our cheap encoder :-) -Tom

Have you tried using FF2 to tune out the lag/lead during accel/decel?

(a jerk limited profile would also help)

Peter Wallace
Mesa Electronics

(\__/)
(='.'=) This is Bunny. Copy and paste bunny into your
(")_(") signature to help him gain world domination.

[Tom Easterday]

Post by Peter C. Wallace

Date: Tue, 13 Dec 2011 11:45:41 -0500
Reply-To: "Enhanced Machine Controller (EMC)"
Subject: Re: [Emc-users] Encoders
Thanks for the info Jon. We are seeing a small (about 0.001) position error
just on initial acceleration and deceleration that we cannot account for.
It may be due to the encoder. Since this is mainly a plasma machine we will
probably live with it. If we need to do better we'll look at replacing the
encoders. We now know the string attached to our cheap encoder :-) -Tom

Have you tried using FF2 to tune out the lag/lead during accel/decel?

Yes. Peter (working with me) spent a long time playing with FF2. We were seeing large spikes at first and had FF2 set to 0.007 which helped to lower it to .002-.003. We then realized we had the Granite Devices input filtering (which introduces a delay and is documented as doing so) turned on. Turning that off has allowed us to lower FF2 to 0.000105, not zero but getting there. The remainder of the delay is now (possibly) coming from the encoder issue Jon has pointed out.

Post by Peter C. Wallace
(a jerk limited profile would also help)

What'd you call me? :-)

What is a jerk limited profile?

-Tom

[Peter C. Wallace]

Date: Tue, 13 Dec 2011 13:06:31 -0500
Reply-To: "Enhanced Machine Controller (EMC)"
Subject: Re: [Emc-users] Encoders

Post by Peter C. Wallace

Date: Tue, 13 Dec 2011 11:45:41 -0500
Reply-To: "Enhanced Machine Controller (EMC)"
Subject: Re: [Emc-users] Encoders
Thanks for the info Jon. We are seeing a small (about 0.001) position error
just on initial acceleration and deceleration that we cannot account for.
It may be due to the encoder. Since this is mainly a plasma machine we will
probably live with it. If we need to do better we'll look at replacing the
encoders. We now know the string attached to our cheap encoder :-) -Tom

Have you tried using FF2 to tune out the lag/lead during accel/decel?

Yes. Peter (working with me) spent a long time playing with FF2. We were seeing large spikes at first and had FF2 set to 0.007 which helped to lower it to .002-.003. We then realized we had the Granite Devices input filtering (which introduces a delay and is documented as doing so) turned on. Turning that off has allowed us to lower FF2 to 0.000105, not zero but getting there. The remainder of the delay is now (possibly) coming from the encoder issue Jon has pointed out.

Post by Peter C. Wallace
(a jerk limited profile would also help)

What'd you call me? :-)
What is a jerk limited profile?

A cubic profile

Currently EMC uses a trapezoidal (linear) velocity profile (so parabolic
position profile) This means the acceleration profile is a step function. The
beginning of this step is whats hard to tune around (as you have found)

Jerk is the derivative of acceleration so is infinite with stepped
acceleration (the current situation with EMC). By using a cubic profile where
the acceleration is ramped (like velocity is now) starts and stops are much
"gentler" and contain less high frequency components that make it hard to tune

-Tom
------------------------------------------------------------------------------
Systems Optimization Self Assessment
Improve efficiency and utilization of IT resources. Drive out cost and
improve service delivery. Take 5 minutes to use this Systems Optimization
Self Assessment. http://www.accelacomm.com/jaw/sdnl/114/51450054/
_______________________________________________
Emc-users mailing list
https://lists.sourceforge.net/lists/listinfo/emc-users

Peter Wallace
Mesa Electronics

(\__/)
(='.'=) This is Bunny. Copy and paste bunny into your
(")_(") signature to help him gain world domination.

[Tom Easterday]

Post by Peter C. Wallace
A cubic profile
Currently EMC uses a trapezoidal (linear) velocity profile (so parabolic
position profile) This means the acceleration profile is a step function. The
beginning of this step is whats hard to tune around (as you have found)
Jerk is the derivative of acceleration so is infinite with stepped
acceleration (the current situation with EMC). By using a cubic profile where
the acceleration is ramped (like velocity is now) starts and stops are much
"gentler" and contain less high frequency components that make it hard to tune

Thanks Peter. And how/where does one set this as the velocity profile?
Tom

[Peter C. Wallace]

Date: Tue, 13 Dec 2011 13:44:01 -0500
Reply-To: "Enhanced Machine Controller (EMC)"
Subject: Re: [Emc-users] Encoders

Post by Peter C. Wallace
A cubic profile
Currently EMC uses a trapezoidal (linear) velocity profile (so parabolic
position profile) This means the acceleration profile is a step function. The
beginning of this step is whats hard to tune around (as you have found)
Jerk is the derivative of acceleration so is infinite with stepped
acceleration (the current situation with EMC). By using a cubic profile where
the acceleration is ramped (like velocity is now) starts and stops are much
"gentler" and contain less high frequency components that make it hard to tune

Thanks Peter. And how/where does one set this as the velocity profile?
Tom

Apply ~0.5 man year to Trajectory Planner

------------------------------------------------------------------------------
Systems Optimization Self Assessment
Improve efficiency and utilization of IT resources. Drive out cost and
improve service delivery. Take 5 minutes to use this Systems Optimization
Self Assessment. http://www.accelacomm.com/jaw/sdnl/114/51450054/
_______________________________________________
Emc-users mailing list
https://lists.sourceforge.net/lists/listinfo/emc-users

Peter Wallace
Mesa Electronics

(\__/)
(='.'=) This is Bunny. Copy and paste bunny into your
(")_(") signature to help him gain world domination.

[andy pugh]

Thanks Peter.  And how/where does one set this as the velocity profile?

It isn't currently an option with EMC2. Though I think at least some
work has been done around adding it.

[Jon Elson]

Post by Tom Easterday
Thanks for the info Jon. We are seeing a small (about 0.001) position error just on initial acceleration and deceleration that we cannot account for. It may be due to the encoder. Since this is mainly a plasma machine we will probably live with it. If we need to do better we'll look at replacing the encoders. We now know the string attached to our cheap encoder

If you can send me a picture form Halscope, I can compare it to what I
get. Are you using FF2?
This can be quite helpful in fixing errors on acceleration. You have to
use it in VERY small
amounts, though, like .005 or even less. It is easy to add too MUCH FF2
and cause jerks
in the response. Also, there is a manufacturing issue in these, where
the encoder ring may
fit loosely on the splined hub that mounts to the shaft. On some units
you need to put a
little dab of RTV, super glue or whatever on the splined hub to lock the
ring to it. You
can poke the ring with an X-acto knife to see if there is any play
between it and the hub
when the whole thing is assembled.

Jon

[Tom Easterday]

Post by Jon Elson
If you can send me a picture form Halscope, I can compare it to what I
get. Are you using FF2?
This can be quite helpful in fixing errors on acceleration. You have to
use it in VERY small
amounts, though, like .005 or even less. It is easy to add too MUCH FF2
and cause jerks
in the response.

Yes, see post in response to Peter Wallace.

Post by Jon Elson
Also, there is a manufacturing issue in these, where
the encoder ring may
fit loosely on the splined hub that mounts to the shaft. On some units
you need to put a
little dab of RTV, super glue or whatever on the splined hub to lock the
ring to it. You
can poke the ring with an X-acto knife to see if there is any play
between it and the hub
when the whole thing is assembled.

Mariss from Gecko suggested this to me early on, so we super glued the collars to the shafts. This did indeed help a little, one of them was slipping badly, the others perhaps a small amount. He also suggested adding a tiny bit of silicone caulk to one of the cogs in the gear to take up any slop in the fit (both pieces are plastic after all). I did that as well, but I don't think there was much slop to begin with so that provided no noticeable improvement.

-Tom

[Peter C. Wallace]

Date: Tue, 13 Dec 2011 13:20:28 -0500
Reply-To: "Enhanced Machine Controller (EMC)"
Subject: Re: [Emc-users] Encoders

Theres a FAQ fom AMT that mentions a jumper on the card that can be removed
to approximately 1/2 the filter time constant (at the expense of more noise)

Might be worth a try

www.amtencoder.com/Resources/Frequently-Asked-Questions

Peter Wallace
Mesa Electronics

(\__/)
(='.'=) This is Bunny. Copy and paste bunny into your
(")_(") signature to help him gain world domination.

[Jon Elson]

Post by Peter C. Wallace
Theres a FAQ fom AMT that mentions a jumper on the card that can be removed
to approximately 1/2 the filter time constant (at the expense of more noise)

And, that is real hard to do once the hub has been glued! Oops!

Jon

[Tom Easterday]

Post by Jon Elson

Post by Peter C. Wallace
Theres a FAQ fom AMT that mentions a jumper on the card that can be removed
to approximately 1/2 the filter time constant (at the expense of more noise)

And, that is real hard to do once the hub has been glued! Oops!

Even with the hub glued to the shaft, the encoder still pops out, so you can remove the jumper. We did that yesterday but if it helped it was not obvious.

-Tom

[Tom Easterday]

Post by Jon Elson
If you can send me a picture form Halscope, I can compare it to what I
get.

See:
Loading Image...

These are versions without the velocity command at 250ipm and ~1500ipm:
Loading Image...
Loading Image...

-Tom

[Jon Elson]

Post by Tom Easterday

Post by Jon Elson
If you can send me a picture form Halscope, I can compare it to what I
get.

http://bgp.nu/~tom/pub/XPosErr-VelCmd.png

Doesn't look that bad. I'm a little surprised the FF2 can't make it
better. But, then these
systems with multiple smart controllers can be quite hard to tune.

Jon

[Jon Elson]

Post by Tom Easterday
These are versions without the velocity command at 250ipm and ~1500ipm

Oh, at 1500 IPM, maybe you need to turn up the servo thread to faster
than 1 ms, or
have you tried that already?

Jon

[Tom Easterday]

Post by Jon Elson

Post by Tom Easterday
These are versions without the velocity command at 250ipm and ~1500ipm

Oh, at 1500 IPM, maybe you need to turn up the servo thread to faster
than 1 ms, or
have you tried that already?

We did try that. But, I am only able to turn it to down to about 600,000. Below that I get realtime errors on the system for some reason (that I don't understand). At 600,000 it didn't seem to help.
-Tom

[Viesturs Lācis]

Post by Jon Elson
Watch out for the CUI AMT-10x encoders at Digi-Key, they have a lag
responding to acceleration, and
may not be well-suited to CNC systems such as EMC2.

Thanks for the warning, Jon!
I happen to have bought these encoders for one of the machines...
Do I understand correctly that they are working fine, but I will need
to decrease max acceleration to get better performance of the encoder?

Viesturs

[Jon Elson]

Post by Viesturs Lācis

Post by Jon Elson
Watch out for the CUI AMT-10x encoders at Digi-Key, they have a lag
responding to acceleration, and
may not be well-suited to CNC systems such as EMC2.

Thanks for the warning, Jon!
I happen to have bought these encoders for one of the machines...
Do I understand correctly that they are working fine, but I will need
to decrease max acceleration to get better performance of the encoder?

The problem is there is a lag between acceleration and the encoder
responding to it.
If your servo loop can be tuned for good performance, you are lucky. The
more
massive the load, the better, I guess. The worst case is a low-inertia
motor sitting
on the bench. But, if you cannot get the loop response tuned properly,
then there
really is nothing you can do to fix that. The problem is that when
velocity changes,
the encoder does not correctly report position. It reports what the
position WOULD
have been if there had not been an acceleration.

Decreasing max accel will help prevent exciting any unstable response
from G-code,
but external forces acting on the system cannot be controlled that way,
and may
excite instability. In other words, reducing accel masks the problem,
instead of
solving it. Reducing gain will help, but can make the servo response less
accurate.

Jon

[Tom Easterday]

The more massive the load, the better, I guess. The worst case is a low-inertia motor sitting on the bench.

Yes, this is an important point - that we have learned the hard way. We were about to throw in the towel trying to tune our machine. We have some fairly torquey (I can't believe that is actually a word:-) ) motors given the mass of the machine. We finally got a little education on servos and ended up changing our gearing from 2:1 to 5:1 (and using an initial 10:1 gearbox attached to the motor). This made ALL the difference in the world. The machine runs smooth as silk now as there is a constant load on the motor to overcome the 10:1 gearing.

Tom