Dynamic Prop Ballancer - PIC Project

[Gary Warner]

Seeing the $20 accelerometer in the banner ads has me thinking... :rolleyes:

I had this idea several months ago - build a dynamic propeller balancer. I've been looking for a cheap accelerometer ever since.

I used to work at and FBO and we used accelerometers to balance props on full-scale planes. With the accelerometer mounted on top of the engine, a strobe light was used to strobe the blades and consistent vibrations could be seen and indexed for adding weights behind the spinner back plate. A bit of trial and error would result in a strobe that was totally random, indicating the prop was in balance.

I'm thinking that if the rotation was read in degrees (encoded) a readout could show where to add or subtract weight. And with a bit of calibration work, it could also indicate how much weight to use. Kind of like when you get your tires balanced.

What do you guys think? Has this been done here before? Does it sound like a good group project?

Gary
--

[tve]

What do you guys think? Has this been done here before? Does it sound like a good group project?

Gary
--

Sounds like a great project. I'm sure it has been done before somewhere..., but it sounds like fun. What are you able to contribute to the project? I'm pretty busy, but I am also interested in something along these lines. I would be willing to help. I can help with firmware (pic 18F series) and/or board-layout.

Regards,
tve

[ZAGNUT]

whatever you come up with i hope it's a lot simpler and easier to build than this: http://turbinemuseum.de/Gasturbines/Balancing_Tool/balancing_tool.html


dave

[Gary Warner]

What are you able to contribute to the project? tve

Hi tve,

Sorry about not responding back over the weekend - I picked up a nasty bug and I feel like chit.

I was thinking of designing a rotary encoder disk that I'll have my laser cutting guy cut for me. My thoughts are to use photo interrupters to tach the disk, set the phase and to determine the rotation direction (so that once the motor is stopped, you be able to rotate back and forth looking at the display to find to correct location. I short I need to read (and control) the RPM, sync the rotation at zero degrees and detect rotation direction.

Also, I was wondering about a new method of applying the counter balance correction. My thoughts are to use off-center drilled 'washers' that would be mounted with the prop. I've put some thought into this.

The 'washers' (actually blank disks that are drilled out off-center) could be mounted up on the balancer and each size and offset value could be directly read directly off the balancer display. (The balancer will be tached and controlled for a known RPM for both the washer test and the prop balance) A collection of these would be created. Now, when a prop is run on the balancer and the display says the error is 'xyz' vale off, you simply retrieve the correct washer (with the same 'value' and mount it up using the displayed index degrees. Then the washer and the prop are indexed with, say a marker pen, so that they can be removed and reinstalled on a motor with the same location needed for the balance.

The main reason I thought of the washer balance system is because so many times when I balance a prop on a typical balancer, it shows a error that is not in-line with the prop strait up or down. Most of these errors are due to the holes not being drilled perfectly centered. This washer idea would allow for balancing those hard-to-balance props that typically show the weight error with the blades in a horizontal position (or to some degree of that effect).

Thought?

Gary

(sorry if I'm not coherent - this cold has my mind in a thick fog)
--

[Gary Warner]

whatever you come up with i hope it's a lot simpler and easier to build than this: http://turbinemuseum.de/Gasturbines/Balancing_Tool/balancing_tool.html


dave

It's safe to say I won't be making anything that hardware intensive. And so far as easy to use, look at my ideas in the above post. What do you think?

Gary
--

[Gary Warner]

This is the encoder wheel. Each red tic mark is a slot which an optical photo interrupt shines through, encoding rpms, phase index (zero degrees) and the inner offset slots are used to determine rotation direction.

I'm having some trouble envisioning the rotation direction code logic. Any ideas? Have I taken the right approach? Or should I not use this function, but instead only allow one direction rotation when indexing the prop by hand? Or is there another way of reading rotation direction?

Gary
--

[Gary Warner]

Actually, the inner encoder holes are not represented correctly in the above drawing. This is how it should look.

The idea being that the bottom set of holes will be used to represent the direction and the outer (top) holes are used to the degrees offset (I'm using 120 slots, i.e., 3 degrees - that should be close enough, I think). I.E., if the bottom hole is not exposed before the top hole is exposed, then the rotation is of one direction. If the bottom hole is exposed before the top hole is exposed, it's moving in the opposite direction.

Am I on the right track?

Gary
--

[bigandy]

For rotation direction you could try using a quadrature encoder type sensor. There are loads of resources on the net out there!

Cheers
Andy

[Gary Warner]

Like this? http://www.mcmanis.com/chuck/robotics/projects/lab-x3/quadratrak.html

If I read this right, it would need to rotate once for each of the 120 3 degrees of resolution. At 2000 RPM, this little control would be running at 240,000 RPM! I see a problem with this. Am I missing something here?

I could see using (engaging) the sensor only when turning the prop by hand, but that would add complications to the use and manufacturing.

Still, I'm all for the use of as much off-the-shelf components as possible.

How would you use the quadrature encoder?

Gary
--

[Comatose]

Gary,

You can make an encoder wheel at home, using transparency film and the heaviest ink setting on your printer.

Quadrature encoders aren't that bad if you're using a microcontroller that has an external interrupt. Basically, when you get a high to low transistion on your primary channel (set up going into your INT pin), read the secondary channel. If its high, increment your counter. If its low, then decrement your counter. That'll give you position.

Do you really need 3 degree resolution for a prop balancer? it seems to me that you could get away with far less, because you only have a few prop blades. Using the 2 axis accelerometer, you'd need four ticks per blade, minimum (with a two or four bladed prop they'd overlap). If these transitions are aligned with the prop blades and the acelerometer axes, then the code would go something kinda like this for a two bladed prop


when(interrupt) (blade is aligned with accelerometer axis)
{
if(0 degrees)
get X channel


else if(90 degrees)
get Y channel

else if(180 degrees)
get X channel

else
get Y channel

}

Then subtracting the 0 degree acceleration from the 180 degree acceleration will give you the imbalance in the prop, and the 90 - 270 degree should give you the same values. A positive number would mean the prop was too heavy on one side, and a negative number would mean it was too heavy on the other. Run this for a bit and average the numbers to get rid of noise.

It'd be a little more complicated for three bladed and four bladed props (needs to track more) but not too bad.

[Gary Warner]

All good information, thanks.

I like the idea about 'printing' my own encoder wheel. Sounds like I'll be doing this.

I like the simplicity of your concept to use both axis of the accelerometer, at least in reducing code overhead. But doesn’t full address one part of my concept. If I read your logic correctly, it requires trial and error, and it doesn’t address 'width-wise' balance errors (errors that do not correspond to any of the blades in the vertical axis, as seen on conventional static balancers). Well, it does 'address' it, but it offers no way of making this kind of adjustment in balance. Adding of subtracting weight from the 'side' of the prop has always been the downfall of prop balancers, IMHO.

Here's what my goals are:

Able to swing blades from 3" to 14" (actual size limited by the RPM's it's run at and the power available).

Able to rotate the prop by hand, after testing it, to the exact (with 3 degrees) point of error on the vertical axis.

Able to apply known weighted washers (holes drilled off center - indexed to their vertical offset) to the shaft.

Able to re-check balance and have it read back "0 correction needed" on the first or second re-check. Be accurate enough to get reproducible results with each check.

Eliminate trial and error in balancing.

Avoid modifying the blades in any way.

Be as simple to use as a car tire balancer.

Use off the shelf cheap motor and hardware.

Able to self calibrate system and trim washers (weights).

Use only one of the axis of the accelerometer (vertical axis).

Be a reproducible construction project for those of our level of skills.


I explained the 'washer weight' to a friend of mine and he wasn't big on this. He was concerned about the washer turning after being mounted and loosing a matched washer/prop combinations. I thought that if a drop of thin CA was applied between the washer and the prop, they could stay matched and aligned, within reason. I still think his point is valid and I'm currently trying to get my little brain cells aligned up enough to find a better solution. But even if I don't, I'll use the CA idea, though it may not be the best solution to the problem.

As I see it, there are only three advantages to this kind of balancer. It will be accurate, able to balance side errors and no blade modification. And after the 'play time' ends with having fun with it, it will be very fast to use too. If I can't address these advantages, then I might as well use the 'ol standby balancer.

Gary


(sorry if I sound like I'm preaching - I havn't fully explained what my goals were 'till now)
--

[Comatose]

Okay, I see where you're going with this.

In that case, you still only need four ticks on your encoder. The measured acceleration is going to be the vector sum of the two accelerometer axes if you use both (but do a vector add instead of simply averaging them for magnitude, and do an arctangent to get the angle) that will get you the angle by which the prop is off balance and the magnitude. Using both axis of the accelerometer and an arctangent with four ticks per revolution seems much easier than one axis and 120 ticks. More accurate too, and there's no trial and error involved.

I don't see why you wouldn't want to use both axes of the accelerometer, its a two axis accelerometer.

[Gary Warner]

This is GREAT conversation. It's getting the mental juices flowing. And considering my bad cold, I could use all the help I can get. :)

The reason for using only one axis is that the motor mounts might have a different level of rigidity for the two axis. That is, one axis might move so much for any given g-force and the other axis might move slightly (or considerably) differently. In fact, I don't see how they could be matched perfectly without major mechanical work to the apparatus; that is the test stand (maybe stand the motor assembly on end, eliminating the forces of gravity?).

Errors caused by an out of balance condition will have a single peaked error that stays constant with any angle (degree of offset) and only occur once in any given rotation cycle (given only + or - deviations are monitored). When that error (max deviation) is detected and the rotation angle is known (encoding the rotation through the 360 degree arc) than this is the exact position of the error and the amount of error can de directly read from the accelerometer by means of amplitude. The readout doesn't even have to convey a specific real-world measurement. It can be any value, so long as the washers have been documented (calibrated) for their 'values' in identical speed (known constant RPM) tests.

I go back to the FBO where we did dynamic balance of props. Only one axis was used (vertical), and for $4500 for the equipment, I think they would have used a second axis if it was going to do a better job. This project only hopes to improve on the full-scale prop balancers in such that it won't need a strobe light and the amount of weight needed will be a known (exact) value.

The only reason that the full-scale balancers fall short of this project is that the RPM's and the location of the washer(s) (distance from the point of rotation; i.e. spinner diameter) are not known and not needed, if you are willing to balance the prop with a fair bit of trial and error. Now, if someone was willing to encode the engine speed, phase and position (indexing when the motor was peaked off balance), and do the software programming, the washer locations (distance from the center of rotation) and weight.... then they too would have a one time balance tool.

Given how easy it is to understand the principals involved, it's a wonder why no one has done so yet, at least at the FBO level of service. Then again, FBO's make their money by the hour. Balance a prop too fast and aircraft owners wouldn't think you were earning your money legitimately. :rolleyes:

Again, great conversation. Keep'em coming. I REALLY like your idea about the encoder being printed. That alone has saved me $20 or so having a disk cut at the laser cutter. :D

Gary
--

[Comatose]

Okay, thats a fair point about the rigidity, though with clever software you could get around it.

A fast encoder isn't a huge problem, it just complicates things a little. The major source of difficulty is that the standard interrupt handler on a PIC written in CCS C (what I use) ranges from 20 to about 60 instructions per interrupt, plus whatver your routine takes. Its certainly not insurmountable like that, but you may end up needing a pretty fast clock, especially if you end up doing the standard quadrature thing of reading both edges of both pulse streams.

[Gary Warner]

I understand this. I can assembly code an interrupt that only uses 4 instruction cycles (if I remember right) plus cycles used to store data and execute code. I'll be storing as much data in ram as it's recorded to minimize the interrupt latency. So far as the multiple interrupts, well I haven't quite figured that one out yet. I assumed that I'd used the degree offset photo interrupt are the primary CPU interrupt since this seems to me to be the most critical step. All others can just be port scans. The only reason I need to read the inner photo interrupt is when turning the prop by hand (a much slower process of reading the quadrature). The tack monitor could be read directly off the degree encoding or use a third photo interrupt. If the third interrupt was used, tach speed can be a controlled by a separate 555 timer, PWM generator. Though I'd like to have the CPU control the speed, it's not necessary. So, if the RPM's are...

Oh crud... I see a problem in the above logic. Well, I won't delete the words, so you can see what my line of thinking was. (CPU has to detect zero degrees - most important?)

Anyway...

I wondered about processing overhead this morning when I was taking a shower (I do my best thinking when naked and wet :D ). I was running the code logic in my head and wondered about the A/D conversion time (delay) and to what extent that was going to have on recording the correct angle of error.

My solution was to read each individual degree of offset individually. To explain, I'd start by reading the 0 degree offset. I'll latch the A/D converter and wait for the A/D flag to be set. Now the motor will have moved on by that time. The value will be recorded in a table that corresponds with 0 degree offset location. Then, regardless of where the motor is at the end of the program cycle, the program will repeat this process when the next angle (0 degrees + one tick (3 degrees)) comes around. This process is repeated for all of the 120 possible positions.

Once the 120 cycle is completed the peak value offset degree will be noted. Then, the process will be repeated, except that only 30 degrees (10 ticks) plus and minus from the peak will be sensed and recorded. If the same peek offset degrees are seen in 'x' number of program cycle loops (I haven't decided just how many repeated cycles will be needed), then that degree is finally set as the error degree. The amplitude of the average peak value readings will be the displayed error.

In this way, several code problems can be addressed. First, I don't have to run lightning fast code to read an A/D and complete the program cycle before the next degree comes up. I'll just do the A/D latch and let the motor go, waiting for the program cycle to finish. Then I’ll be able to just wait for the next degree (optical sence) for reading the next degree. Also, by using averaging math, I'll be able to reduce noise from the sensor so that I get better real amount of error.

In all, I expect the whole spinning process to take about 5 seconds to complete and most of that will be just stabilizing the motor RPM's. But I’m not setting any process time in stone; it’s just a rough guess.

Thoughts?

Gary
(I'm not a real programer, I just play one on the web ;) )
--

[Gary Warner]

While I seem to in the long-winded mode...

Motor control:

I plan on making the unit around an 05 or Speed 700 brushed motor, direct drive. I might have to consider a gear drive for the larger props. But for now, I'll just look at the direct drive. The motor will be controlled with a conventional ESC for electric flight and a regulated power source. I know not everyone has access to a $200 40 amp bench power supply, so I'll have to assume that others will be using a motor battery.

I'll uses the CPU to send out the PWM pulse to the controller. On start up, the pulse will be set to .5ms, and hold there for about 5 or 10 seconds. This will allow for some ESC's to arm in their low power setting. Also, a buzzer and/or LED will warn the user about the intent to start the motor. A 'cancel' button will also be available to stop the startup process or to stop the motor at any point in the running process (safety).

Once the startup 'hold' time has elapsed, I will have the CPU slowly begin to increase the PWM. At a reasonable level (say .6 to .8ms) the motor should be running. The CPU reads the tach speed. If it fails to reach a minimum tach speed, the process is stopped and an error indication would be given (this assumes that the motor is blocked or incapable of turning). Once this safe condition is met, then the controller will continue to increase the motor speed up to a preset RPM. Only the tach photo interrupter is used for this. The tach speed is checked against a timer to see if speed is reached. If for some reason the motor can not come up to speed or the PWM output reaches 1.5ms (max ESC output) without reaching speed, again, a fault will be displayed and the process stopped. Assuming the RPM's are reached, the controller PWM will adjust for errors to maintain that speed. For practical purposes, the 'steps' in the PWM will be adjusted to the closest level to come as close as possible to the required speed. In other words, the output will slowly increase or decrease the PWM steps and use a 'hold' type function, unless changes are detected. It's not a full FG feedback loop, i.e. it's not going to 'hunt' for the correct RPM's all the time.

Considering the relatively short time for the whole process, I'm considering just 'locking' the PWM to the value that keeps the speed at the prescribed level. In other words, Once the PWM value is found for the required RPM's, the CPU simply continues to output this same value for the rest of the running process. I could actively servo lock the PWM signal, but why? It will be relatively stable for the following 5 seconds or so. This might pose a small problem for the battery applications, since battery voltage will always be changing, a bit. Not enough to be of concern, I think. For my purpose, the regulated power supply won't change voltage once the RPM's are locked in. The voltage does drop a bit on the wires, due to voltage drop, but it won't change under a constant load.

Now the balance error routines would kick in, as described in the previous post.

Once the error routines have completed, the PWM will be quickly, but smoothly reduced to .5ms, hold there for a few seconds (allowing ESC brake functions to work) and will finally hold the PWM to .4ms, ensuring the ESC won't restart. The display will read out the errors in balance. The user MUST disconnect the battery before rotating the prop by hand to align the prop with the error. If, for some reason the prop is moved and the battery is still attached, then the CPU can detect the rotations and warn the user to disconnect the battery via a buzzer and/or LED.

This is a work in progress and I'd like to hear what you all think.

Gary
--

[Comatose]

That sounds reasonable enough, but do you really need the ESC? If your micro of choice has a hardware PWM function, why not just use that to drive a low side fet? If people replicating the project need more current for their setup, adding more fets in parallel wouldn't be too much of a chore. IMHO, the less conversions in the feedback path the better, so micro-pwm-ESCmicro-ESCpwm seems more complicated than micro-PWM-FET.

[Gary Warner]

To start to put things into real world practice, I'm going to build the motor control circuits now. Lets see if I can get the control logic to work correctly. Also, since I'll be making this hardware first, I'll go ahead and use a separate CPU for the motor control routines. At another time, I'll consider adding the motor control function to the main CPU. But for now it will be a slave CPU. I'll reference a 16C71 (since I have a boat load of them)

First thing: What's the time for the tach rotations?

Well, if I did the math right, these numbers can be used:

10ms = 6,000 RPM
20ms = 3,000 RPM
30ms = 1999.99... RPM (I'll call this 2,000)
40ms = 1500 RPM
50ms = 1200 RPM
(1000ms = 60 RPM)

I got these numbers by:

60*(1/Sec)

Is that math correct?

If so, I'll continue...

I 'could' use a key pad and display to select the desired speed, but for now, I'll just use binary dip switches. These switches and other I/O functions will be connected to:

Bits 1 -7 on portB (4 bit input - 16 selected speeds)

PWM output will be bits 0 on portA

Interrupt from the tach photo sensor goes to bit 0 on portB (int. port on this CPU)

2 wire mode select from master CPU (4 selected modes - in test conditions, 2 switches will be used)

Let me think about this... just what run modes do I need?

1 - start mode (input)
2 - stop mode (input)
3 - locked mode (output)
4 - error mode (output)

Ok, so I'll use one control bit for start/stop control from the MCPU and another bit to tell the MCPU it's locked or if errors. So, for this trial hardware, I'll use one switch for the MCPU inputs and an LED for the output to the MCPU. The LED will read steady for locked and flash for error.

I'm out of time toady. I'll put some rough code together tomorrow an post it for you all to check.

Gary
--

[Gary Warner]

That sounds reasonable enough, but do you really need the ESC? If your micro of choice has a hardware PWM function, why not just use that to drive a low side fet? If people replicating the project need more current for their setup, adding more fets in parallel wouldn't be too much of a chore. IMHO, the less conversions in the feedback path the better, so micro-pwm-ESCmicro-ESCpwm seems more complicated than micro-PWM-FET.

That's very true. I think you have a good point. I just assumed the use of a speed controller since I already have some PWM code to run servos. I guess if anyone was going through to trouble to make this hardware, adding a FET drive for the motor is easy enough.

Sold, unless others have additional comments.

I'll adjust my logic and code for direct MOSFET drive from here on out. IRF44's are cheap enough. Think I can get away with 5 volt drive without going to L's? I've run 300 watt systems on 4 IRF44 high level FET's without problems in airplanes.

Thanks for the good input.

Gary
--

[Gary Warner]

One question...

I've never gotten a full swing from 0 PWM output to 100% PWM output on these chips (no PWM port). I've always hit the multi-task problem, where I run out of processing overhead. I can get to about 95% output, but the code needs about the last 5% or so to run the calculations. Little help?

Should I just saturate the output at 95%, leaving the rest as calculation headroom?

Gary
(amateur hard at work)
--

[Comatose]

Gary,

Limiting your duty cycle sounds like a good plan. You probably don't need more than ~80% duty cycle anyway, as you don't need your test stand to climb from a sustained hover.

Using a chip with a hardware PWM would be easier, and flash is certainly easier to work with, but i certainly can understand the "i have a bunch of them" argument. You'll probably want to limit it lower, actually, because you'll need a nontrivial amount of processor time to process the interrupts. If you were working from scratch I'd suggest a pic16f818 or pic16f684, which are pretty cheap and have hardware PWM and analog.

[TugBoat]

Gary,

Background Info:

Yes, it is possible to get past the 95% PWM problem using software PWM. (My ESC design does this: see http://www.rcgroups.com/forums/showthread.php?t=259623)

The way I solve this problem is to use a combination of timer interrupt and software loop timing for those PWM rates with very short on or off time. Other rates just use the timer interrupt. You can see the documentation for details of how this works.

Comment:

Like Comatose I agree that you probably don't need to reach 100% duty cycle and the added complexity of getting from say 95% to 100% is not worth it for this application.

I presume you are going to need to be able to limit the prop RPM anyway - you don't want to exceed the maximum RPM for the prop - and I suspect this will happen a long way before 100% motor drive with the direct drive you are suggesting.

Another advantage of 'building in' the ESC function is that you will be able to build in the slow start and smooth braking to spin the prop up&down. You can do this by applying a slowing increasing PWM rate to the brake FET until you get close to 100% then just go to 100% brake (this is how my ESC does slow brake). You may also be able to detect certain failure situations better.

This sounds like an interesting project. I suppose I see the mechanical part as being more difficult/interesting have you developed any drawings of what this thing 'looks like'?

Tim

[Gary Warner]

A bit of change in plans. I'm not going to use the 16C71 and I'm not going to break the project up into two CPU's. After sifting through my 'goody box', I found that I have a 16F877-20/P. It's a bigger chip, but it has more than enough features. With 8K prog. mem., 368 RAM and 256 EEPROM I could do this project and still have enough room to have it cook breakfast too :p . What really made up my mind was the 2 CCP/PWM modules and 10 bit A/D's. Plus, If I'm going to eventually incorporate a key pad and DMC Optrex display this CPU won't have any trouble doing so.

I've never worked with the F series chips. I got to looking at an old copy (2000) of PicBasic Pro (PBP) and for what I want to do, I think I'll be using this for programming. Most of the code work is just logic (which I usually do just well in assembly) but I want access to some higher level math without the steep learning curve. I can probably use my PICC but I’m a fair bit better in PBP.

Any who...

I'm off the www.melabs.com to get all the upgrades for their software and programmer. I'm also going to need to go to the parts house to get ZIF socket for this IC. Once these things are handled (a few days) then I can start putting the board together. I'll be working on code modules until then.

Gary
--

[ZAGNUT]

i'm not too hot on the eccentric washers but there's no reason i couldn't use this balancer with my standard "scrape a bit at a time till it balances" technique...

to correct width-wise balance i usually glue some lead into the hollow part of the hub or a drilled hole in wood props...if we could calibrate the balancer to the hub size we're working with it could tell what amount of weight is needed...just like a tire balancer

also, those stupid conical clamp things should never be used if you're going for any kind of accuracy. because they only clamp up against the very edge of the hole any slight imperfection or off-center chamfer can throw things way off...not a big deal to make a few different sizes of shafts from drillrod


dave

[Gary Warner]

The nice thing about this setup is that you can use any method you want to balance the prop. You could take a round disk (representing the hub size) and apply known weights to the disk in known offset distances, run the balancer and read the value for assorted weights. Catalog the weights, then retrieve the weights as needs, knowing your only drilling and weighting the hub one time.

I'm going to first use off the shelf 'accurate' centered prop adaptors. As the need arises, I may have to have custom adaptors made or seek out sources for them.

Gary
--

[Gary Warner]

Holly bits and bytes, Batman!

I see it's been a few too many years since I've coded cpu's. It's like starting all over again. The datasheet on the 16F877 is WAY more involved than the 16C71.

I noticed that the PWM output has a frequency low limit of 1221hz at 20mhz clock and 245hz at 4mhz clock. I was hoping to use this chip for some servo driving because of the pwm functions. Can't do it unless I want to clock at about 800khz. As it is, at 20mhz, I'll clock the PWM motor output at 2000hz.

Upgraded PBP is on the way. Should see it Friday. I'm ordering a DE accel. tonight. Photo couplers will be salvaged off some scrap VCR's in the shop, though I'll try to find OEM sensors that anyone could find.

This weekend I'll start making the motor stand/mount and encoder disk. If things stay this slow at work next week, maybe I'll be able to start motor tests. The first to tackle will be to get the motor to lockup at a selected speed and perform the 4 routines (start, stop, lock and error).

[Pete P]

Just make a device which suspends the prop on a very low friction pivot, similar to a clock pendulum (centrifugal/spring type) and have a device watch whow it turns and how fast, and measure the weight of the entire device as it turns.... then you can read the measurement taken from the rotation/weight comparison and output the correct mass at a given R to add.

[FenceMagnet]

what sort of encoder do you need, in final analysis.... I work for an encoder manufacturer..... :D

[Gary Warner]

Just make a device which suspends the prop on a very low friction pivot, similar to a clock pendulum (centrifugal/spring type) and have a device watch whow it turns and how fast, and measure the weight of the entire device as it turns.... then you can read the measurement taken from the rotation/weight comparison and output the correct mass at a given R to add.

Zzzzzzzoooooooooooommmmmmmmmm....

[the sound of this going way over over my head] :confused:

Gary
--

[Gary Warner]

what sort of encoder do you need, in final analysis.... I work for an encoder manufacturer..... :D

I'm going to try optical photo interrupter module that goes over the windowed encoder disk. It would be great to have one part that could 3 levels deep into the disk.

Alternately, I may try a single tx LED on one side and three rx photo diodes on the other. When I get some time today, I'll thumb through a Digikey catalog and see if I can find what I'm looking for.

Gary
--

[Comatose]

Gary,

For encoder wheel and sensor, another thing you might want to try is ripping apart an old ball mouse. They'll have two encoder disks and a quadrature sensors. They're a little bit on the small side, but cheap and readily available.

[Gary Warner]

A few encoder questions:

1 - Can I put the zero degree tach, degree offset and quadrature pickups off center? The way I see it, as long as they are in the same places for the test and post test rotation, they will always indicate the correct locations for the error. I've already concluded that the tach/quadrature sensors don't necessarily have to read adjacent slots. That being the case, the question becomes, can the zero degree encoder be placed in 'any' radial location?

2 - I see that photo sensors have from 3us to 5ms response (rise/fall) times. How can I be sure that the sensor I choose has a fast response time? I have a scope and assume I can make a test that can read the response time, but I can't envision the process. If I get sensors from Digikey or something like that, they'll provide the data. But there will be a good chance that salvaged or surplus parts may not be documented.

Gary
--

[sesat]

Would a Hall-effect cam position sensor (from an ic engine) be a usable substitute for the optical encoder?

Ram.

[Gary Warner]

Gary,

For encoder wheel and sensor, another thing you might want to try is ripping apart an old ball mouse. They'll have two encoder disks and a quadrature sensors. They're a little bit on the small side, but cheap and readily available.

Excellent idea.

I have an old mouse in front of me. I see the output of the RX transistor has 3 leads so there must be two photo receivers inside.

Question: I'm new to this (quadrature encoding), so bare with me. Since there are only single linear slots in the encoder wheel, does that mean that the two receiver sensors are located so that only one is lit on the 'edge' of a slot, both lit at the center of the slot and the other only lit at the other edge?

Also, the two receiver sensors seen to be in a vertical alignment (one stacked over the other). Is this right?

Gary
--

[Gary Warner]

Would a Hall-effect cam position sensor (from an ic engine) be a usable substitute for the optical encoder?

Ram.

Don't know. How fast can they resolve rise/fall times? Don't they use magnets? I'd rather not use any offset weight that would need to be counter balanced.

I was going to use optical sensors since (as it was pointed out to me) I can print out a wheel with 'shutter windows' on a clear plastic sheet. I plan on gluing this sheet to a support disk that will be mounted on the motor shaft. Second option will be to have my laser cutter cut me a wheel out of a thin phonelic (?sp) sheet.

Gary
--

[sesat]

The magnet is attached to the stationary hall sensor ic. A steel pinion is attached to the propshaft, and so there will be a changing flux level measured as the gear-teeth pass by the sensor. Rise/fall times are 400ns for the Melexis part, tunable with a tradeoff with noise.

Allegro Micro would send you samples.

An engine management computer needs to know quite precisely where the engine is in the combustion cycle.


Ram.

[Comatose]

With a standard quad encoder, one of the sensors is positioned to be on the edge of the segment while the other is exactly in the center of the segment or blank, depending on which direction you're turning. If the sensors are mounted at the 3:00 or 3:00 position, they'd be one above the other. if they're mounted at the 12:00 or 6:00 position they'd be side by side.

[Gary Warner]

Here's a link to a HTML document that shows the basic operation logic of the DPB.

DPB Logic Sheet (http://web2.airmail.net/warner1/dpb.htm)

Comments welcome.

(I forgot to add one function that would look for prop rotation while preparing to start the test - results would cause error and failed stop, due to an assumption that 'hands/fingers' are in the way of the prop.)

Gary
--

[FenceMagnet]

no interest in a commercial encoder..... shrug :(

the sensors can be placed anywhere around the disk, provided they are phased correctly, only accuracy suffers....

the quadrature channels are phased 90deg from each other, 360deg being one slot cycle on the disk.... you only need quadrature if you need to tell direction.... for a constant direction (tachometer) device, a single channel will suffice.... the once around pulse is called the "index"

:cool:

[Comatose]

Jim,

Gary may not be interested, but I am. What encoder manufacturer do you work for?

[Gary Warner]

no interest in a commercial encoder..... shrug :(

Oh, now my feelings are hurt :p :D

I wasn't blowing you off. I am looking for the kind of sensor I want, so's I can show or explain it to you.

The sensor you speak of, is it hall?

I do need to tell the direction of rotation, since the prop will be turned by hand to set the correct position to add or remove weight. That can and would be rotation in both directions to locate that point.

It could be done with only one direction, but I'd like to have the ability to swing back and forth, crossing over the correct position.

I'm just now learning about quadratic sensing, so I don't have a large resource of vocabulary to explain myself without tons of odd and twisted words. Sorry I sounded like I was blowing you off. I DO need all the help I can get, understanding quadratic sensors.

Can you describe the physical sensors (shape, size, weight) or point to one on the web?

Gary
--

[Gary Warner]

I had an interesting discussion with a friend today. We are both concerned about the +/- 5G range being of a high enough resolution to be of any use. The debate went back and forth until a solution came to mind in the event that the resolution was too small. This is what we came up with.

Since speed and torque are exchanged in a lever, this should multiply the speed (acceleration) at a rate proportional to the moment arm ratio.

What do you think?

Gary
--

[Gary Warner]

Rethinking this a bit...

Since the point of pivot has already been established at the motor mount, only an arm need be mounted along the top of the motor (literally glued to the side of the motor) and extended off the back of the assembly the necessary length. Simpler in design and sill as effective.

Gary
(mind moving a mile a minute... yeah right :rolleyes: )

[Comatose]

With the speced resolution of the accelerometer being 312 mV per g, with a pic ADC being 10 bit, reading both the max and the min acceleration you get 125 ticks per g range.

If your measurement is~ 2.2v-2.8v, you could gain some more resolution be using an op amp to multiply by about 1.5, shifing the range to 3.3-4.2 or maybe a bit higher. That'd get you up close to 200 ticks per g.

The stick extension should work like a charm if your stick is rigid enough, but I'd be inclined to try it without first, just for simplicity's sake.

Actually, the first thing I'd try is cranking up the speed. That'll increase the vibration and my MechE training saya there's nothing that can't be solved with more power.

[Gary Warner]

Oh yeah... MORE POWER! :D

I know. I was hopping to keep the RPM's at a 'safe' level. I guess I could turn the motor faster. How about mounting the prop on backwards? It would reduce the current needed to turn the motor and allow for more RPM's.

Gary
--

[Gary Warner]

I just went to order 2 accelerometers from DE. Found out that if your email address is in Paypal's files, you MUST use Paypal.

I refuse to do ANY business with Paypal (don't get me started...) :mad:

I shot off a note to DE looking for other payment options. Looks like there will be a delay in getting my hands on these accelerometers. :(

Gary
--

[FenceMagnet]

"Gary may not be interested, but I am. What encoder manufacturer do you work for?"

Sensor Systems.... formerly Vernitech.... www.vsensors.com

:cool:

[OmegaDot]

Just getting up to speed on this thread... A couple of things I noted that might be worth mentioning.

1. A lot of talk about encoder selection and over head to interpret angular position.

When I set up a dynamic balancer for my gas turbine rotor, I simply placed a black Sharpy marker line on the shaft and used a reflective optical sensor to sense it. I used an oscilloscope to read out my displacement with the opto sensor as the sweep trigger. In your case, why not use a single position sensor to trigger your data acquisition burst and just ensure that your acquisition rate is constant/known. Then, you can calculate the angle by the time between trigger and peak. Or better yet, fit a A*Sin(Omega*t + phi) function to the data and use the phi value for position (admittedly easier in a PC than a microcontroller).

2. There has been no dicussion of the idea that the phase of the shaft's displacement will change as the speed of the rotor passes through the natural frequency of the mounting system. For the full scale airplane, the resonance is below Idle spped, so this is not an unknown. For sensitivity, you will want to operate near resonance, but this will change with the mass of the prop (and stiffness of the sensing system), soo you may not known which side of resonance you are on. You must build something into your run up process and analysis to account for this. For my turbo, I ramped up my speed control until I saw the 180 phase shift and then read the angle off the scope. I did not "calibrate" the magnitude scale.

3. I used strain gages bonded to the flexures of my bearing supports to monitor the displacement of my shaft. These have the benefit of working down to 0 Hz (unlike many accelerometers).

4. Cheap sensors can be made from Radio Shack piezo speakers (but do not have the low frequency response). See picture...

5. Depending on the design of your suspension, you may or may not be sensitive to thrust imbalance of your prop. Too bad you can't test in a vacuum. In heli rotor tests, I found that the signal from thrust imbalance far outweighted that from mass imbalance.

[Gary Warner]

OmegaDot,

That's very impressive. Just goes to show that there many ways if skinning this cat.

I have a shop full of o-scopes and could do this much easier if it was just for me. I'm trying to make a one-box solution to this balance issue.

Gary
--