Interesting thing about PLC counters and system tics.

[itsmoked]

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).

Keith Cress
kcress -

http://www.flaminsystems.com

 

[IRstuff]

I'm not sure if I followed what you're doing, but doesn't the PLC have a free-running counter function? Most PICs, I think, have a hardware counter that you can set up to count, and it runs independent of the software loop, so:
> receive pulse
> read counter
> zero counter; counter runs on its own
> calculate flow rate
> wait for next pulse


TTFN
faq731-376

Need help writing a question or understanding a reply? forum1529

 

[John2025]

I think you need to use either the "Pulse Catcher" or "Interrupt" setting under Setup\ CPU Builtin I/O. You have to use the I/O on the actual PLC, not Extended modules so some rewiring might be required. I need to try the same thing on an application where we're trying to detect falling pieces of clear plastic and getting inconsistent results that I thought were from the sensor, but now I'm not so sure.
John

 

[djs]

Does the CLICK support interrupts? If so use them. Another alternative is to generate you own 10 ms clock using a timer. Or use a timer and then calculate the flow from the accumulator value.

 

[itsmoked]

Hi IR; That is exactly what I'm doing. And no the CLICK doesn't have a free running timer that you can directly read. Hence my attempt at creating one...which falls short. (Of counts)

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

 

[controlsdude]

If your counting a pulse that is coming true every 4 seconds then you monitor that input at 2x the rate. If you use timed interrupt task would get it if set for 2 secs. Then one shot that pulse when its true to get your flow. Otherwise, I see you counting a scan time like your doing. This is the only thing I remembered from digital systems class.

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.

 

[John2025]

I didn't know about those other input modes either until you brought up this subject. I have a hard time remembering that Leading Edge to the Click means a change of value from one scan to the next. I think the Pulse Catcher works for the shorter than scan cycle pulses, but djs's idea about the timer sounds like a simpler solution that doesn't require rewiring.