What should you do? Count the time between pulses or the pulses per time?

[BryanG]

BryanG kind of has a phase locked loop between the 'Ideal Sample Time' and the 'Actual Sample Time' adjusting the internal counter's setpoint until they agree (the setpoint being the 'measured count for the sample period'). Though he would still have the +/- 1 oscillation problem.

I don't think I have the +/-1 oscillation problem as the interrupt is caused by a high speed counter reaching a set value so there can't be part pulses. It might count 20-20-20-21-20-20-20-20-21-20-20-20-20-21 but the time at the interrupt would be different for a 20 or 21 count. The time used in the flow calculation is the Actual Time caught by the interrupt not the Ideal Time, it won't be perfect and will depend on the speed of the PLC and the resolution of the quickest timer.

That is a very elegant solution. Of course, it's also rather advanced, lol. Were you a computer programmer at one point, because that sounds like an answer a computer programmer would come up with. Or do you just happen to be damn good with PLCs?

It happened because of the circumstances I was given. A customer wanted to compare two liquid flows and raise an alarm within a set period if the ratio went out of band. The speed at which the alarm must occur had to stay the same no matter how fast the product was flowing. The range of flow was large so time between pulses was OK at slow speed but no good a high speed and counting and how many pulses within a set time was no good at the slow speed as the alarm wouldn't have happened quickly enough. Finally they had to use their 'standard' flowmeters so I couldn't boost the pulse count to avoid the +/- I problem.

Bryan

 

[a12bee]

lol, how is it I can understand everything in this thread, yet not understand some base plc concepts?
Sorry, carry on.

 

[m_turk]

You are forgetting one very, if not the most important question, Peter. The usage of the measurement. It will define the aproach to the problem (and that is why I don't think you should use math to decide).
Example:
a)You need a measurement for HMI and logging every minute.. even if you have a fast machine and ideal flow and you can get perfectly accurate reading every second, why would you do that?
b)You need an alarm to stop a process ASAP - you don't care about accuracy in that case - you will allways measure time between two pulses and sound alarm if it is to small..

and so on...

 

[shooter]

In the old days we used a waiting loop and counted pulses in that time and yes we had jitter and this 21 20 story.
Now we take and pulses and time.
wait for pulse
get time
delay 1 second
wait for pulse
get time
speed is pulses divided by time in milliseconds.
jitter is unavoidable with digital systems.
yes i still like analog gauges a lot, with a little mark on it where it should be, and you can see the slightest movement very easy, like a pumppulse. I never saw any plc with this.

 

[Peter Nachtwey]

Still waiting

You are forgetting one very, if not the most important question, Peter.

No, in your examples you don't need fast updates and the method doesn't matter much but all you have done is avoided facing the question because you know it doesn't matter much. However, if you need updates every scan what do you do?

yes i still like analog gauges a lot, with a little mark on it where it should be, and you can see the slightest movement very easy, like a pumppulse. I never saw any plc with this.

PLCs and gages are slow. Pressure sensors are the way to go if one must see transients.

 

[JesperMP]

Re: "still waiting".

This is how much "analysis" I can throw after my method in a hurry.

I only calculate the error that is caused difference between the actual time that a pulse on-off transition happens, and the time that the PLC gets to read it. Other errors are not accounted for.

tScan = Time between scans of the PLC. The PLC scans the inputs and executes its program, including the calculation of the flow. In my case 5-10 ms, worst case 20 ms which I assume hereafter. I do not use hardware interrupts.
tUpdate = Time between executions of the flow calculation. I.e. that the flowrate is updated. In my case 10 seconds.
tSample = Time between the off-on flank of the first impulse, and the off-on flank of the last impulse. In the worst case, there will only be 2 pulses, and they fit in so that only half of tUpdate is used. So worst case tSample = tUpdate / 2.

tError = The error in the reading of the time of an impulse will be evenly distributed withing the 20 ms, so the average is 10 ms.
This we have to double because we have to look at the last impulse too. All the other impulses do not matter. So this error is 20 ms on average. (Actually, I think that it is less. When you combine errors there is some calculations that I have written down somewhere. But lets just assume double the error for simplicity).

The relative error therefore becomes tError / tSample
= 0.02 seconds / (10 seconds / 2) = 0.004 = 0.4%.
This is fine enough for me.
It is possible to vary tScan and tUpdate, and then see what happens with the error.

 

[Peter Nachtwey]

This isn't going quite where I hoped

If the flow or speed only needs to be update only once every 10 seconds then it is easy enough to use the method described by JesperMP.

I think more in terms of computing accurate speeds every 10 milliseconds or scan update. At these short intervals the correct method of estimating speed is much more critical. I can see that most don't think rate updates that often.

JesperMP remembered that sample jitter occurs at both ends of a period. That is good.

 

[BryanG]

If I was looking at getting reading that often I wouldn't use a meter with a pulse output, I would get one with an analogue output

'Teaching your Grandmother to suck eggs alert'
Pulse output is excellent for giving a total volume/distance, but you have to do calculations to get a flow/speed rate. Also you always get historical data for flow/speed, I mean the flow/speed you calculate is always for the last period of measure not the current one.
Analogue output is best for instantaneous flow/speed but you have to do calculations on it to get total volume/distance.

So I think my answer is I wouldn't use either 'time between pulses' or 'pulses in time', I would use an analogue signal.

Bryan

 

[JesperMP]

For sure, my method is a low-cost approach that only work within a certain meassuring range.

In another department of my company, the required update time of some control loops is 2 ms. It is position control, where both position and acceleration is measured with a dedicated analog transducer.

I dont think that we will see anyone attempting accurate flow or speed measurement in a PLC by sensing impulses for updates at 10 ms or less.
This must belong to the land of microcontrollers, counter cards, or other dedicated hardware.
For PLCs, I think that we are beginning to find PLCs that can realistically work with scantimes measured in microseconds. But, do there exist PLCs that have timers in microseconds ? Or interrupts in microseconds ?

 

[Peter Nachtwey]

Using an analog output works but what about the null offset. It is rare that an analog devices offset and scale stay constant over a range of temperatures. Averaging over 10 seconds is fine for process applications but that dodges the problem. This may not be fast enough for many temperature control applications.

There was a recent thread about reading an encoder with 18 pulses per rev spinning at 500 RPM using a Omron PLC. The PLC brand is not important.
These problems happen all the time.

In motion control the scan times are often 1 ms or faster and the feedback is usually positions. The positions must be differentiated to provide velocities. Updating the velocity every 10 or even every 10 milliseconds seconds will not do. The motion control world has this problem worked out.

The derivative gain in a PID is basically a gain that is multiplied on the rate of change in the PV. This means that the derivative gain is multiplied by the error between the SP rate if change and the PV rate of change. If the rate of change can't be computed accurately the derivative gain can do more harm than good yet a properly implement PID often requires the use of the derivative gain.

Have any of you done gearing? When doing gearing you are using the actual position of some input to generate the position, velocity and even the acceleration that the slave must follow instead of using an internally generated perfect position, velocity and acceleration.

Dodging the question does not solve it. It should be relatively simple. There are two curves that show the percent error as function of speed. The time between pulses is a curve that starts relative low in the lower left and rises to the right. The pulses per unit time starts with a large error that decreases as the rate increases. At some point the two curve intersect. That is the point where one should switch between the two methods.

JesperMP at least figured out an error using his method

 

[m_turk]

Dodging the question does not solve it.

To me, it looks like you are dodging the answer, Peter...

The question was, what method to use..
- Jesper said: do both!
- Bryan gave you the optimal function that you can achieve with a plc
- adjust the function to match the use (Ideal Sample time in Bryans function)
- as an alternative, Bryan pointed out to consider analog measurment.


Maybe you should refrase the question, because this one has been answered...

(i do think that you just want us to play with math a little bit and minimize the error function.. so why didn't you ask that? we could.. but you asked something else..)

 

[kamenges]

Originally posted by m_turk:

(i do think that you just want us to play with math a little bit and minimize the error function.. so why didn't you ask that? we could.. but you asked something else..)

I must respectfully disagree with this. In engineering, knowing how to use the tool is not the hard part. Knowing when to use the tool is.

Keith

 

[Peter Nachtwey]

To me, it looks like you are dodging the answer, Peter...

The thread that prompted this is
http://www.plctalk.net/qanda/showthread.php?t=52802&highlight=Omron
Obviously it isn't obvious when to use time between counts or counts per time.

Jesper says use both but why calculate both when one will have a better answer than the other and how do you know which answer is the best?

- Bryan gave you the optimal function that you can achieve with a plc

No way. By definition a Kalman filter minimizes the error and is optimal but usually not practical. Bryan's answer is reasonable for what he needs to do and for the effort he is willing to put into it. I can do much better. I define better as a combination of faster updates,less error and less lag from the true values.

- adjust the function to match the use (Ideal Sample time in Bryans function)

But you are always limited by the sample jitter and the feed back resolution. One can average this out over time if you don't need fast updates but what do you do when fast updates are required. I always advocate getting the highest resolution feedback possible and sampling in hardware. Even then one may need to use advanced techniques to get the best answer.

- as an alternative, Bryan pointed out to consider analog measurement.

That is an excellent answer if you simply need the rate, but what do you do when you are controlling temperature or flow with a PID and the updates must be fast. I have seen lots of posts in the past where people complain about using low pass filters or averaging because the of the lag in the calculated values.

 

[Paul B]

I have kept quiet and I subscribed to this thread the instant I saw it.

 

[Peter Nachtwey]

I have kept quiet and I subscribed to this thread the instant I saw it.

So far all you have seen is resistance to finding the best way.

I have many customers with all sorts of problems. One wanted to compensate for wave motion. Assume the waves have a period of 10 seconds and a amplitude of 1 meter. There are MRUs, motion reference units, that will provide the roll, pitch and heave every 10 milliseconds. I can tell you that isn't fast enough for a motion controller that runs much faster. The trick is to estimate position, velocity and acceleration every millisecond from a device that updates every 10 ms. The idea is to keep a platform or crane at a constant attitude as the waves moves the platform or crane on the platform. Most are struggling with computing rate or the first derivative and can't even think of computing the second derivative.

Most vendors would simply try to sell the motion controller. We do a simulation of the problem and show how we can solve the problem. I simulate the sample jitter, the fee back resolution and the analog noise when analog feedback is used.

I find it distressing that people simply try to find methods that seem to work as opposed to finding the best way to do something. It may be that the best way was never even considered because a lack of education.

Someone must generate the wealth that the AIG people get in bonuses.
You guys should have voted for me for president but Phil deleted that thread.