Speed measurement

[Fabios]

Hi,

i must measure the speed of a turbine. There is pulse sensor on a main wheel with 2 bolts. Every one rotary i have 2 pulse. I use an Hight Speed Input(I47/MI0).

The main wheel transmit the rotary to a more little secondary wheel. When the main wheel go to 433 rpm, secondary wheel go to 1011 rpm. Please see the two

attachments. As you can see i have used Frequency mesurement 1000 ms, so in MI0 i have F = impulse number in one second. If i multiply this number for 60 sec i obtain number of pulse in one minute. But now i must ti divide this number for 2 (number of Bolts(bulloni in italian). So as you can see in MI183 i have Main wheel RPM. If now i linearize from 433 to 1011, i obtain secondary wheel rpm. The system work fine, but i have the following problem:

for example if F(MI0) = 10 then speed of secondary wheel = 702 rpm; if F = 11 then speed of secondary wheel = 772 rpm; if F = 12 then speed of secondary wheel = 842 rpm; There is no middle way

So for my application is necessary more precision. Is there another more accuracy sistem via software?

Fabio

[Stein Yair]

If the RPM is fairly stable you can use interpolation. Take two RPM values and find their mean.

Of course, this is just an manipulation. As long as you measure the RPM of the big wheel I don't think there's a way to overcome this problem.

Also, as you shown before, if you take larger intervals the differences will be smaller (At the expense of accuracy).

[Fabios]

> Also, as you shown before, if you take larger intervals the differences will be smaller (At the expense of accuracy).

Sure now is not accuracy.

Why now i don't see precedent post?

Regards

Fabio

[Damian]

Hi Fabios,

I have often had to do very similar to what you are doing. If you want better resolution on your measurement you will need to take a different approach.

If I were doing this I would instead measure the time between pulses (bolts).

So

For the below I have defined the variables as........

XDW25 = CapturedTimeCount

XDW26 = OldCapturedTimeCount

XDW27 = TimeCountDifference

MF2 = TimeBetweenPulses in (ms)

regular DW will work just as well as the XDW

Make sure trigger is a "transition" unlike what is shown in the picture.

1) Rising edge of pulse is seen

2) Store CapturedTimeCount into OldCaptureTimeCount

3) Store the clock value (ie. SDW3) into CapturedTimeCount

4) Subtract OldCapturedTimeCount from CapturedTimeCount and Store in TimeCountDifference

5) Multiply TimeCountDifference by the float 2.5 and place in TimeBetweenPulses "this will give you the time between pulses in miliseconds as a float".

6) Repeat from Step 1

Now to get RPM, RPM = 30000 / TimeBetweenPulses (this accounts for the 2 pulese per rev)(Just make sure you compare for TimeBetweenPulses > 0 before the division)

If the numbers are a bit jumpy, you might want to perform a running average over 3 or 4 values. The Filter FB is handy for this.

D

[Ziwi]

I know you asked for a software solution, but it looks like the sensor is pointing to the nuts on the outside, and there are 8 of them. This should help accuracy?

[Stein Yair]

Fabios, the previous posts were deleted because they contained a wrong approach, according to you.

[Fabios]

> Fabios, the previous posts were deleted because they contained a wrong approach, according to you.

Ok, no problem.

>I know you asked for a software solution, but it looks like the sensor is pointing to the nuts on the outside, and there are 8 of them. >This should help accuracy?

Ziwi, you are right. If i use 8 bolts i have more precision:

10(pulse in one second)*60(sec)/8(bolts)*2,34(ratio 433/1011) = 175,5 rpm

one pulse more:

11(pulse in one second)*60(sec)/8(bolts)*2,34(ratio 433/1011) = 193,05 rpm

It's no the best but it's better. There is only one problem.....it's no possible!

Damian your solution i like it! I study it and test! If i need help i will contact you, according to you!

Regards

Fabio

[Fabios]

Software test

Damian, please look image in the link "software test". I have only a doubt: MF2 (TimeBetweenPulses) remain ever > 0, also when the wheel is stop. Second your opinion is a good way to insert a timer (TD 1 sec) and ceck if for 1 sec no arrive impulse from I47 then MF2 = 0?

Regards

Fabio

[Damian]

Software test

Damian, please look image in the link "software test". I have only a doubt: MF2 (TimeBetweenPulses) remain ever > 0, also when the wheel is stop. Second your opinion is a good way to insert a timer (TD 1 sec) and ceck if for 1 sec no arrive impulse from I47 then MF2 = 0?

Regards

Fabio

Hi Fabios,

Here is a reworked example.

I noticed after testing that you needed to divide from 300000.0 and not 30000.0

Let me know if you have an questions.

D

[Fabios]

Hi Fabios,

Here is a reworked example.

I noticed after testing that you needed to divide from 300000.0 and not 30000.0

Let me know if you have an questions.

D

300000? why? 1000ms*60sec/2bolts = 30000

[Damian]

Fabios,

Your right! I was wrong about being wrong.

Some other considerations ..........

I don't know what your scan time is, but if it is large compared to the 2.5ms resolution it would help to make the code interupt driven.

Also, I was just playing with the "Debug" interval function. It gives a resolution of 0.001 ms on the time value. The actual measured resolution will still end up limited by your actual scan time or interupt reaction time, but it would be the most accurate time possible from what I see.

D

[Damian]

Here's another way to skin the cat.

I'm not sure how "wise" it is to do it this way though.

D

[Ziwi]

Great solution from Damian! I like it.

I guess if it were turning really really slow (slower than this) then you could measure the sector angle that the sensor was on for say 5 deg, and time that.

At 680rpm there is 44 ms, not 440 so this is why the 300000. I don't know why though? Is SDW3 = 2.5ms x 10?

[Fabios]

speed test

Ok Damian, i have tested with a V280, it work fine!

I noticed after testing that you needed to divide from 300000.0 and not 30000.0

i have used 30000, and result is exact!

Thank you very much!

Fabio

[Damian]

Great solution from Damian! I like it.

I guess if it were turning really really slow (slower than this) then you could measure the sector angle that the sensor was on for say 5 deg, and time that.

At 680rpm there is 44 ms, not 440 so this is why the 300000. I don't know why though? Is SDW3 = 2.5ms x 10?

Hi Ziwi,

No, 30000.0 was right all along. The numbers in my example were low because I was just using a push button to simulate pulses. I could only get about 2 presses in per second.

When things start getting really slow, you also then have to worry about how consistent/accurate the trigger location is every time. It also relies on the speed being pretty stable and constant. But normally if you are looking for that kind of accuracy you would probably be hanging an encoder off it anyway.

D

[Fabios]

I have tested the Damian's advice. The system work fine but only in low speed. (about 500 pulse for minute).

When i go in hight speed, i lose some pulse, i don't see light up of the led in input card!

Now if i have 20 pulse for minute there is NO problem also for a normal input, because the response time is 10ms on all inputs: 1000ms / 20pulse = 1 pulse

every 50ms. But the problem is: how long a pulse when the wheel run in hight speed? About 0,1mS. This time is the problem.

If i have set the input as HSC i have Minimum pulse width = 80µs. For a normal input i don't know!!!

I have contact unitronics support that advice me to use Immediate Read Physical Input. In this moment i can not try because i'm far from the plant, but

i think that also this solution NO solve problem because Immediate Read Physical Input function is called every plc scan....about 2 ms.

What is your opinion? Is there other way?

[Simon]

Hello Fabio,

I think you are doing a good job of finding all the problems!

If you are using a standard input then the fundamental limit is the speed you can read the input. This is either the normal PLC scan, or you can use the 2.5ms or 1.25ms interrupt routines (depending on the model of PLC you are using). This still isn't fast enough for your pulses, based on the figures you provide above. This is the problem for the high-speed range.

You have already looked at the low-speed range and ruled out using more bolts. However that is really the only option to improve resolution for low-speed frequency measurement using a high-speed counter.

Here's a thought. Note that when you configure an input as a high-speed counter, you can also still read the immediate value of the input, as a normal digital input. For low speeds you read the input directly in logic, as you have been doing. Then for higher speeds you can read the High-Speed input.

There are definitely some potential problems with this approach, but maybe it's just crazy enough to work...

[Fabios]

Simon thank you very much.

On the datasheet of the I/O DI16 there is wrote:

Response time 10mSec typical :-------------------- What does it mean exatly? How long is necessary Minimum pulse width?

[Damian]

I have tested the Damian's advice. The system work fine but only in low speed. (about 500 pulse for minute).

When i go in hight speed, i lose some pulse, i don't see light up of the led in input card!

Now if i have 20 pulse for minute there is NO problem also for a normal input, because the response time is 10ms on all inputs: 1000ms / 20pulse = 1 pulse

every 50ms. But the problem is: how long a pulse when the wheel run in hight speed? About 0,1mS. This time is the problem.

If i have set the input as HSC i have Minimum pulse width = 80µs. For a normal input i don't know!!!

I have contact unitronics support that advice me to use Immediate Read Physical Input. In this moment i can not try because i'm far from the plant, but

i think that also this solution NO solve problem because Immediate Read Physical Input function is called every plc scan....about 2 ms.

What is your opinion? Is there other way?

Hi Fabios,

If I understand correctly, the source of the issue isn't so much that the frequency of the pulses is too fast but rather the pulse "ON" time is too small as a result of the bolt being too short in width. The good news is, this should be an easy problem to fix.

Simon already hit the nail on the head. Instead of referencing the digital input directly, you will instead need to reference the input indirectly by way of the high speed counter. Assuming you already have the prox wired to one of the high speed inputs, go to the HSC with with reload in the hardware configuration. Select that input to be a HSC, and do not select a frequency measurement. Now you will use the "reload event" M or X bit in place of where you had the contact for the prox in the code.

With the high speed counter, it gives you some flexibility. You can instead have it count to 2. This means that your measurement code would need to divide by 60000 now instead of 30000 since you are only measuring between every other prox. This will also help you get better RPM read resolution IF THE SPEED IS UNIFORM AND CONSTANT during the measurement. Sort of in the same way you can measure the width of a sheet of paper by measuring the thickness of a reem of paper and dividing it by the number of sheets in the reem.

Another consideration, many sensors can be purchased that have a built in time delay. If you had one of these, you could adjust such that the prox output stays on for some minimum time. This is used often in high speed registration applications where things go by too fast for the PLC scan to detect reliably.

You could also put a cap on the bolt to make them "wider" to the prox.

To get better resolution on the above, you might also need to make the HSC interrupt driven. In this case, you would want to use the "Interval" blocks instead of the 2.5ms clock to take the measurement. That combination is probably the best you could do with the system you have as far as performance.

Good luck,

D

[Joe Tauser]

Fabios,

You mentioned the specs for a DI16 module - this implies that you are connecting your prox to an expansion module. If this is the case, then all bets are off. You can only use Immediate Inputs on a Snap I/O module on the large PLCs or on the built-in inputs on the small PLCs (they're all considered snap I/O). There is a bit of delay associated with expansion I/O which is why the response time on a DI16 is 10 ms. You will not be able to sense a faster pulse on an expansion module with any amount of programming.

I did a similar project awhile ago and the solution was to run the high speed inputs all the way back to the PLC and connect them to Snap inputs. Then I put Immediate Inputs in a interrupt routine to get the response time I needed. You'll have to pick the input used based on your shortest possible pulse time.

You also mentioned a V280, so you could use a V200-18-E1B module. The HSC inputs are rated at 10 kHz so you can sense a 0.1 ms pulse, but the V280 only supports the 2.5 ms interrupt routine so the best you'll get from the other inputs is a 2.5 ms response. Anything shorter may or may not be sensed depending on the input state at the beginning of the interrupt routine.

What is the total time duration at high speed? You mentioned a 0.1 ms pulse, but how long is the off time? You may be able to go old school and add a resistor and capacitor across the input to stretch the pulse, but you have to be careful not to stretch it too long and interfere with the next pulse.

Joe T.

[Fabios]

Thank you very much, your advice is very important for me!

go to the HSC with with reload in the hardware configuration

In I/O DI16 there is'nt this option. Can i use "Reset HSC" Function?

Fabio

[Fabios]

Here's another way to skin the cat.

I'm not sure how "wise" it is to do it this way though.

D

Hi,

what is in your example "start Inter.." and "end inter.." function block?

[Damian]

Hi Fabios,

You can find them here.

They are meant to be a means for you to measure the speed of execution of your code. It is basically the start and stop for a very high resolution timer.

D