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.

Advertisements

Quantum Devices Interface Cable for the QDH20

QDH20 interface cable

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

Cross-referencing RENCO Incremental Encoders

We have always been able to come up with a suitable replacement for Renco encoders, but our customers are making us aware that we need to point that out.

For those who don’t know, Renco, after being absorbed by Heidenhain, made the decision to  eliminate much of their product line.  This move has left quite a few of their customers in the lurch. To help fill this need, we recently started promoting our ability to cross-reference Renco encoder lines on our web site with the rather obvious image you see above.  Clicking on this image will take you to a request form where you can let us know which Renco Encoder you are trying to cross.

Keep in mind that we can cross other encoder manufacturers as well.

As a  general reference, the following Renco incremental encoder cross-reference table can show you which style of Quantum Devices Incremental Encoder will likely work best.

Renco Encoder Quantum Devices Encoder
RHS15 QD145 or QR12
RCM15 QD145 or QR12
RM15 QD145 or QR12
RCH20 QD145 or QR12 or QD200
RHS20 QD145 or QR12 or QD200
RM21 QD145 or QR12 or QD200
RCM21 QD145 or QR12 or QD200
RCH50 QD145 or QD200
R50i QD145 or QR12 or QD200
R35i QR12 or LP12
R22i QR12 or LP12
RA25 QDH20
RDHI QDH20
RS25 QDH20

The use of potentiometers in Incremental Encoder Design

Recently I decided to catalog the competitive Incremental Encoders that have populated the shelves surrounding my desk.  In doing so, I was surprised to find that many of our competitors use potentiometers in their designs.

I can understand why they need to use potentiometers.  In most designs the potentiometers are used to balance the raw analog signals produced by the Incremental Encoder sensor.   A potentiometer is the perfect component for this, you fire up the Incremental Encoder during test, lay a scope probe on it and dial the value specified by Engineering.  For most encoder designs, the only other option is to guess at some resistor values hoping that you don’t have to solder and unsolder resistors too many times until you hone in the correct signal, as that would be a very time consuming process.

While I can understand the use of Potentiometers, the reason that I am a bit shocked by their ubiquity in competitor’s designs is that potentiometers are inherently a much less reliable component.  A resistor is all one solid piece, but a potentiometer (which is a variable resistor) has a resistive track and a movable wiper that slides along to vary the resistance value. Moving parts are inherently less reliable than a non-moveable part.

Here are a few of the PCBs from various manufacturers ,  the potentiometers are circled in Red:

 

This next one is my favorite.  Thirteen potentiometers!

I am proud to say that Quantum Devices Encoders do not use potentiometers in their Incremental Encoder designs.  The reason we can avoid potentiometers is because of our patented phased array sensor that provides perfectly balanced complementary signals right from the sensor.

Other incremental encoder sensors suffer from having their active areas in different locations along the length of the sensor. Since the light source spreads light unevenly over the sensor, some active areas receive more light than others creating signal imbalances.

In Quantum Devices Incremental Encoders the photosensitive areas of each channel are interlaced with each another,  so all active areas receive the same amount of light.  This eliminates the need to balance any signals, which in turn eliminates the need for potentiometers in the design.

Below is an drawing of the phased array sensor Red indicates Channel A active areas, Blue indicates channel B active areas.

The lost Optical Encoder Demo Box

Optical ENcoder Demo Box Main Menu

We recently teamed up with one of our distributors to create a Demo box that showcased our QD145 optical encoder with a Delta Tau PLC and touchscreen panel.  It was sent off to a trade show where potential customers would get to spin the encoder and watch on the screen as counts were incremented and decremented and needles on dials spun.

I thought the Optical Encoder Demo box would make for a fantastic topic to write a post on, so that was my plan as soon as the demo box returned from the show.

Well… it never did come back.  I would love to tell you that I did such a great job on it that our distributor insisted on keeping it but the truth of the matter is that it was lost in shipping.

What I do have is the code and screenshot of the Optical Encoder Demo box, which should be more than enough to explain the functionality. What I don’t have are pictures, or video of the Optical Encoder Demo box in action, so you will have to use a little imagination on your part.
I  mounted the PLC, HMI and encoder to an enclosure that can set on a table.  The default screen (shown above) tells a little about the encoder. From this screen you can select a few different screens that allow you to interact with the encoder.

Count Screen:
This screen shows Pulse Count, Angle, RPM and direction.

Optical Encoder Data Screen

Degree Screen:

This screen shows mechanical degrees. The needle rotates in conjunction with encoder rotation:

Optical Encoder Mechanical Degree Screen

Pulse Count:
This screen shows the direct read count of the encoder, the needle rotates in conjunction with  encoder rotation:

Optical Encoder Pulse Count Screen

Tank Screen:
This is sort of a fun screen where rotation the encoder fills tanks in sequence, tank one fills, when tank one is full it “empties” into tank 2, when tank 2 is full it “empties” into tank 3.  Tank 3 continues to accumulate until 2 billion counts or so. The Drain button clears the levels on all of the tanks.

Optical Encoder Tank Filling Screen

ABZ screen:
This screen indicates status of inputs coming from the encoder.  Since I used a 5000 LC encoder, the screen was not be able to keep up real time when the encoder was rotated really fast, and it was nearly impossible to land on Z(Index) and have it light.

Optical Encoder Incremental Signals Screen

Programming

The Delta Tau was pretty easy to program, with only a couple hiccups.  The manual was a little vague in its explanation of the way two registers were used for some of the counter functions, but a little troubleshooting showed me which bits were activated when the counter set point was hit.

The Ladder Logic

This first rung of code is needed to do some basic housekeeping to ensure that D1022 is properly configured with a “1” on the first program scan. It is set by  M1002 and forever latched by M110.  The value of 1 tells the high speed input that we want a double frequency selection A/B phase counter.

The second rung sets up our high speed counter and checks the count to see if we have gone negative in value. If so, bit M120 is set high.

Rung three turns on a physical output Y11 if the counter set point has been hit.

Rung four moves the set point of 5000 back into the counter if we have gone negative in value. This allows the needles on our display screens to rotate continuously and not peg out to a high or low value.

Rung five updates Register D300 with our counter value every 10mS via the handy M1011 10 mS clock pulse.

Rung six divides the counter value by 16 and moves the answer into Register D302. This is where we start our math for the degree conversion. The rest is scaled by the configuring the screen register in the screen editor software.

Run seven uses the trailing edge of our 10 mS clock pulse to move the counter value into register D310.  This value is held for comparison in time to get RPM.

Rung eight uses the leading edge  of our 10mS clock pulse to find the difference in our stored value and put it out to register D312.  D312 is then doubled and sent out to register D350.

For any of you interested in repeating the project, I have included the BOM below.

Of course, I also used some miscellaneous wire and hardware to construct the Optical Encoder Demo box, but the list below includes all the big ticket items.

From Cymatix:

QD145-5/26-5000-0-02-T1-01-02 Optical Encoder

DOP-AS35THTD 3.5” Color touch screen

DVP12C11T Micro programmable Logic controller 8 inputs 4 High Speed outputs

DRP024V060W1AZ CliQ 24 Vdc, 60 Watt power supply

DVPACAB2A30 3 Meter connection cable

 

From Automation Direct:

DN-R35S1 Din Rail 35mm X7.5mm

WC12C12  N12 Desktop enclosure 12”X12”X9”

DN-T12A Terminal Blocks

DN-EB35MN End Brackets

DN-LAB terminal block labels

Finding the RPM of an Optical Encoder using an Oscilloscope

 

We only need to measure one of the incremental channels in order to calculate the RPM of an optical encoder.  Using an oscilloscope to measure the period of one incremental channel A cycle.

We will need to find the frequency of the incremental signal. Keep in mind that converting from time to frequency is just a simple press of the “one over X” button on a scientific calculator.

Frequency =(1/X time)

Time = (1/X Frequency)

To find RPM Once you have the frequency, Multiply by sixty and divide by the line count.

RPM = (Frequency X 60)/Line count of encoder

 

 

The encoder in the video is a 5000 Line Count encoder.  Channel A is outputting pulses at a frequency of 224.2 Khz

RPM = (224.2Khz X 60)/5000

RPM = (13452000)/5000

RPM = 2690.4 RPM

I often use this method to either verify the speed of a motor controller I have built, or if I know the RPM of the motor, I will sometimes use this as a quick way to verify the line count of an encoder.

You can also use the handy Web-based QDI optical encoder calculator  as well.

 

Jim