Delaying a inductive prox pulse 1

[ccdubs]

Hi all,

I have an application where we sense rotational speed by using an inductive proximity sensor to send pulses to a counter card on a plc every time a gear tooth passes the prox.

The problem I have is that the resolution is a too low and our speed output is not accurate enough. I have recently learned that the PLC can take a second pulse input and can then be set to count leading and lagging edges of both signals, hence 4x the resolution!!!!

To do this though, one pulse input needs to lag the other. This could be done with 2 proxes offset from each other but this is hard to implement. I was wondering if there is a device available on the market that can do this or if it would be simple enough to use a capacitor (and diode?) circuit of some type. The difficulty is that the frequency ranges from 0-1600Hz although most accuracy is needed at 1500Hz which is its normal running frequency.

Thanks for any help.

 

[itsmoked]

Would it be harder to just increase the teeth the prox sensor is seeing or running the prox sensor with a small pulley to double/triple it's pulse rate?

 

[ccdubs]

At this point I am trying to avoid mechanical solutions. When we make up our next range of gearboxes we will then increase the number of teeth or possible use encoders.

 

[WIRESRCROSSED]

Hi ccdubs:

What is your current sensing range...found a prox with 1.2mm sensing range & switching frequency of 5kHz?

What about analog signal & setup count based upon certain parameters?


..or there is proxes with 2 set points, but with .5-1 kHz switching frequency.

First time trying to answer thread...let me know if way off track.

 

[itsmoked]

If you have open collector prox sensors you could tie their outputs together. This so, either one can pull your PLC input low. Now if your pulses are always less than about 25% in duty cycle you would be able to mount the second prox detector exactly 50 percent out of "tooth phase" with the first prox. You would then double your resolution.

Make sure you try this before broadcasting it out to a zillion sites. ugh.

--- ----------- ---
| | | |
| | | |
- -

Would then be:

--- ---- ---- ---
| | | | | |
| | | | | |
- - -

 

[Skogsgurra]

It would be quite simple to make a delayed replica of your prox's signal - you could use a 74HCT14 schmitt trigger and some resistors and capacitors to achive that - but it will not increase your resolution.

The reason is that you will always get 4 pulses out for each pulse in. And it would be the same thing as multiplying your present result by four. So you gain nothing in resolution. Adding another sensor and positioning it to be 90 degrees out of phase from the original sensor will give you the required quadrature signal. And I would not see it as a "mechanical solution".

Gunnar Englund

http://www.gke.org

 

[ccdubs]

Thanks for the answers.

At this point I should let it be known that as a precaution I have designed the facility to install a second prox a while ago. I have 2 concerns with this though:

1) I doubt the gearbox manufacturer has been able to accurately drill the prox mounting hole to obtain the 90deg shift as the tooth pitch is quite small on a large OD.

2) Another prox is just one more field device that can fail or be broken.

In reply to skogsgurra: the pulses are being fed to a counter which is them sampled by a PLC at a cycle time of 20ms. At this rate we are typically reading 2-4 pulses per cycle which effectively means an error of 25-50% depending on how close you are to the next rising edge. If the counter evaluates all edges on 2 signals you will now count 8-16 pulses per cycle which is lower error. With averaging this will even out but we require a very fast response to speed changes (which do occur in this application which is a wind turbine) so averaging can't be too long.

I am not an electronics whiz and was wondering if the schmitt trigger solution would need to be designed for a certain frequency or would it dynamically change.

 

[itsmoked]

You are not going to gain any new location information by this scheme. Nor any more speed information. You are only going to cause your PLC to have to look at something much faster.

This doesn't seem like a sound solution to me.

 

[Skogsgurra]

The schmitt trigger solution must be designed for your highest operating speed. But, as said, it will not give you any better resolution since every original pulse will always produce exactly four new counts. Not 2 or 3, always 4.

Since this is a wind turbine, I think that your speed will stay in a very narrow window. You can then use a PLL and "gear up" the frequency almost as much as you want. A factor ten will not be difficult at all and it will give you true resolution enhacement.

Google PLL (Phase Locked Loop) for more information.

Gunnar Englund

http://www.gke.org

 

[VEBill]

Turn the problem on its head.

Use the 'prox pulse' to gate a fixed, high speed clock signal. Then you simply count the high speed clock and detemine how many small units of time (1/clk) per tooth.

Using this approach, you can measure the rotational speed to any degree of accuracy and resolution that you might require (limited only by the hardware).

With a sufficiently high clock speed, you could probably map out the variations of the tooth placement on the gear...

If your counter card has limited speed capabilities, then you may want to change the sensor to provide only one pulse per rotation (more counts - resolution - at a lower clk rate).

 

[VEBill]

Clarifying previous: the gating should obviously be from one rising edge to the next rising edge (dependent on the tooth spacing, not tooth width).

Even better would be one pulse per rotation. The resolution only falls away when the rotation speed approaches the clock frequency (not usually an issue).

 

[VisiGoth]

Expounding on Ve1BLL and itsmoked, you might be able to gain a direct measurement of speed, instead of just counting pulses and dividing by time to get speed. If you have a very fast counter (along the lines of VE1BLL) you might be able to correlate the pulse width to speed. This could be very noisy. But if there is any positive correlation to the correct answer you can find a weighting to improve you estimate of speed. our processor would not have the extra pulses itsmoked warns about, but it will have an extra set of calculations or a mapping of pulse width to speed and the averaging of the PW speed estimate with the classical speed estimate.

 

[ccdubs]

Once again thanks for the replies.

To those who have argued that the delayed pulse will not improve speed accuracy I have come around to your way of thinking. The way I look at it is: How can just copying one signal give you any more accuracy?

You need to have some direct sensing to get improvement. In the next week I will install the second prox and "tweak" it until I get the correct phase shift.

FYI, I am doing this by mounting the sensor in a eccentrically bored out piece of studding and by adjusting the protusion of the sensor from the studding I should (by trial and error) be able to get any phase shift I want.

I am now looking at how I can use a rotary encoder for the next batch.

 

[itsmoked]

ccdubs; Not to say you can't glean some "extra" info with tricks like skogs,VE1BLL, and others mentioned but it becomes really kind of specialized and myoptic info if you will.

I will say that for your new design you might want to formalize the two 90degree prox sensors because encoders have a few drawbacks.

1) They cost like stink!

2) They often won't fit the geometry, like they want a shaft thru them et. Or you need extra mechanical linkage chains and what-all.

3) They are usually more complex to replace. May have to be built to spec etc.

Hey, how big are your wind machines?

 

[richs]

You might try using a PIC microcontroller.

It has a 16 bit timer/counter. It can be driven by
a crystal.

You can get interrupts to sample pretty consistantly.
Best case +/- 200 ns.

1. Turn off all interrupts on the PIC.
2. Set up pic to use timer 1 (the 16 bit) to increment from
internal (xtal driven) clock frequency (timer mode).

3. Interrupt on desired edge of the proximity detector
(rising/falling makes no matter).

4. Clear timer, with timer off

5. When interrupts, turn timer on.

6. When interrupts again, turn timer off.

7. Round and scale timer to match. Remember there is
some uncertianty here as the interrupt (if I remember
correctly) will be sampled internally on the third
phase of a 4 phase instruction cycle (hence the
uncertainty). With a 20Mhz clock, that equates to
an instruction time of 200ns. There should be a
fixed time (+/- the uncertianty) between when the
timer is turned on.

8. You could use the pic to adjust the motor speed
directly without having to have the plc worry about
it at all. Or, have the pic pass it along to the
plc via serial, or other wiggly outputs.....

My personal druthers would be to have the pic do the
speed control and have the plc left to other important
issues.

Cheers,

Rich S.

 

[VEBill]

I'm not sure if my point was sufficiently clear...

There is a fundamental decision (a basic engineering trade-off) that needs to be made (clearly and explicitly) in this sort of situation (measuring RPM).

Which approach is better?
1) Counting rotational events per unit of time, or
2) Counting units of time per rotational event.

Obviously one is the reciprocal of the other. A 'rotational event' is a gear tooth (~ACP) or a single pulse per revolution (~ARP).

Counting teeth per unit time is thus method #1 (even if you count them twice !). This might be the ideal method when things are really cranking around at very high rotational speed and you can count thousands of teeth (resolution!!) in the very short time of your required update rate (several times per second?). Do the math and you'll see that this is the best method (for resolution) only when things are really cranking around (!), or you're willing to accept a very slow update rate (to allow the count to slowly build up to a big enough number that provides some resolution).

Counting a fixed clock gated by the rotation event (tooth for example)is #2. This is ideal when things are turning too slowly which allows time for thousands (millions even, resolution!!!!) of clock pulses per rotational event (tooth, or reference pulse).

If I understand the previous postings, Mr. CC Dubs is using method #1 (perhaps without thinking about the alternative) and is having problems with resolution.

Well, resolution problems are one of the signs that you might want to look at the opposite approach. When N looses resolution, 1/N starts to get very good resolution.

(When talk turns to resolution, I'm always reminded of the difference in scores between Soccer [or European Football] and Basketball. Scores like 1-0 vice scores like 103-106. Anyway...)

Note - in this modern age it is entirely possible to use both methods and intelligently switch between them as the RPM varies. Absolutely trivial given very simple sensors (ideally both ACP and ARP) and some simple software. Such an approach can allow one to measure RPM - with high resolution - at either end of the speed range.

I hope that this helps...

 

[itsmoked]

Nice synopsis VE1BLL.

 

[VEBill]

Further to previous:

You need the following parameters:
1) Number of teeth on the gear.
2) RPM range *
3) Required update interval **

It would be interesting to see your parameters.

* You should design it for the worst imaginable RPM range so that it ~always~ knows what to do.

** You can use a sliding window, which also filters (information time lag), to improve resolution.

 

[VEBill]

"Nice synopsis..."

Didja like the soccer/basketball thingy ? ;-)

It always struck me that the resolution of soccer scores was too low.

 

[itsmoked]

Oh yeah! I hate those two sports though... I think soccer should be corrected with larger goals so the scores approach 30-40 points a game. Watching all those peeps running back and forth up that field to set up kicks only to never make them for two hours is ridiculous!! And watching basketball scores go:

A TEAM 100
B TEAM 100
B TEAM 102
A TEAM 102
A TEAM 104
B TEAM 104
etc,
etc,
etc,Until
A TEAM 106
B TEAM 106
A TEAM 108
B TEAM BEEEEEP
GAME OVER.

This is likewise stupid, as essentially the game came down to when a timer went off.

Why didn't they just flip a coin hours ago, same difference!

They should play until the clock goes off then continue until one team is 4 points ahead. Just common sense.

But I digress...