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

Join Date
Apr 2002
Location
No income tax, no capital gains tax. Freedom!
Posts
8,351
Over the 10+ years I have been monitoring this forum I am amazed that no one has asked this question. It should be obvious that at high pulse rates it is best to count the pulses per unit of time and at low pulse rates it is best to count the time between pulses. Where is the dividing line? What factors does the decision depend on?
 
Do both !

I have a flow measurement where the flow can vary down to a trickle.
In order to measure it reaonably accurate even at low flowrates, and more precise at higher flowrates, I calculate the flow cyclically after a set time period, in my case 10 seconds.
At the first off-on transition I start a timer, at the next off-on transition I increment a counter and I log the time since start, same for the next off-on transitions as long as the cycle time hasnt expired.
When the cycle time expires, I calculate the flow based on the number of pulses and the spent time.
Notice that I do not use the set cycle time in the calculation. I use the time used for measuring the off-on transitions.

In this way I get the best of both "worlds".
I get a reasonably accurate value even if I only have one pair of off-on transitions.
At higher flowrates I get the advantage that many pulses evens out the inaccuracies.
 
No one asks that question because on ones plc is designed to do precision time measurement between high speed events. Some of the high speed counting devices made for plcs will do this for you. For example, when used in rate mode the 1746-HSCE2 will automatically switch between counts per unit time and time between counts when calculating frequency based on the time between counts. It becomes a non-value added discussion if you can't implement the solution.

Keith
 
Assuming you don't have an intelligent counting module I like Jesper's implementation.

Added could be a timer after the end of the first calculation which, if it expires without 2 edges, could raise some type of 'Low Flow' flag.

But going with Peter's question (and he rarely asks one of these without a lengthy discussion of his own in mind) there is a crossing point when the percenatge accuracy for one method crosses the other. This is mainly dependent on maximum update interval allowed and the resolution of any timing measurement. Since our rate calculations on our machine are within a narrow range I haven't developed automatic testing and switch over logic.
 
Good Question Peter
Since even the best flowmeter would have 100:1 turndown would this influence the choice?
I like Jespers idea.
Roy
 
Huh ?

It is always interesting to discuss fundamental stuff.

Anyways, your method costs a counter module. That is what I used to have for that application, but I made the software counter method in stead as a cost-cutting measure. So it added some value in my case.

edit: The real question is at what rate a simple software based counter can work. Obviously in my case I must make certain that the pulses do not come faster than approx 40% of the longest CPU scantime. If this would be a problem, I could start to think about interrupts, but I would probably jump to using a counter module.
 
Last edited:
No one has given an answer

JesperMP said:
Do both !
Fine, but when do you use the speed calculated by the time between pulses or the speed calculated by pulses per time period?

kamenges said:
No one asks that question because on ones plc is designed to do precision time measurement between high speed events.
You know better.

kamenges said:
Some of the high speed counting devices made for plcs will do this for you.
OK, then how do you know when you need a high speed counter?

But going with Peter's question (and he rarely asks one of these without a lengthy discussion of his own in mind)
This thread was motivated by another recent thread.

JesperMP said:
edit: The real question is at what rate a simple software based counter can work.
Yes, that question is related to the original question but still no answer.
 
im doing a project where im counting the time between pulses right now.
I need to determine the the speed at wich a machine travels in meters/minute with only one inductive sensor. It is a paper machine so i need to use the diameter of the cylinder in the calculation.
When the sensor is 0 i enable a counter and count 10ms pulses then when the signal turns 1 i do a oneshot calculation involving the pulses, diameter and timebase.

But i need to trim it more becours the values tend to change even in constant speeds.
 
Yes, that question is related to the original question but still no answer.

With my comparable lack of knowledge, I provide a laymans opinion... From a layman...

Keep it simple stupid! Which method is best you ask? "Well darn it, the counting time between pulses wasn't very accurate, prehaps i'll use the other method"

Over what time period are you spanning if using the counted pulses method? At what point does timing between pulses become inaccurate? What brand of PLC is it?
"It used to be accurate." "Hey, wasn't it after we added those ten PID loops that we started to lose accuracy?"

As stated above, I am a layman, whose knowledge pails painfully incomparison to the previous posters, but would you not agree that due to the copious of amounts variables that influence such a decision of one method or the another that this thread may not come up with a definitive resoloution.

Peter, with the greatest respect, what is your answer to your own orginal question?
 
Last edited:
I use another combined system. I set an Ideal Sample Time and I give an initial Count Set Point to a high speed counter with interrupt. I store the Count and Actual Sample Time at the interrupt. In the next cycle of the PLC, using the Ideal Sample Time and Actual Sample Time I calculate a new set point for the high speed counter to bring the Actual Time closer to the Ideal Sample Time. This method means that as the machine speeds up or slows down I can keep the error as a function of the accuracy of the on-board timer. Also if they have a problem on site they can use whatever pulse/litre flowmeter or pulse per rev encoder they have and the system automatically adjusts itself to get the best reading. If the flow or speed I am measuring varies rapidly then I add some smoothing/averaging to the Pulse Set Point adjustment calculation.

edit:
Also have a watchdog timer so that if the High Speed Counter doesn't reach it set point then a flow/speed calculation is forced.

Bryan
 
Last edited:
JesperMP said:
Do both !
Peter Nachtwey said:
Fine, but when do you use the speed calculated by the time between pulses or the speed calculated by pulses per time period?
If you read my description you will see that I combine the two into one method.
If you measure ONLY the time between pulses, you will get variations between each measurement. Measuring the time will be increasingly inaccurate (in relative terms) as the flowrate increases. You would have to counter that with a low-pass filter.
If you measure ONLY pulses within a fixed time, then you will get quantisation errors (is that the right term ?), because even at a constant flowrate, there will be differences for each sampling. If you have for example 20.2 pulses within a time, then you will measure 20-20-20-21-20-20-20-20-21-20-20-20-20-21 etc. Again, it would require a low-pass filter.
With my method you do not need the low-pass filter.

JesperMP said:
edit: The real question is at what rate a simple software based counter can work.
Peter Nachtwey said:
Yes, that question is related to the original question but still no answer.
I wrote that I must make certain that the pulses do not come faster than approx 40% of the longest CPU scantime. That is the high flowrate treshold for when my approach, or any software based method will work. Otherwise impulses will be lost.
The low flowrate treshold will be defined by the required update rate of the measurement. If have a low update rate (long time between updates) then you can measure very minute flow rates. It is simple. You must have at least one pulse pair to work with.
 
I use another combined system. I set an Ideal Sample Time and I give an initial Count Set Point to a high speed counter with interrupt. I store the Count and Actual Sample Time at the interrupt. In the next cycle of the PLC, using the Ideal Sample Time and Actual Sample Time I calculate a new set point for the high speed counter to bring the Actual Time closer to the Ideal Sample Time. This method means that as the machine speeds up or slows down I can keep the error as a function of the accuracy of the on-board timer. Also if they have a problem on site they can use whatever pulse/litre flowmeter or pulse per rev encoder they have and the system automatically adjusts itself to get the best reading. If the flow or speed I am measuring varies rapidly then I add some smoothing/averaging to the Pulse Set Point adjustment calculation.

edit:
Also have a watchdog timer so that if the High Speed Counter doesn't reach it set point then a flow/speed calculation is forced.

Bryan

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?
 
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 think Jesper's method provides the closer measurement since the actual time (to the accuracy of the time base) for the number of pulses in the sample period (not the sample period time itself) is used to determine the rate. Even if the number of counts in the sample period does the +/- 1 oscillation the time for those pulses varies also giving a consistent measurement.
 
JesperMP said:
If you measure ONLY pulses within a fixed time, then you will get quantisation errors (is that the right term ?), because even at a constant flowrate, there will be differences for each sampling.
That is the right term. When ever you sample analog data and convert it to digital there is quantizing. Sample quantizing makes what should be like a linear ramp look like a stair step response. The finer the resolution the smaller the 'steps' are and the closer it approximates the linear ramp.

If you have for example 20.2 pulses within a time, then you will measure 20-20-20-21-20-20-20-20-21-20-20-20-20-21 etc. Again, it would require a low-pass filter.
With my method you do not need the low-pass filter.
You are assuming that you can measure the time between two events and that your sample time is arriving a constant intervals. News flash everybody. There are times when interrupts are turned off. Interrupts do not happen at equal intervals but that is another thread.

Bryan G's method is good but doesn't answer the question. Both Bryan G's and JesperMP's method rely on sampling over time or many counts to reduce sample error. Basically he is measuring the time between many pulses.

I do simulations on this topic. I use linear ramps and sine waves as the ideal velocity. I add two types of 'noise'. One is the quantizing error, the other is sample jitter. In our FPGAs the sample jitter is in the nanosecond range but for a PLC it is much different.

resolution:=0.0001;
jitter:=0.0000000001
y(t)= Trunc(v(t+rnorm(jitter,0),resolution)
the t+rnorm(jitter,0) term is the current time plus the sample jitter with an offset 0 and a standard deviation of jitter.
The Trunc( ,resolution) term adds the quantizing.

I am assuming there isn't any true analog noise in the formula above. There is just sample jitter and quantizing.

I think Jesper's method provides the closer measurement since the actual time (to the accuracy of the time base) for the number of pulses in the sample period (not the sample period time itself) is used to determine the rate.
Show me/us the numbers.

Keith is right about really needing hardware to do this right. If you sample by time then how do you know the next count is about to occur? If you record time difference over a number of counts you are assuming the time you are latch is the time at which the last count just changed. There will be an error. In JesperMP's example the speed is 20 20 20 20 21 20 20 20 20 21 for a true speed of 20.2. One can compute the standard deviation of error or the maximum error of 21-20.2=0.8.
 

Similar Topics

Hello All. I have a flowmeter with a pulse module. The flowmeter generates one pulse per gallon. I am reading approx. 5GPM. The pulse width is...
Replies
9
Views
7,397
Hi, I am working on automating an industrial fabric shrinkage tester to replace its outdated electronics with a PLC. To get the tank's water level...
Replies
14
Views
502
In a control System, I need to move 3 motors attached to roller in stages with speed of 1 to 2 RPM and the torque of motor should be 8-10 Nm...
Replies
0
Views
816
Hi, I want to build a production line project using a PLC. This is the project page...
Replies
14
Views
2,059
See picture. I want to add a rung (magenta) into the existing code. Can't figure out how to do this. I select a -||- , right? When I drag/drop...
Replies
21
Views
1,701
Back
Top Bottom