Calculations for Meters/per/Minute

Has anyone got any good formulas for displaying the speed of a machine in Meters per Minute?

The problem:

A machine has been retro fitted with a small PLC and HMI a few years ago. (Not by me) The plc is controlling some pneumatic arms and valves. The timing of these valves is done by a proxy looking at gear teeth.

The main motor is controlled by a VFD and a potentiometer. The VFD had a plug in speed indicator that was on the main control panel. The operatives used this display to set the speed for different products that passed through the machine.

The speed indicator got smashed and the customer could not locate another (The drive is a make I have never heard of)

I was asked could I put a speed indication on the HMI.

They wanted a cheap and dirty fix as the speed indication is only used for approximation.

I decided to sample the pulses from the proxy, do the math’s (math) and give a fairly accurate M/P/M reading. Luckily the gear teeth that are being sampled are a 1 to 1 ratio with the speed of the machine.

I decided to sample the pulses every .5 of a second, then multiply this by 2 to give pulses per second, then multiply this by 60 for pulses per minute, then divide this by the distance between peak to peak of the gear teeth. To give a meters/per/ minute reading.

The result was accurate enough except for my time base sampling was (say) sometimes counting 17 pulses and next time 16 pulses with the machine running at the same speed.
With the multiplication this was exaggerating the count and the readout was fluctuating by 4 every .5 of a second. I need a steady readout.

Actually; writing the problem out here has just given me the answer but I will still post for the benefit if others to think about and of course for others to give solutions.

Isn’t this what PLC’s are about, - a problem – a good think – a solution.

There are a few things that you can do to improve the accuracy.

First, you can accumulate pulses over a longer time period. You'll still have a variation in the accumulated count, but that variation will be a smaller percentage of the total, so the amount of variation will be less objectionable. The downside to the longer time period is that the display doesn't get updated as frequently.

You might also try timing a fixed number of pulses. Ten pulses always represents a fixed distance, so calculate the elapsed time to accumulate ten pulses and use that to calculate speed. At low speeds, you may have to wait a long time to get ten pulses.

If you're not already doing it, consider counting both the Off-to-On and the On-to-Off transitions of your prox switch. If you were to look at the prox signal with an oscilloscope, it would probably be reasonably close to a square wave. The more it deviates from a square wave, the more innaccuracy you introduce by counting both edges of the signal.

Another solution is to treat the Meters-per-minute as you would any other analog input signal that jumps around more than you want and put a low-pass filter on it: Speed = Speed*(1-x) + Meters-per-minute*(x), where 1 > x > 0 (or something like that - I don't want to get into a discussion with Peter again).

Since the filter might never actually hit zero, you will want to set it to zero if the Meters-per-minute is zero.

What was the solution that you came up with?

The motion controller guys do it this way.

We compute the number of counts in a period as you do, but we also compute a fraction of counts. To do this one must be able to measure the time between pulses too and when they occurred. When the sampling is done, one must also read the time between the last two pulses and the time since the last pulse. These readings may require a high speed counter card. We get the time between pulses with micro second resolution. You will probably have to settle for millisecond second resolution. If time between the last to pulses ( T_BETWEEN ) = 16 milliseconds and the time since the last pulse ( T_LAST ) =8 milliseconds then the fractional number of pulses is:

T_LAST/T_BETWEEN = 8/16 = .5 FRACTIONAL PULSES

This method greatly improves the speed estimate without filtering, but this result should still be filtered using the technique Allen mentioned or even something more sophisticated.

different technique

Instead of sampling based on time, measure the time between pulses.
Use selectable timed interrupt (STI) in your PLC to provide accurate time measurement between pulses or if the pulses are too fast then measure every so many pulses. Feed the the time intervals into a FIFO stack.
Stack should be deep enough to eliminate unwanted flickering on the
display and fast enough to provide reasonable update time.
Average the FIFO stack by using the AVG instruction if available,
else calculate by using math instructions.
FIFO needs to be a sliding window that's always on the move.
This technique will eliminate your current error.

mr Allen Nelson
Speed = (Speed*(1-x) + Meters-per-minute*(x))*100 then
where 100 > x > 0

Use your equation if X is an integer (except that it's / 100, not * 100 ).
Use mine (well, Peter's actually - I stole it from him) if X is a float.

Some one shared this with me

Allen Nelson said:

Use your equation if X is an integer (except that it's / 100, not * 100 ).
Use mine (well, Peter's actually - I stole it from him) if X is a float.

Click to expand...

Now it is yours to share.

A simpler form is Y(n+1) = Y + K * ( X - Y )
where 0 < K < 1 but K should be much closer to 0.
Only one mulitply required.

I'll share this again for the those that want the theory of how to determine what K should be.
Digital Low Pass Filter

You didn't mention the PLC brand. Some have one or more channels that are or can be high speed counters, and many of these have a functin that will give you frequency directly.

If you are going to be doing this by counts over a fixed time period, and you don't need instantaneous updates, you just have to make sure that your time base is such that the number of counts is greater than the resolution needed. For example, if you are getting 20 counts per second, and you time over 10 seconds, you get 200 counts. Even if you are off by one count it may not matter because the error is 1/2%.

Could you take the sum of 4 half-second samples and multiply by 15?

Then you could dump your 5th sample into the 1st again. That way if you vary between 16 and 17 your sample would vary by one instead of four every half second. The only problem is it takes a complete 2 seconds to dump a zero into every integer and show it as completely stopped if the machine isn't running.

Just a novice attempt........

Personally I think the solution he thought of and probably is using is to SLOW down his sample rate (as Allen said) but I think Goody is Goody enuf (pls excuse the pun) to figure out himself. He may have also used an averaging routine but not likely because conditions/rate didnt warrant it.

I misstated that ALLEN said use LONGER time samples, it was STEVE BAILEY...u know how it is ALL YOU PLC PROGRAMMERS LOOK ALIKE TO ME.

Hi,

If you find out the pitch of your sprocket (gap between teeth) you should be able to calculate the meters per minute form the prox pulse counts i.e (every prox count = xMeters)

Jiri Toman's solution is called a moving average, or something like that, I used it in West Africa on a mine for the speed of an Apron feeder that feeds a conveyor belt. If you get the depth of the fifo table, and the rate at which you populate it, just right it works well.

first thinking about averaging So plus pulses - average/100 and display will be 100 times better.
also you can make longer sampletime as display is slow. so just count for 10 seconds. now resolution is much better.
if possible use realtime and not looptime.

In the future, if you need any more conversions done, don't leave your laptop without this little gem of a program:

http://www.mrplc.com/dl/index.php?action=view&view=entry&entryid=82

It's called CONVERT.exe

When you download it, go to "FLOW" that is where the meters/per/minute conversion are, and just about everything else under God's sky you want to convert too...

awesome program!