CUI encoders

[Jon Elson]

I have had a couple reports of strange things happening with the CUI AMT
encoders,
that are so nicely affordable from Digi-Key. Well, I was fiddling with
a Keling brushless
motor fitted with one of those encoders, and couldn't seem to get it to
run smoothly, and
started thinking about those reports and the fact that the CUI encoder
is by definition an
interpolating device. So, I decided to fit a HEDS optical encoder to
the same motor AT
THE SAME TIME and compare the results. I was hoping for a smoking gun,
but did
not find anything completely outstanding. However, the two encoders
definitely show
significant differences, and I believe that is the cause of the tuning
difficulty.

So, I have 4 HalScope shots if anyone is interested in looking at them.
In Loading Image...
the velocity derived from timestamp estimation is compared.
ppmc.0.encoder.00.velocity (red) is the CUI encoder, and
ppmc.0.encoder.01.velocity
(white) is the HEDS. There are a number of jagged features in the CUI
trace that are
absent in the HEDS one. Also, one momentary deviation seen by the HEDS
encoder is
totally missed by the CUI! The jagged artifacts may be due to time
jitter when movement
is reported by the CUI.

in Loading Image...
I show the servo cycle-by-cycle velocity in raw encoder count units, not
helped at all
by velocity estimation. The CUI encoder seems to suppress some of the
typical dithering
seen in optical encoders at near zero speed. But, it also seems to
flatten out places where
velocity is not changing rapidly.

In both of these plots, EMC was controlling motion using the CUI encoder.

In Loading Image...
I show a well-tuned servo response with the HEDS encoder providing
position feedback.
Note following error is easily held within an equivalent 200 u-In band.

In Loading Image...
I show the same setup with the CUI encoder providing feedback, and the
best tuning
I could accomplish. Peak error is at least 3 times worse, and the
velocity trace also
shows lots of velocity fluctuation.

Does anyone see a smoking gun that I missed? I THINK I can see a phase
lag in the CUI
encoder in the encoder2 (raw delta) plot. There are some places where
this delay could
be up to a couple millisecond, that would be enough to really foul up
the servo loop.
On the encoders plot (velocity estimate) it seems to be kind of
one-sided, delay when
velocity is rising, early when velocity is falling. That seems even
more perverse.

I will bring this stuff to the Workshop if anyone wants to see it and
play with it live.

Thanks,

Jon

[Jon Elson]

OK, I think I get it, and it is about what I expected from an encoder
with interpolation.
It isn't exactly a velocity lag, it is an ACELLERATION lag! I did
another plot at
expanded time resolution, Loading Image...
and it looks like there is a real lag in responding to changes in velocity.

Does anybody agree that is what I'm seeing here?

Thanks,

Jon

[Jan de Kruyf]

Jon,
I see exactly this in yr pictures: (from the faq on their website)
9. How does angular acceleration affect pulses and error? Angular
acceleration does not cause missing pulses. But it does cause some lag in
position, proportional to acceleration and T^2. (with T= 100, 50, 25, 13 µs
at resolution settings D2, D1 = 11, 10, 01, 00, respectively). The internal
position follower will have no problem with acceleration as long as the
resulting position error stays within 256 increments (4 increments per
quadrature period) for resolution 2048 PPR, with the limit being
proportional in other resolutions. The position follower will catch up at
the end of acceleration. Decreasing the basic resolution will reduce
acceleration error, if that is of concern for fast loops or removing the SF
jumper as described in section 3 above.
-------------------------------

so I would give that rubbish a miss. It is good for a position readout, but
definitely not for a high speed feedback loop.

j.

Post by Jon Elson
OK, I think I get it, and it is about what I expected from an encoder
with interpolation.
It isn't exactly a velocity lag, it is an ACELLERATION lag! I did
another plot at
expanded time resolution, http://pico-systems.com/images/vel.png
and it looks like there is a real lag in responding to changes in velocity.
Does anybody agree that is what I'm seeing here?
Thanks,
Jon
------------------------------------------------------------------------------
EditLive Enterprise is the world's most technically advanced content
authoring tool. Experience the power of Track Changes, Inline Image
Editing and ensure content is compliant with Accessibility Checking.
http://p.sf.net/sfu/ephox-dev2dev
_______________________________________________
Emc-developers mailing list
https://lists.sourceforge.net/lists/listinfo/emc-developers

[Jon Elson]

Post by Jan de Kruyf
Jon,
I see exactly this in yr pictures: (from the faq on their website)
9. How does angular acceleration affect pulses and error?
Angular acceleration does not cause missing pulses. But it does cause
some lag in position, proportional to acceleration and T^2. (with T=
100, 50, 25, 13 µs at resolution settings D2, D1 = 11, 10, 01, 00,
respectively). The internal position follower will have no problem
with acceleration as long as the resulting position error stays within
256 increments (4 increments per quadrature period) for resolution
2048 PPR, with the limit being proportional in other resolutions. The
position follower will catch up at the end of acceleration.
Decreasing the basic resolution will reduce acceleration error, if
that is of concern for fast loops or removing the SF jumper as
described in section 3 above.
-------------------------------

Yes, I read this and it didn't sound too bad. But, I think the lag is a
LOT more than 100us, up to several
milliseconds, or maybe 30 times worse than what they state.

Post by Jan de Kruyf
so I would give that rubbish a miss. It is good for a position
readout, but definitely not for a high speed feedback loop.

I may experiment some more at different resolutions, and see about that
jumper setting.

Thanks,

Jon

[Jan de Kruyf]

Jon,
the problem is that the delay between reality and the Z domain of the
encoder is variable, so good tuning will be
something somewhere in fairyland unless you lower the bandwidth of your
drive right down so that the delay jitter
becomes insignificant in respect to the bandwidth of your system.

j.

Post by Jon Elson

Post by Jan de Kruyf
Jon,
I see exactly this in yr pictures: (from the faq on their website)
9. How does angular acceleration affect pulses and error?
Angular acceleration does not cause missing pulses. But it does cause
some lag in position, proportional to acceleration and T^2. (with T=
100, 50, 25, 13 µs at resolution settings D2, D1 = 11, 10, 01, 00,
respectively). The internal position follower will have no problem
with acceleration as long as the resulting position error stays within
256 increments (4 increments per quadrature period) for resolution
2048 PPR, with the limit being proportional in other resolutions. The
position follower will catch up at the end of acceleration.
Decreasing the basic resolution will reduce acceleration error, if
that is of concern for fast loops or removing the SF jumper as
described in section 3 above.
-------------------------------

Yes, I read this and it didn't sound too bad. But, I think the lag is a
LOT more than 100us, up to several
milliseconds, or maybe 30 times worse than what they state.

Post by Jan de Kruyf
so I would give that rubbish a miss. It is good for a position
readout, but definitely not for a high speed feedback loop.

I may experiment some more at different resolutions, and see about that
jumper setting.
Thanks,
Jon
------------------------------------------------------------------------------
EditLive Enterprise is the world's most technically advanced content
authoring tool. Experience the power of Track Changes, Inline Image
Editing and ensure content is compliant with Accessibility Checking.
http://p.sf.net/sfu/ephox-dev2dev
_______________________________________________
Emc-developers mailing list
https://lists.sourceforge.net/lists/listinfo/emc-developers

[Kim Kirwan]

Jon,

I am very glad that you are doing this, I have wanted to do it
myself for a long time. I have always felt that the CUI encoders,
while being admirably cheap, are not as good as an optical
encoder, but I have had no data to support my belief. Maybe you
are about to come up with some.

In the last picture you mentioned, yes, I do see the "lag" (again,
encoder in light-green, CUI in red) and also I see a "lead", where
it seems to realize that it's way behind and it starts to "hurry",
resulting in a steeper slope than the encoder, and an overshoot.
If you look at the right side where it's fairly level, the CUI
oscillates a time or two. So overall it gives the appearance that
(at least in this case) its "estimator" is "overtuned". This is
not necessarily a criticism, because I'm sure it has to be tuned
for the "general case", or to fit in everywhere if possible.

The problem as I see it is that the CUIs are inferred measurement
devices, and so take some finagling to arrive at the result.
Whereas an encoder is strictly a measuring device, like the
barrel of a micrometer. You look, you get a measurement, and
that's it. Even a resolver is a little bit of an inferred
measurement, but I think there's a little less finagling with
a resolver than with the CUIs.

I suspect that the CUI encoders would be very good for adding to
open-loop stepper systems for use as following-error monitors.
(Follow the cautions in the data sheets about mounting them too
close to strong magnets, like stepper motors!). That way, if there
are any problems with them, you can just loosen the following-
error limits a smidgen, and everything will work fine. The tuning
of the machine would not be dependent upon them.

I'd like to see you do a graph of static error vs. rotation, using
some kind of precision degree wheel. In format, something like the
monotonicity error of an A/D or D/A converter. If CUI does not
have a graph like that, one is needed. If they do, you'd be
keeping them honest.

Carry on, Jon, and let us know what you find, please write it up
when you've got some good results there. It should make for a very
interesting report.

Kim

Post by Jon Elson
OK, I think I get it, and it is about what I expected from an encoder
with interpolation.
It isn't exactly a velocity lag, it is an ACELLERATION lag! I did
another plot at
expanded time resolution, http://pico-systems.com/images/vel.png
and it looks like there is a real lag in responding to changes in velocity.
Does anybody agree that is what I'm seeing here?
Thanks,
Jon

[Jon Elson]

Post by Kim Kirwan
Jon,
I am very glad that you are doing this, I have wanted to do it
myself for a long time. I have always felt that the CUI encoders,
while being admirably cheap, are not as good as an optical
encoder, but I have had no data to support my belief. Maybe you
are about to come up with some.
In the last picture you mentioned, yes, I do see the "lag" (again,
encoder in light-green, CUI in red) and also I see a "lead", where
it seems to realize that it's way behind and it starts to "hurry",
resulting in a steeper slope than the encoder, and an overshoot.

Yes, exactly. Not a position overshoot but a velocity overshoot.
Anyway, since a major
part of a PID control loop is to manage velocity, serious velocity
errors are going to
cause difficulty in closing the loop.

So, the acceleration lags, and then the velocity has to overshoot for
position to ever catch up.

Post by Kim Kirwan
If you look at the right side where it's fairly level, the CUI
oscillates a time or two. So overall it gives the appearance that
(at least in this case) its "estimator" is "overtuned". This is
not necessarily a criticism, because I'm sure it has to be tuned
for the "general case", or to fit in everywhere if possible.
The problem as I see it is that the CUIs are inferred measurement
devices, and so take some finagling to arrive at the result.
Whereas an encoder is strictly a measuring device, like the
barrel of a micrometer. You look, you get a measurement, and
that's it. Even a resolver is a little bit of an inferred
measurement, but I think there's a little less finagling with
a resolver than with the CUIs.

Well, it is pretty much an unavoidable part of using an interpolation
scheme to turn
a low-resolution sensor into a high-resolution measurement in the form
of a quadrature
encoder signal. Almost all the schemes I've seen used some kind of
velocity tracking
loop so the output pulses try to replicate the velocity of a real encoder.

On the other hand, some other systems like the Analog Devices 2S1200
chip for
resolvers seem to handle this without great delays. Of course, that
chip costs $28
or so.

Post by Kim Kirwan
I suspect that the CUI encoders would be very good for adding to
open-loop stepper systems for use as following-error monitors.
(Follow the cautions in the data sheets about mounting them too
close to strong magnets, like stepper motors!). That way, if there
are any problems with them, you can just loosen the following-
error limits a smidgen, and everything will work fine. The tuning
of the machine would not be dependent upon them.
I'd like to see you do a graph of static error vs. rotation, using
some kind of precision degree wheel. In format, something like the
monotonicity error of an A/D or D/A converter. If CUI does not
have a graph like that, one is needed. If they do, you'd be
keeping them honest.
Carry on, Jon, and let us know what you find, please write it up
when you've got some good results there. It should make for a very
interesting report.

Well, as Jan de Kruyf mentioned earlier, there are some settings that
can affect the problem.
I removed this smoothing filter jumper (I'm guessing that's what "SF"
stands for) but it made
very little difference. I reduced the encoder resolution from 1000
cycler/rev to 512 and that
made a definite improvement. But, cutting encoder resolution is not a
desirable thing to do,
and it only helps but doesn't come anywhere near "curing" the problem.

I tried to decipher the info in the CUI document that Jan quoted from,
but they don't define
units in their equations. Attempting to deduce what the heck they are
saying, maybe this
"But it does cause some lag in position, proportional to acceleration
and T^2. (with T= 100, 50, 25, 13 µs at resolution settings D2, D1 = 11,
10, 01, 00, respectively)" means that if T=100, T^2 means a delay of
10,000 us.
That would certainly explain the problem!

Pretty annoying! I was just about to order some of these encoders for
installation in some really
NICE Pacific Scientific motors I got, but clearly they won't do. I'll
have to spend a lot more
to get Renco encoders, I think. I have Keling motors with encoders
listed on my web store,
but I will have to come up with something different to put on them.

Jon

[Peter C. Wallace]

Date: Sat, 18 Jun 2011 13:52:05 -0500
Subject: Re: [Emc-developers] CUI encoders

Post by Kim Kirwan
Jon,
I am very glad that you are doing this, I have wanted to do it
myself for a long time. I have always felt that the CUI encoders,
while being admirably cheap, are not as good as an optical
encoder, but I have had no data to support my belief. Maybe you
are about to come up with some.
In the last picture you mentioned, yes, I do see the "lag" (again,
encoder in light-green, CUI in red) and also I see a "lead", where
it seems to realize that it's way behind and it starts to "hurry",
resulting in a steeper slope than the encoder, and an overshoot.

Yes, exactly. Not a position overshoot but a velocity overshoot.
Anyway, since a major
part of a PID control loop is to manage velocity, serious velocity
errors are going to
cause difficulty in closing the loop.
So, the acceleration lags, and then the velocity has to overshoot for
position to ever catch up.

Post by Kim Kirwan
If you look at the right side where it's fairly level, the CUI
oscillates a time or two. So overall it gives the appearance that
(at least in this case) its "estimator" is "overtuned". This is
not necessarily a criticism, because I'm sure it has to be tuned
for the "general case", or to fit in everywhere if possible.
The problem as I see it is that the CUIs are inferred measurement
devices, and so take some finagling to arrive at the result.
Whereas an encoder is strictly a measuring device, like the
barrel of a micrometer. You look, you get a measurement, and
that's it. Even a resolver is a little bit of an inferred
measurement, but I think there's a little less finagling with
a resolver than with the CUIs.

Well, it is pretty much an unavoidable part of using an interpolation
scheme to turn
a low-resolution sensor into a high-resolution measurement in the form
of a quadrature
encoder signal. Almost all the schemes I've seen used some kind of
velocity tracking
loop so the output pulses try to replicate the velocity of a real encoder.
On the other hand, some other systems like the Analog Devices 2S1200
chip for
resolvers seem to handle this without great delays. Of course, that
chip costs $28
or so.

Post by Kim Kirwan
I suspect that the CUI encoders would be very good for adding to
open-loop stepper systems for use as following-error monitors.
(Follow the cautions in the data sheets about mounting them too
close to strong magnets, like stepper motors!). That way, if there
are any problems with them, you can just loosen the following-
error limits a smidgen, and everything will work fine. The tuning
of the machine would not be dependent upon them.
I'd like to see you do a graph of static error vs. rotation, using
some kind of precision degree wheel. In format, something like the
monotonicity error of an A/D or D/A converter. If CUI does not
have a graph like that, one is needed. If they do, you'd be
keeping them honest.
Carry on, Jon, and let us know what you find, please write it up
when you've got some good results there. It should make for a very
interesting report.

Well, as Jan de Kruyf mentioned earlier, there are some settings that
can affect the problem.
I removed this smoothing filter jumper (I'm guessing that's what "SF"
stands for) but it made
very little difference. I reduced the encoder resolution from 1000
cycler/rev to 512 and that
made a definite improvement. But, cutting encoder resolution is not a
desirable thing to do,
and it only helps but doesn't come anywhere near "curing" the problem.
I tried to decipher the info in the CUI document that Jan quoted from,
but they don't define
units in their equations. Attempting to deduce what the heck they are
saying, maybe this
"But it does cause some lag in position, proportional to acceleration
and T^2. (with T= 100, 50, 25, 13 µs at resolution settings D2, D1 = 11,
10, 01, 00, respectively)" means that if T=100, T^2 means a delay of
10,000 us.
That would certainly explain the problem!
Pretty annoying! I was just about to order some of these encoders for
installation in some really
NICE Pacific Scientific motors I got, but clearly they won't do. I'll
have to spend a lot more
to get Renco encoders, I think. I have Keling motors with encoders
listed on my web store,
but I will have to come up with something different to put on them.
Jon

I suspect the problem is that the velocity follower loop parameters need low P
and I gain at high resolution so that the source induced (A-D) noise is
manageble (not to many quadrature counts dithering about) but this slows the
loops response to acceleration.

I've seen the exact same thing with our resolver interface, you have a
tradeoff between response time and output noise (but in our case the loop
parameters are tunable)

------------------------------------------------------------------------------
EditLive Enterprise is the world's most technically advanced content
authoring tool. Experience the power of Track Changes, Inline Image
Editing and ensure content is compliant with Accessibility Checking.
http://p.sf.net/sfu/ephox-dev2dev
_______________________________________________
Emc-developers mailing list
https://lists.sourceforge.net/lists/listinfo/emc-developers

Peter Wallace
Mesa Electronics

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

[Kim Kirwan]

The CUI sensors use the "kit" (frameless) mounting method.
This mounting method lets you save money when your motor
(or something) has a nice shaft sticking out the back, and
a flat place to mount things.

If you're ever looking for a "kit" (frameless) encoder, I have
had good luck with USDigital's E6 series. Be sure to get the
D option (differential outputs). The E6 series uses a 2" disk
and is available up to 2,500 lines (10,000 counts).
Priced at $87.97 in singles (with D option).
http://usdigital.com/products/encoders/incremental/rotary/kit/e6
http://usdigital.com/assets/general/90_e6_datasheet_0.pdf

If you don't have that much room, there is also the E5 series,
using a 1" disk. Again, be sure to get the D option (differential
outputs). Available up to 1,250 lines (5,000 counts).
Priced at $77.25 in singles (with D option).
http://usdigital.com/products/encoders/incremental/rotary/kit/e5
http://usdigital.com/assets/general/87_e5_datasheet_1.pdf

Kim

... I'll have to spend a lot more to get Renco encoders, I think.
I have Keling motors with encoders listed on my web store,
but I will have to come up with something different to put on them.
Jon

[Jon Elson]

Post by Kim Kirwan
The CUI sensors use the "kit" (frameless) mounting method.
This mounting method lets you save money when your motor
(or something) has a nice shaft sticking out the back, and
a flat place to mount things.
If you're ever looking for a "kit" (frameless) encoder, I have
had good luck with USDigital's E6 series. Be sure to get the
D option (differential outputs). The E6 series uses a 2" disk
and is available up to 2,500 lines (10,000 counts).
Priced at $87.97 in singles (with D option).
http://usdigital.com/products/encoders/incremental/rotary/kit/e6
http://usdigital.com/assets/general/90_e6_datasheet_0.pdf

I have a personal bias against US Digital, as their low-cost line of
encoders have a number
of deficiencies. But, they seem to be becoming the only game in town!
Renco is reducing
what they make available, Avago is cutting back on the higher resolution
units they make
available, etc.

Post by Kim Kirwan
If you don't have that much room, there is also the E5 series,
using a 1" disk. Again, be sure to get the D option (differential
outputs). Available up to 1,250 lines (5,000 counts).
Priced at $77.25 in singles (with D option).
http://usdigital.com/products/encoders/incremental/rotary/kit/e5
http://usdigital.com/assets/general/87_e5_datasheet_1.pdf

I have the Keling size-23 motors on my web store for $120. To use
either of these
encoders, I'd have to raise my prices significantly just to break even.

Do you know of anything a little less expensive with a 1/4" hub and 1000
cycles/rev (lines) preferably
with an index output? I haven't had any problem using single-ended
encoders in
my system, which have filters on the output of the servo amps. The Avago
HEDB-9040-B06 would be great, but they seem to have discontinued the 23mm
radius version that can go up to 1000 lines. Their parameter search
feature on
their web site doesn't work well.

Jon

[Kirk Wallace]

On Sat, 2011-06-18 at 17:14 -0500, Jon Elson wrote:
... snip

Post by Jon Elson
I have a personal bias against US Digital, as their low-cost line of
encoders have a number of deficiencies.

They work well for me, am I missing something?
Loading Image...
Loading Image...

[Jon Elson]

Post by Kirk Wallace
... snip

Post by Jon Elson
I have a personal bias against US Digital, as their low-cost line of
encoders have a number of deficiencies.

They work well for me, am I missing something?
http://www.wallacecompany.com/cnc_lathe/HNC/00001-1a.jpg
http://www.wallacecompany.com/cnc_lathe/HNC/00010-1a.jpg

US Digital used to have a really cheap line of kit encoders (Avago and Renco
call them modular encoders, ie. the motor provides the bearings, but
they have
a housing and usually the disc is trapped within the housing at all
times.) One big
failing is they needed a small cap local to the encoder, and long cables
would cause
the encoder to power down each time there was a transition on the A or B
lines.
I want to avoid having to do microsurgery on the encoders before
shipping them.

Anyway, they may not have these anymore, and everything seems to have
gone up
in price. The cheapest model I could find with 1000 lines and index is the
E2-1000-250-I-D-D-B, which looks like it will fit fine on these Keling
motors.
It lists in small quantity at $62, and goes down to $52 if you buy 10.
This is a
lot more than the CUI encoder, and I'd have to raise my prices, but it isn't
insane.

Your encoders look fine if you have an existing housing to protect the
disc, but
I want something that will just bolt onto the back of the motors.

I am also looking for a couple 6-channel encoders for some Pac Sci motors I
just got. I will probably get them from Renco, but they will only make up
certain combinations of resolution plus commutation if you order 100.
They didn't have 2500 line plus 4-pole commutation in stock.
Apparently, you
can't search their available parts, you have to ask for a quote each time.

Thanks,
Jon

[Andy Pugh]

Post by Jon Elson
Do you know of anything a little less expensive with a 1/4" hub and 1000
cycles/rev (lines) preferably
with an index output?

Do these look familiar?

http://www.slidesandballscrews.com/hkt300635301g1024b5l-p-493.html?cPath=88

[Dave]

What do the Chinese use when they equip a servo driven machine with
encoders?? Surely they are not paying $50-60 per encoder?

Dave

Post by Andy Pugh

Post by Jon Elson
Do you know of anything a little less expensive with a 1/4" hub and 1000
cycles/rev (lines) preferably
with an index output?

Do these look familiar?
http://www.slidesandballscrews.com/hkt300635301g1024b5l-p-493.html?cPath=88
------------------------------------------------------------------------------
EditLive Enterprise is the world's most technically advanced content
authoring tool. Experience the power of Track Changes, Inline Image
Editing and ensure content is compliant with Accessibility Checking.
http://p.sf.net/sfu/ephox-dev2dev
_______________________________________________
Emc-developers mailing list
https://lists.sourceforge.net/lists/listinfo/emc-developers

[Tom Easterday]

I was having some issues with tuning servos with CUI encoder that are connected to Geckos and talked with Mariss. He said the the mounting interface of the CUI encoder can slip and has too much play (backlash) in it. He suggested putting a drop of super glue on the edge of the plastic piece that mounts to the motor shaft (to keep it from slipping), and to put a drop of silicone caulk in a single tooth of the encoder-to-shaft interface in order to take up the space (slop) and reduce backlash. I haven't done this yet, but was thinking that if the ring on the motor shaft could slip a tiny bit, and with the backlash (that is clearly visible), could this be why you are seeing a lag?

-Tom

ps: this is on the developers list but seems relevant to all users...

[Dave]

I think that Mariss started looking at those CUI encoders more than a
year ago as I recall reading on other lists..

I would listen to his advice as he tends to beat the heck out of things
finding out if they are suitable or not for his recommendation.

Dave

Post by Tom Easterday
I was having some issues with tuning servos with CUI encoder that are connected to Geckos and talked with Mariss. He said the the mounting interface of the CUI encoder can slip and has too much play (backlash) in it. He suggested putting a drop of super glue on the edge of the plastic piece that mounts to the motor shaft (to keep it from slipping), and to put a drop of silicone caulk in a single tooth of the encoder-to-shaft interface in order to take up the space (slop) and reduce backlash. I haven't done this yet, but was thinking that if the ring on the motor shaft could slip a tiny bit, and with the backlash (that is clearly visible), could this be why you are seeing a lag?
-Tom
ps: this is on the developers list but seems relevant to all users...
------------------------------------------------------------------------------
EditLive Enterprise is the world's most technically advanced content
authoring tool. Experience the power of Track Changes, Inline Image
Editing and ensure content is compliant with Accessibility Checking.
http://p.sf.net/sfu/ephox-dev2dev
_______________________________________________
Emc-developers mailing list
https://lists.sourceforge.net/lists/listinfo/emc-developers

[Jon Elson]

Post by Tom Easterday
I was having some issues with tuning servos with CUI encoder that are connected to Geckos and talked with Mariss. He said the the mounting interface of the CUI encoder can slip and has too much play (backlash) in it.

Yes, I have seen this on some samples of the CUI encoder. I have had to
put a drop of superglue between the
locking ring and the encoder disc on those. The one I am working with
does not suffer from this problem.

Jon

[Topi Rinkinen]

Hi,

I have two Chinese BLAC servomotors. They are equipped with (Tamagawa's)
something like:
http://www.alibaba.com/product-gs/330725161/Lift_the_original_factory_replacement_Tamagawa.html

I also bought one spare encoder from the manufacturer, price was RMB
370, about USD 57.

I have a little experience by testing them with FPGA, and they seem to
work perfectly (no slips or anomalies).

- Topi

Post by Dave
What do the Chinese use when they equip a servo driven machine with
encoders?? Surely they are not paying $50-60 per encoder?
Dave

Post by Andy Pugh

Post by Jon Elson
Do you know of anything a little less expensive with a 1/4" hub and 1000
cycles/rev (lines) preferably
with an index output?

Do these look familiar?
http://www.slidesandballscrews.com/hkt300635301g1024b5l-p-493.html?cPath=88

[Dave]

Wow.

That is really cheap for a hollow shaft encoder. I wonder why someone
is not importing those to the US?? Or perhaps they are?

Dave

Post by Topi Rinkinen
Hi,
I have two Chinese BLAC servomotors. They are equipped with (Tamagawa's)
http://www.alibaba.com/product-gs/330725161/Lift_the_original_factory_replacement_Tamagawa.html
I also bought one spare encoder from the manufacturer, price was RMB
370, about USD 57.
I have a little experience by testing them with FPGA, and they seem to
work perfectly (no slips or anomalies).
- Topi

Post by Dave
What do the Chinese use when they equip a servo driven machine with
encoders?? Surely they are not paying $50-60 per encoder?
Dave

Post by Andy Pugh

Post by Jon Elson
Do you know of anything a little less expensive with a 1/4" hub and 1000
cycles/rev (lines) preferably
with an index output?

Do these look familiar?
http://www.slidesandballscrews.com/hkt300635301g1024b5l-p-493.html?cPath=88

------------------------------------------------------------------------------
EditLive Enterprise is the world's most technically advanced content
authoring tool. Experience the power of Track Changes, Inline Image
Editing and ensure content is compliant with Accessibility Checking.
http://p.sf.net/sfu/ephox-dev2dev
_______________________________________________
Emc-developers mailing list
https://lists.sourceforge.net/lists/listinfo/emc-developers

[Topi Rinkinen]

Hi,

I asked prices from Chinese suppliers and one seems quite interesting:

Incremental solid shaft encoder, shaft dia 6mm. 1000 pulses per rev, ABZ
output. 5-12V VCC, open collector output.
Price: USD 36. FOB Shanghai.

The only drawback I see is O.C. output, but it can be overcame by
placing TTL=>LVDS transmitters very close to the encoder.

- Topi

Post by Dave
Wow.
That is really cheap for a hollow shaft encoder. I wonder why someone
is not importing those to the US?? Or perhaps they are?
Dave

Post by Topi Rinkinen
Hi,
I have two Chinese BLAC servomotors. They are equipped with (Tamagawa's)
http://www.alibaba.com/product-gs/330725161/Lift_the_original_factory_replacement_Tamagawa.html
I also bought one spare encoder from the manufacturer, price was RMB
370, about USD 57.
I have a little experience by testing them with FPGA, and they seem to
work perfectly (no slips or anomalies).
- Topi

Post by Dave
What do the Chinese use when they equip a servo driven machine with
encoders?? Surely they are not paying $50-60 per encoder?
Dave

Post by Andy Pugh

Post by Jon Elson
Do you know of anything a little less expensive with a 1/4" hub and 1000
cycles/rev (lines) preferably
with an index output?

Do these look familiar?
http://www.slidesandballscrews.com/hkt300635301g1024b5l-p-493.html?cPath=88

------------------------------------------------------------------------------
EditLive Enterprise is the world's most technically advanced content
authoring tool. Experience the power of Track Changes, Inline Image
Editing and ensure content is compliant with Accessibility Checking.
http://p.sf.net/sfu/ephox-dev2dev
_______________________________________________
Emc-developers mailing list
https://lists.sourceforge.net/lists/listinfo/emc-developers

------------------------------------------------------------------------------
EditLive Enterprise is the world's most technically advanced content
authoring tool. Experience the power of Track Changes, Inline Image
Editing and ensure content is compliant with Accessibility Checking.
http://p.sf.net/sfu/ephox-dev2dev
_______________________________________________
Emc-developers mailing list
https://lists.sourceforge.net/lists/listinfo/emc-developers

[andy pugh]

Post by Topi Rinkinen
The only drawback I see is O.C. output, but it can be overcame by
placing TTL=>LVDS transmitters very close to the encoder.

Or resistors at the PC interface to use current-loop signalling?

[Jan de Kruyf]

resistor vs. cable capacitance. -> line speed suffers.
sensitive to noise, in my experience.

j.

Post by andy pugh

Post by Topi Rinkinen
The only drawback I see is O.C. output, but it can be overcame by
placing TTL=>LVDS transmitters very close to the encoder.

Or resistors at the PC interface to use current-loop signalling?
--
atp
"Torque wrenches are for the obedience of fools and the guidance of wise men"
------------------------------------------------------------------------------
EditLive Enterprise is the world's most technically advanced content
authoring tool. Experience the power of Track Changes, Inline Image
Editing and ensure content is compliant with Accessibility Checking.
http://p.sf.net/sfu/ephox-dev2dev
_______________________________________________
Emc-developers mailing list
https://lists.sourceforge.net/lists/listinfo/emc-developers

[Dave]

That is inexpensive for a shaft encoder.

Post by Topi Rinkinen
Hi,
Incremental solid shaft encoder, shaft dia 6mm. 1000 pulses per rev, ABZ
output. 5-12V VCC, open collector output.
Price: USD 36. FOB Shanghai.
The only drawback I see is O.C. output, but it can be overcame by
placing TTL=>LVDS transmitters very close to the encoder.
- Topi

Post by Dave
Wow.
That is really cheap for a hollow shaft encoder. I wonder why someone
is not importing those to the US?? Or perhaps they are?
Dave

Post by Topi Rinkinen
Hi,
I have two Chinese BLAC servomotors. They are equipped with (Tamagawa's)
http://www.alibaba.com/product-gs/330725161/Lift_the_original_factory_replacement_Tamagawa.html
I also bought one spare encoder from the manufacturer, price was RMB
370, about USD 57.
I have a little experience by testing them with FPGA, and they seem to
work perfectly (no slips or anomalies).
- Topi

Post by Dave
What do the Chinese use when they equip a servo driven machine with
encoders?? Surely they are not paying $50-60 per encoder?
Dave

Post by Andy Pugh

Post by Jon Elson
Do you know of anything a little less expensive with a 1/4" hub and 1000
cycles/rev (lines) preferably
with an index output?

Do these look familiar?
http://www.slidesandballscrews.com/hkt300635301g1024b5l-p-493.html?cPath=88

------------------------------------------------------------------------------
EditLive Enterprise is the world's most technically advanced content
authoring tool. Experience the power of Track Changes, Inline Image
Editing and ensure content is compliant with Accessibility Checking.
http://p.sf.net/sfu/ephox-dev2dev
_______________________________________________
Emc-developers mailing list
https://lists.sourceforge.net/lists/listinfo/emc-developers

------------------------------------------------------------------------------
EditLive Enterprise is the world's most technically advanced content
authoring tool. Experience the power of Track Changes, Inline Image
Editing and ensure content is compliant with Accessibility Checking.
http://p.sf.net/sfu/ephox-dev2dev
_______________________________________________
Emc-developers mailing list
https://lists.sourceforge.net/lists/listinfo/emc-developers

------------------------------------------------------------------------------
EditLive Enterprise is the world's most technically advanced content
authoring tool. Experience the power of Track Changes, Inline Image
Editing and ensure content is compliant with Accessibility Checking.
http://p.sf.net/sfu/ephox-dev2dev
_______________________________________________
Emc-developers mailing list
https://lists.sourceforge.net/lists/listinfo/emc-developers

[Jon Elson]

Post by Andy Pugh

Post by Jon Elson
Do you know of anything a little less expensive with a 1/4" hub and 1000
cycles/rev (lines) preferably
with an index output?

Do these look familiar?
http://www.slidesandballscrews.com/hkt300635301g1024b5l-p-493.html?cPath=88

Thanks! Looks like these are made by HEDSS, now looking for a US
distributor, and a data sheet
that has a full part number guide, so I can pick all the right options.
Not having a lot of luck so
far, but thanks for the pointer!

Jon

[Jon Elson]

Post by Jon Elson

Post by Andy Pugh

Post by Jon Elson
Do you know of anything a little less expensive with a 1/4" hub and 1000
cycles/rev (lines) preferably
with an index output?

Do these look familiar?
http://www.slidesandballscrews.com/hkt300635301g1024b5l-p-493.html?cPath=88

Thanks! Looks like these are made by HEDSS, now looking for a US
distributor, and a data sheet
that has a full part number guide, so I can pick all the right options.
Not having a lot of luck so
far, but thanks for the pointer!

HEDSS seems very difficult to work with. Everybody has the same
one-page data sheet that doesn't
give enough info to create a specific part number, or even interpret
part numbers that are stocked
by distributors. So, I have pretty much given up on them. Also, I was
very lucky to finally spot
a note that their 1000 and 1024 line HKT30-series encoders do not have
index.

Seems like the next best thing is the US Digital E2-1000-250-I-D-D-B, at
$62 in single quantity.
Has anybody used the E2 series in EMC applications? I worry that they
might need additional
capacitors to be added to the read head. They even have a note in the
data sheet to not use them
with more than 6 feet of cable without using their $16 line driver
(which they also note adds a
0.1 uF capacitor to the encoder.)

Jon

[Lee Studley]

Hi Jon,
Did you verify that there was issues with the CUI's? I have used them to
repair a large bridgeport
CNC lathe in a professional shop and they worked fine and very accurate.
-Lee Studley

Post by Jon Elson

Post by Jon Elson

Post by Andy Pugh

Post by Jon Elson
Do you know of anything a little less expensive with a 1/4" hub and 1000
cycles/rev (lines) preferably
with an index output?

Do these look familiar?
http://www.slidesandballscrews.com/hkt300635301g1024b5l-p-493.html?cPath=88

Thanks! Looks like these are made by HEDSS, now looking for a US
distributor, and a data sheet
that has a full part number guide, so I can pick all the right options.
Not having a lot of luck so
far, but thanks for the pointer!

HEDSS seems very difficult to work with. Everybody has the same
one-page data sheet that doesn't
give enough info to create a specific part number, or even interpret
part numbers that are stocked
by distributors. So, I have pretty much given up on them. Also, I was
very lucky to finally spot
a note that their 1000 and 1024 line HKT30-series encoders do not have
index.
Seems like the next best thing is the US Digital E2-1000-250-I-D-D-B, at
$62 in single quantity.
Has anybody used the E2 series in EMC applications? I worry that they
might need additional
capacitors to be added to the read head. They even have a note in the
data sheet to not use them
with more than 6 feet of cable without using their $16 line driver
(which they also note adds a
0.1 uF capacitor to the encoder.)
Jon
------------------------------------------------------------------------------
All of the data generated in your IT infrastructure is seriously valuable.
Why? It contains a definitive record of application performance, security
threats, fraudulent activity, and more. Splunk takes this data and makes
sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-d2d-c2
_______________________________________________
Emc-developers mailing list
https://lists.sourceforge.net/lists/listinfo/emc-developers

[Lee Studley]

Jon,
This machine was not the fastest thing on earth, so that may be the
saving point.
-Lee Studley

Post by Lee Studley
Hi Jon,
Did you verify that there was issues with the CUI's? I have used them
to repair a large bridgeport
CNC lathe in a professional shop and they worked fine and very accurate.
-Lee Studley

Post by Jon Elson

Post by Jon Elson

Post by Andy Pugh

Post by Jon Elson
Do you know of anything a little less expensive with a 1/4" hub and 1000
cycles/rev (lines) preferably
with an index output?

Do these look familiar?
http://www.slidesandballscrews.com/hkt300635301g1024b5l-p-493.html?cPath=88

Thanks! Looks like these are made by HEDSS, now looking for a US
distributor, and a data sheet
that has a full part number guide, so I can pick all the right options.
Not having a lot of luck so
far, but thanks for the pointer!

HEDSS seems very difficult to work with. Everybody has the same
one-page data sheet that doesn't
give enough info to create a specific part number, or even interpret
part numbers that are stocked
by distributors. So, I have pretty much given up on them. Also, I was
very lucky to finally spot
a note that their 1000 and 1024 line HKT30-series encoders do not have
index.
Seems like the next best thing is the US Digital E2-1000-250-I-D-D-B, at
$62 in single quantity.
Has anybody used the E2 series in EMC applications? I worry that they
might need additional
capacitors to be added to the read head. They even have a note in the
data sheet to not use them
with more than 6 feet of cable without using their $16 line driver
(which they also note adds a
0.1 uF capacitor to the encoder.)
Jon
------------------------------------------------------------------------------
All of the data generated in your IT infrastructure is seriously valuable.
Why? It contains a definitive record of application performance, security
threats, fraudulent activity, and more. Splunk takes this data and makes
sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-d2d-c2
_______________________________________________
Emc-developers mailing list
https://lists.sourceforge.net/lists/listinfo/emc-developers

[dave]

Post by Jon Elson

Post by Kim Kirwan
The CUI sensors use the "kit" (frameless) mounting method.
This mounting method lets you save money when your motor
(or something) has a nice shaft sticking out the back, and
a flat place to mount things.
If you're ever looking for a "kit" (frameless) encoder, I have
had good luck with USDigital's E6 series. Be sure to get the
D option (differential outputs). The E6 series uses a 2" disk
and is available up to 2,500 lines (10,000 counts).
Priced at $87.97 in singles (with D option).
http://usdigital.com/products/encoders/incremental/rotary/kit/e6
http://usdigital.com/assets/general/90_e6_datasheet_0.pdf

I have a personal bias against US Digital, as their low-cost line of
encoders have a number
of deficiencies. But, they seem to be becoming the only game in town!
Renco is reducing
what they make available, Avago is cutting back on the higher resolution
units they make
available, etc.

Post by Kim Kirwan
If you don't have that much room, there is also the E5 series,
using a 1" disk. Again, be sure to get the D option (differential
outputs). Available up to 1,250 lines (5,000 counts).
Priced at $77.25 in singles (with D option).
http://usdigital.com/products/encoders/incremental/rotary/kit/e5
http://usdigital.com/assets/general/87_e5_datasheet_1.pdf

I have the Keling size-23 motors on my web store for $120. To use
either of these
encoders, I'd have to raise my prices significantly just to break even.
Do you know of anything a little less expensive with a 1/4" hub and 1000
cycles/rev (lines) preferably
with an index output? I haven't had any problem using single-ended
encoders in
my system, which have filters on the output of the servo amps. The Avago
HEDB-9040-B06 would be great, but they seem to have discontinued the 23mm
radius version that can go up to 1000 lines. Their parameter search
feature on
their web site doesn't work well.
Jon

Koyo from Automation Direct is $87. The go upto 2500 ppr.
More money than you want to spend but despite their being labeled at
light duty encoders they seem to survive.
I have a couple on the Mazak, a three on the Cinci and one on the
lathe spindle (but nothing on the lathe is hooked up yet. ;-(
They also offer a hollow shaft (8mm) for the same price.
I expect to use one for the Z on the lathe also.

No magic bullets here. ;-)

HTH

Dave

Post by Jon Elson
------------------------------------------------------------------------------
EditLive Enterprise is the world's most technically advanced content
authoring tool. Experience the power of Track Changes, Inline Image
Editing and ensure content is compliant with Accessibility Checking.
http://p.sf.net/sfu/ephox-dev2dev
_______________________________________________
Emc-developers mailing list
https://lists.sourceforge.net/lists/listinfo/emc-developers