Skewed Encoder Waveform

I received this e-mail from a potential customer who is trying to determine why his Encoder waveform doesn’t look right.  His name has been changed to protect his identity.

Hi Jim

I have just come across your Web page on RPM calculation using an optical encoder and oscilloscope. I was keen to test out this method of RPM calculation so rigged up my little encoder and oscilloscope without hesitation. I don’t seem to be getting a nice wave wave form across my display, its rather skewed. Could you just point out where I’m going wrong?

Really enjoyed reading your articles. Look forward to hearing back from you soon.

Eddie

Eddie’s photos are below:

Hi Eddie,

I would love to say the problem is that you aren’t using a Quantum Encoder….

But instead it looks like you are just missing a ground reference for the scope.   There is usually a little black alligator clip hanging off the side of the scope probe. That clip needs to be attached to the signal common on the encoder (black or negative on the power supply)

The red arrow below indicates where the ground clip should connect to the scope probe.

The reason your waveform looks  skewed is because the absence of a ground reference causes the scope to pick up ambient 60 Hz noise (it is everywhere, outlets, lights etc.) and couple it with your encoder signal.

Connecting the scope ground to the incremental encoder signal common will clear that right up.

Below is a picture of a scope probe with the ground clip.

Take care,

Jim

Jim Miller is a Design/Application engineer working for Quantum Devices Inc.

He can be reached at (608) 924-3000, or via e-mail at jmiller@quantumdev.com.

Air gap in high resolution optical encoders

As the resolution of optical encoders increases, the distance from sensor to disk decreases. In the incremental encoder industry, this distance is called the “Air gap”.  In the side view photo of an optical encoder above, the two red lines indicate the air gap between the sensor and disk  in a QD145 incremental rotary encoder.

In the photo below I have added a human hair to show perspective.

For more information on optical encoders, contact Quantum Devices  at (608) 924-3000.

Incremental Encoder Engineer interview

I was featured in an interview with EEweb.

Jim Miller – Application and Design Engineer at Quantum Devices

How did you get into electronics/ engineering and when did you start?

I started when I was pretty young, like nine or ten, taking apart radios and using an old wood-burning tool to desolder components from the circuit boards I scavanged. I would pick up anything that was broken or being thrown out and tear it apart. I had no idea what I was doing but eventually stumbled onto some of the “Engineers Notebooks” that Forrest M. Mims III wrote for Radio Shack, those gave me the knowledge I was missing. Before long I was able to blow fuses out in the house on a regular basis. I have come a long way since then – we now have circuit breakers.

Can you tell us about your work experience/ history before becoming an Applications Design Engineer at Quantum Devices?

I have mainly worked with Industrial controls for Food & Beverage, and Pharmaceutical companies, which always includes quite a bit of PLC Programming. That is why you will see a bit of Ladder Logic in with some of the Quantum Devices Blog posts that I do. While I predominantly work with discrete electronics today, the industrial controls experience dovetails nicely with our Optical Encoder lines. Encoders are used on the back of motor and often in industrial applications, so I am able to better understand the way an end user might be trying to implement a design, and to some extend the way they might think.

Read more…

Incremental Encoder Lathe Automation

I have been working on a project to automate a manual lathing operation for our incremental encoder/optical encoder line.

To keep things simple, thumb switches allow the set point, along with some offsets for fine-tuning, to be entered.

I am not completely finished with project, but in the video below you can get a feel for how the machine will mill down the incremental encoder shaft.  We have control of the tool position to within .0001”

Cable length considerations with Incremental Encoders

The QD145, QD200 and QR12 series of optical encoders have  28 AWG conductors in the standard flying lead cable.

This gauge of cable is excellent for tight bends and fitting in applications where space is a premium.  The conductors can easily handle the 250 mA max current requirement of the encoder.

A smaller gauge conductor means that there will be a limit to the length of the cable. This is due to the DC resistive loss in the conductor that causes a slight voltage drop.  The longer the cable, the greater the voltage drop.

This voltage drop reduces the voltage seen at the encoder.

For an incremental encoder with a 28 AWG cable operating at 5VDC,  this limitation occurs at 17.85 feet.

There are a few ways around this incremental encoder cable length limitation:

1)       Splice the cable and go with a larger wire gauge for longer cable runs.

2)       Increase the power supply voltage to compensate for the voltage drop in the cable.

3)       For Incremental only (Non-commutated Encoders) Quantum Devices offers a 26 AWG cable.  26 AWG conductors bring the cable length limitation to 28.1 feet.

For other options, or help in determining the right wire gauge or incremental encoder for your application, you can reach Jim at (608) 924-300.

QD145 Incremental Encoder Shaft Tolerance

I received a phone call the other day that caught me a bit off guard. A customer was asking what tolerance they need to have on their motor shaft for it to fit with one of our incremental encoders.   I reflexively told the customer that we machine our shaft I.D. to  a –0.0000” +.0005” tolerance. He told me he already knew that, but what did we recommend for his shaft, the motor shaft that the incremental encoder was to be mounted on?

Since I am an Electrical Engineer, I wanted to make sure I had all of my ducks in a row before I took my second shot at answering a mechanical related question. I let him know that I would look up the information he needed and call him back.  After I got off the phone I immediately knew what I should have told him.  This answer may surprise you, but we don’t specify tolerances for the fit of our customer’s motor shafts. – not in the way one would expect.  Instead of a fit tolerance, we have TIR and Endplay tolerances on total encoder movement after it is mounted.

The reason for this is because unlike modular incremental encoders, which rely on the mounting shaft to hold the disk and sensor air gap, the QD145 series of incremental encoders has an internal bearing set that maintains the air gap. This takes the need for an exacting precision shaft to shaft fit out of the list of problems motor manufacturers face when designing a new motor.

I called the customer back and let him know the good news; that instead of some tight machining numbers, he only needed to keep his QD145 Incremental encoder within .007” of radial shaft runout and within +/- .030” for axial shaft runout.

I also pointed him to our QD145 Incremental Encoder Mounting Instructions, which contain other incremental encoder mounting, and wiring suggestions.

How to calculate pulses per degree for an incremental encoder

When using an Incremental Encoder, you often have to know how many pulses there are per degree of rotation. This is a very straightforward math problem.

Pulses per Degree = Number of encoder pulses per rotation/Number of degrees in a circle

For a 5000 Line count incremental rotary encoder we divide 5000/360 to get 13.89 pulses per degree of rotation.

Calculating Degrees of rotation per pulse for an incremental encoder

If you want to find out how many mechanical degrees of rotation there are for one pulse, you would do the problem the other way:

  Pulses per Degree = Number of degrees in a circle/Number of encoder pulses per rotation

For a 5000 rotary incremental encoder we divide 360 by 5000 to get 0.072.

This means that there are  0.072 Mechanical Degrees of rotation for every incremental encoder pulse.

This calculation is often useful if you have a counter totalizing incremental encoder pulses over a given distance or rotation.

Related articles

• Finding the RPM of an Optical Encoder using an Oscilloscope (quantumdevices.wordpress.com)
• Help picking the resolution of an Incremental Encoder (quantumdevices.wordpress.com)

QD145 Incremental Encoder IP-66 Sealing Option

Quantum Devices Inc. has a mounting option that allows for IP-66 sealing of the QD145 Incremental Encoder.  There are two o-rings in the clam shell design; One o-ring seals the encoder to the mounting surface (usually a motor), and the other o-ring seals the end bell housing that covers the encoder.  This is a popular, inexpensive, option for customers who may not need the IP-66 sealing,  but want some sort of end bell protection over the encoder.

Quantum Devices Interface Cable for the QDH20

Quantum Devices is now offering an interface cable to our QDH20 series of Industrial Incremental Encoders.

While we like to focus more on building encoders than “add on” products, we did find this to be something that made sense to offer with our QDH20 encoders.

At this time the ten pin Female MS connector to flying leads is the only interface cable for the QDH20 encoder that is option being offered.  Part numbers can be constructed  by using the prefeix 2100A and adding the length of the desired cable in inches as a part suffix.

Example:

If an eight foot cable is desired, 8 x12 = 96 so the part number would be 2100A096

Contact any of our distributors, or QDI sales for pricing and delivery

 

Jim

Help picking the resolution of an Incremental Encoder

I recently received an e-mail asking for some help picking the right resolution for an Optical Incremental Encoder.  I have removed the personal information and the drive/controller information, otherwise the e-mail is verbatim:

Hi,

I am using a  motor controller in dual loop velocity mode.

What resolution incremental encoder would I need if I wanted to achieve 1%
or better velocity regulation in the range of 0.1RPM to 230RPM on the output
shaft of the gearbox.

The velocity control loop on the controller runs at 1kHz.

I have used your online calculator and it says 600k lines is this correct?

Here was my response:

I think I see what you are after, but you are missing  some information.  The Encoder calculator on the web site is a bit too simple for what you are trying to do.  It is really meant to be a quick conversion tool to find out of your Incremental Encoder is going to violate controller input frequency limitations, and the like.

The ability of the system to regulate to a given speed will depend on more than just the line count of the encoder. The real question that needs to be answered before we can determine Incremental Encoder resolution is “How many pulses are needed per update?” this is a question that will need to be asked of the Drive manufacturer/supplier, but I am sure they will have further questions about the motor size  and loading as well. 

It is easy to see that a motor without a load is easier to regulate than one with a dynamic (changing) load.  Therefore the size of the motor (and it’s inertia)  and the size of the load (and it’s inertia) will need to be taken into account.

With all that being said, we can do some quick math to get a feel for what we do know about the application.

Before I get started, one major thing to note here is that it appears that you are asking for regulation to occur on the output of the gearbox.  I am guessing that the Incremental Encoder is on the motor side (input) of the gear box, so there will be a scaling factor of the input to output ratio that will need to be taken into account along with the following math:

We know that you want to regulate speed within a range of 0.1 RPM to 230 RPM.

Taking the maximum speed of 230 RPM:
230/60 = 3.83 RPS  (Revolutions per Second)

We also know that the drive does a loop update rate of 1000 times/sec  (1Khz)

1000/3.83 = 260.89   updates per Revolution

360 Mechanical Degrees in a revolution

260.89/360     .72469 loop Updates per Degree at full speed.   (Or  1.379 Degrees traveled for every update)

Taking the minimum speed of .1 RPM:
0.1/60 = 0.00167 RPS
1000/ 0.00167  =  600,000 updates per revolution
600000/360 = 1666.67 Loop Updates Per Degree at minimum speed.

After this we really need to ask is “What can the drive do?”  At the top speed we will travel over a degree before the drive can update the loop for any error component.  In the minimum speed example, the drive will not see a change in count over 1667 loop updates. How does the drive handle this? 

To see what this means in Incremental Encoder pulses vs Drive Loop Updates we can take the highest line count encoder we currently provide, a 20,000 LC QR12:

20,000 pulses/360 Mechanical Degrees = 55.5 pulses per mechanical degree

if we use the encoder “post quad”, we can look at the edges of channels A and B pulses to 4x our resolution to 80,000 edges
80000 edges/360 Mechanical Degrees = 222.22 Edges per mechanical degree

For 260 RPM:
55.5 Pulses per degree/.72469 updates per degree = 76.58 pulses per loop update
using edges:
222.22/ .72469 = 306.33 edges per update

For 0.1 RPM:
55.5 Pulses per degree/1666.7 updates per degree = .0333 pulses per loop update (or 30.03 loop updates per Edge)
using edges:
222.22/1666.7 = 0.1333 edges per update  =  0.1333 Edges per update (or 7.5 loop updates per Edge)

Just taking a very rough look at it, a 20,000 line count incremental Encoder appears to have more than enough data per update to give the drive a good idea of how fast the motor is turning at the high speed, while at the slow speed the drive has to wait for several loop updates to pass until it sees even one edge of the Incremental Encoder Signals.

Will the drive be able to regulate at this lower speed without falling out of the 1% tolerance? My guess is probably not, but only the drive manufacturer can answer that for sure.  I am also wondering if 1% regulation is really needed at these slow speeds.

Keep in mind that these numbers would also need to be scaled by the input to output shaft ratio if the encoder is on the input side to the gearbox and the RPM’s above are actually referring to the output shaft speed.

Can the application tolerate being out of the 1% specification momentarily while the drive recovers?  If so, your focus should likely be on loop response time.

At the very least I am guessing tuning the loop to accommodate for both full speed and slow speed may be difficult.

I hope this helps,

Jim