Hour meter programming in Rockwell

Stuwertz

Member
Join Date
Feb 2018
Location
*******
Posts
49
Hi all ,

Good day to everyone.

Can any one suggest how to program for hour meter In Rockwell L72 processors.
I’m using power flux 527 in panel
. I need to know how many hours this drive Run .
 
What I do is have a 6 second timer self reset and on DN I set a OneShot output.

If a motor/pump/fan/conveyor/valve/whatever is on that I want to log run-time I check if the item is on and the OneShot and count up a 'Minute' counter. a count of 10 = 1 minute.

When the minute counter is DN CTU 'OneHour' to 60 and reset the Minute counter.

Keep cascading counters and it will record trillions of hours.

The same 6 second pulse can be used for all items logged.
 
many ways to do this: STI; RTC; etc.


Simplest (least code, not most efficient) is to keep a running total of some regular-in-time event when the flux 527 is running.


The code below monitors the seconds field of the real-time (wall clock), and adds (1/3600)h to the hour meter every time the value changes, when the flux 527 is running.


A knock against this approach is it misses running time when the PLC is off, and it also might reset the value on a power outage.



Alternate approaches: the ADD could be a counter; use the minutes DT[4] instead of seconds.


Using a timer is not ideal for this, as there will be a loss of accuracy at smaller presets, roughly inversely proportional to the timer Preset (a 36s timer that increments hmeter by 0.01 at a time might not be too bad, with an error probably well under 0.1%).


Code:
     flux_527
     running
  -----] [---+---|GSV          |---------+---
             |   |WallClockTime|         |
             |   |LocalDateTime|         |
             |   |DT[0]        |         |
             |                           |
             +---|DTR  |---|ADD      |---+
                 |DT[5]|   |hmeter   |
                 |31   |   |2.7778e-4|
                 |lasts|   |hmeter   |
 
Hi all ,

Good day to everyone.

Can any one suggest how to program for hour meter In Rockwell L72 processors.
I’m using power flux 527 in panel
. I need to know how many hours this drive Run .

These drives have built-in metering (in 10 hour increments) as a readable parameter by explicit messaging.
 
The problem with doing lifetime hour counters in a PLC is that unless you take extra measures to store the accumulated value in non-volatile memory they will very probably be altered by a download.

A few years ago when I built a PLC-controlled system where it was necessary to count runtime for bearing life purposes, I used a relay output on the VFD to run an actual mechanical hour meter.

Jeremy already made the point I was composing my post to make; PowerFlex drives (7 series and 520 series) have a lifetime run meter built in that can be accessed with ordinary Parameter object explicit messaging.
 
Regarding the runtime log in a VFD -



If you want to log the run hours for the drive (not the actual VFD run hours) then the parameter in the VFD would only be good until it had to be replaced. A new VFD will be 0 hours and kill the log.



I work on a waste treatment system for a customer in there shop and they usually have to change a VFD in it at least once every year.
 
Hi,

Attached the simplest way I program an hour meter. The problem arises (as Ken pointed out) when you download a new program the values are overwritten. I still don't know how to solve this issue. What I usually do is to modify the program online. But if I have to download a new program, I copy the current values, then I download the program and finally I modify the downloaded values

Hour Meter.jpg
 
Quick Sanity Check for timer

Whatever you do, the "real" value will ALWAYS lag the value used from a timer that resets itself and makes some sort of incremental change in a counter...no matter the PLC. Timers do not go off at the "zero" time, they go off when the accumulated time exceeds the set point time. Better off to use a long-life timer and compare accumulated value to some fixed value(e.g. 6000 = 6 Sec. in AB world) and increment a 0.1 min interval from there. DO NOT reset timer until the thing is about to roll over. You're still guaranteed to lag "real time" but, at least you won't be adding to this error every 6 seconds.
 
Hi,

Attached the simplest way I program an hour meter. The problem arises (as Ken pointed out) when you download a new program the values are overwritten. I still don't know how to solve this issue. What I usually do is to modify the program online. But if I have to download a new program, I copy the current values, then I download the program and finally I modify the downloaded values

Hi,

Thanks for given an idea for including picture.
 
Whatever you do, the "real" value will ALWAYS lag the value used from a timer that resets itself and makes some sort of incremental change in a counter...no matter the PLC. Timers do not go off at the "zero" time, they go off when the accumulated time exceeds the set point time. Better off to use a long-life timer and compare accumulated value to some fixed value(e.g. 6000 = 6 Sec. in AB world) and increment a 0.1 min interval from there. DO NOT reset timer until the thing is about to roll over. You're still guaranteed to lag "real time" but, at least you won't be adding to this error every 6 seconds.


Where critical accuracy is required I do 1 of 2 things, maybe a combination.


When the PLC is running I check the accuracy of the self-resetting 6 second timer and adjust it so a DN pulse is 6 seconds. That may be the preset is 5.985 or similar.


The second thing is to NOT reset the timer at 6 seconds, Do a compare GEQ T.ACC 6000 and OTE pulse and SUB T.ACC 6000 T.ACC.



This way the timer doesn't lose the DN and reset time loss. If the GEQ 6000 isn't accurate enough I change it to GEQ 5985 and SUB 5985.


But for most applications a self-resetting 6 second timer is good enough. The accuracy of the log would be within ±2% and that would be good for maintenance needs for PM.
 
Where critical accuracy is required I do 1 of 2 things, maybe a combination.


When the PLC is running I check the accuracy of the self-resetting 6 second timer and adjust it so a DN pulse is 6 seconds. That may be the preset is 5.985 or similar.


The second thing is to NOT reset the timer at 6 seconds, Do a compare GEQ T.ACC 6000 and OTE pulse and SUB T.ACC 6000 T.ACC.



This way the timer doesn't lose the DN and reset time loss. If the GEQ 6000 isn't accurate enough I change it to GEQ 5985 and SUB 5985.


But for most applications a self-resetting 6 second timer is good enough. The accuracy of the log would be within ±2% and that would be good for maintenance needs for PM.

The the thing is the accuracy will always be a -% not +-%. There are 86,400 one-tenth-minutes in a day. A consistent -2% error from a 6 second timer would add up to 2.88 minutes/day...pretty significant cumulative error. Roll the thing over once a day and you lose at worst, a single scan time. All this assumes that timer overall accuracy is 100%.
 
Last edited:
the simplest way I program an hour meter.


Very nice: clean; easy to understand; also provides the raw information for display as HH:MM:SS without any extra ugly arithmetic, which is something missing from my approach.

That said, I think it could be simpler:

  • the one-shot instructions (HM_ONS1; HM_ONS2 on rungs 1 and 2) might be unnecessary:
    • The [RES HM_mSec_Timer], on the lower output branch of Rung 1, will reset the HM_mSec_Timer.DN bit to 0 on the same scan that the latter is set to 1
      • So HM_mSec_Timer.DN is already, in effect, a one-shot
      • Even it that were not the case, CTUs have their own internal rising edge detector (i.e. one-shot)
      • The same reasoning applies to Rung 2 and the reset of the minute counter
  • I see the hour CTU preset is 1000001, but the accumulator will never reach that preset because the GEQ branch on Rung 3 will trigger a reset on hour 1,000,000.
    • Why do it this way, when a preset of 1000000 and using [XIC HM_Hour_Counter.DN] instead of the GEQ, would accomplish the same thing, as well as keep the logic in line with the previous two rungs for clarity?
    • Also, I notice there is not a one-shot here, event though this implements resets similar to Rung 1 and 2, which suggests the previous one-shots were put there for the CTUs.
  • Finally, 1e6h is over 114y: is that GEQ branch even necessary, or has your company found a source of very durable motors;)?
Thank you for posting your code: it is always interesting to learn from the approaches and design choices of others; and please be assured that none of my comments are meant either as destructive criticism or to say it works anything other than perfectly.
 

Similar Topics

B
Does anybody know a way to program in ti505 logic for a hour meter on a pump? We are doing studys on pumps (how long they run for PM's) I was just...
Replies
1
Views
3,959
Hi team, I am setting up my first E200 overload unit. I came across parameter 205 StartsPerHour. The default setting is 2. I presume, the motor...
Replies
2
Views
469
Hello all, I have been tasked with moving a mechanical run hour meter of a pump motor to a panelview. I have a slc 5/04 and an allen bradley PV...
Replies
6
Views
2,655
I am trying to record the run times and on-load times of 3 pumps in TIA Portal as hour meters. I want to monitor these on my HMI. I'm not familiar...
Replies
10
Views
8,561
Hi, I am using GE Fanuc PLC to calculate the Flow rate in cubic meter per hour from pulses output. i.e. Pulses per second. But the method i used...
Replies
10
Views
12,649
Back
Top Bottom