Interesting thing about PLC counters and system tics.
Interesting thing about PLC counters and system tics.
(OP)
I was commissioning a PLC based filter-plant controller yesterday and needed to display the instantaneous flow. I had the flow coming in as a pulse per gallon. And was expecting a flow of around 20GPM.
To get the most recent instantaneous value I decided to count how many 10ms periods occurred between rising edges of the flow pulses. Then I would essentially invert that captured count of 10ms periods and multiply by 6000 to get gallons per minute. [(1/10ms counts) x 100 ms/s x 60s/min].
I ran the system and the indicated flow was 20~21GPM. Sweet! Then I looked at the actual flow meter and saw it was doing only 14GPM. Gack! My calculated flow was off by quite a bit.
Reviewing my method:
I was using a _10ms system generated contact to increment a counter.
When a flow pulse rising edge came in I would snatch the counter value into a register.
Then I would reset the counter in the next rung down.
The counter would again start totalizing the 10ms contact closures generated by the PLC.
Then I'd do the above mentioned math and send the result off to the HMI display.
After a whole lot of head scratching I realized that the pulses coming from the water meter were about 4.2 seconds apart. Yet the totals my counter was coming up with were numbers like 286 (10ms periods) which, of course, means 2.89 seconds!! (Hence the greater indicated flow from the inverted result)
I'd always wondered about the asynchronous aspects of a PLC, where it comes by on a scan and checks a system contact at some quasi beat frequency - what happens? Since the scan time was running 5~6ms the system generated _10ms contact was being missed about 1/3 the time. Nasty. Now I know.
There's probably a better way but I don't see it on this relatively simple PLC (CLICK).
To get the most recent instantaneous value I decided to count how many 10ms periods occurred between rising edges of the flow pulses. Then I would essentially invert that captured count of 10ms periods and multiply by 6000 to get gallons per minute. [(1/10ms counts) x 100 ms/s x 60s/min].
I ran the system and the indicated flow was 20~21GPM. Sweet! Then I looked at the actual flow meter and saw it was doing only 14GPM. Gack! My calculated flow was off by quite a bit.
Reviewing my method:
I was using a _10ms system generated contact to increment a counter.
When a flow pulse rising edge came in I would snatch the counter value into a register.
Then I would reset the counter in the next rung down.
The counter would again start totalizing the 10ms contact closures generated by the PLC.
Then I'd do the above mentioned math and send the result off to the HMI display.
After a whole lot of head scratching I realized that the pulses coming from the water meter were about 4.2 seconds apart. Yet the totals my counter was coming up with were numbers like 286 (10ms periods) which, of course, means 2.89 seconds!! (Hence the greater indicated flow from the inverted result)
I'd always wondered about the asynchronous aspects of a PLC, where it comes by on a scan and checks a system contact at some quasi beat frequency - what happens? Since the scan time was running 5~6ms the system generated _10ms contact was being missed about 1/3 the time. Nasty. Now I know.
There's probably a better way but I don't see it on this relatively simple PLC (CLICK).
Keith Cress
kcress - http://www.flaminsystems.com





RE: Interesting thing about PLC counters and system tics.
> receive pulse
> read counter
> zero counter; counter runs on its own
> calculate flow rate
> wait for next pulse
TTFN

FAQ731-376: Eng-Tips.com Forum Policies
Need help writing a question or understanding a reply? forum1529: Translation Assistance for Engineers
RE: Interesting thing about PLC counters and system tics.
John
RE: Interesting thing about PLC counters and system tics.
RE: Interesting thing about PLC counters and system tics.
John2025: !!!! Thanks for pointing out that route to interrupts. Wow. Don't know how I missed that. Maybe since it's a pull down I rarely needed to go to. :I
I see that 'CPU Inputs' requirement thing too. Now that I understand how to use the interrupts on a CLICK it still doesn't solve my problem since with that interrupt I can't read any kind of system free-running timer.
djs: Yes as mentioned by John! Hmmmm Maybe the Timers all keep correct time? That's an idea I will try. I'll have to deal with the timer reaching its terminal value.. Wait, I can reset the timer on every edge, after reading it out. I'll go try that.
I also came up with a way to use the scheme I have running now without the aliasing under-count issue I described happening. You can set the CLICK's scan rate to be fixed! So I can set the scan rate to be 10ms and trigger the existing counter with a _scan contact. I'll try this too.
Keith Cress
kcress - http://www.flaminsystems.com
RE: Interesting thing about PLC counters and system tics.
Or you can use a event driven task that goes true when the event comes true and count it in that task routine. I never liked using counters, add instructions are always full proof.
RE: Interesting thing about PLC counters and system tics.