Hour meter programming in Rockwell

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




Okay, there are 14400 one-tenth-minutes in a day, and 2% of a day is 2% of 1440 minutes which is 28.8 minutes, and the significance of 2% is context-dependent*, but otherwise I agree with what is said here.



I did some testing on a MicroLogix to quantify the error of different timing methods; see this URL: https://github.com/drbitboy/PLC_2s_lamp_flash; the *_freq.png plots in doc/img** are the most illuminating; this was for flashing a light on and off but I think the results can apply to this thread's topic. Basically, the results are predictable: self-resetting timers run long (cumulatively) by order one scan time (~0.5-1ms); using the RTC and free-running clocks directly, where available, which should be equivalent to not letting a timer complete and resetting the .ACC value, are about an order of magnitude better than that for the RTC, and about two and a half orders of magnitude better for the free-running clock. I was surprised that the STI approach, while better than self-resetting timers, was still over half an order of magnitude worse than the internal clocks' methods. Of course, I was using the free-running clock as my metric, so its absolute accuracy wrt, say, atomic time, is ignored, and that is also probably why it gave the best result.





* two percent on an hour-meter could be either insignificant if it's for scheduling maintenance, or significant it if is for some legal purpose.


** I like that predictable double-hump of the single timer.
 
If you keep the timer running for it's entire life(Preset). The minutes are a simple ACC(Mod 60,000)... one of the simplest instructions a processor can do. Upon rollover, add your Setpoint increment to your accumulated time. Anyway, in the end, very long term timers are far more accurate for accumulation than a short-term timer. Done bits are inaccurate...they always lag. Accumulators are the best accuracy available.
 
Could you clarify how to do the timer in effective way.


I think chantecler's method is the most clear, and although it probably does not need the one-shots or the GEQ, it is perfectly functional.


As noted by Aabeck, to get the highest accuracy, chantecler's HM_mSec_Timer.PRE value will likely be something other than 60,000, but the actual value to use would need to be determined by calibration on the physical PLC where, and as part of the program within which, it will be run i.e.

  • Set it to 60000 and run it for a day or so against a high-accuracy clock source.
  • Calculate the difference after one day
    • i.e. how many seconds it is off at the end of the day
      • i.e. subtract 86,400* from its total value after exactly 1d
        • i.e. after exactly 86,400s* as measured by the high-accuracy clock.
  • add (60000 x difference / 86400*) to HM_mSec_Timer.PRE; .PRE will be something like 59876

There will still be a temperature-dependent drift calibrating that is left as an exercise for the user;), but I would hope this approach shows adequate due diligence.


* 86,400s, or for however many seconds the calibration is run e.g. you may start it at 16:00:00 one-day and come in the next and look at it at 08:30:13; that would be 16.5h + 13s = 59,413s.
 
Best to define accuracy requirements and engineer the thing from there. There are many way to skin the cat. But if the cat doesn't need to be skinned, exploring the ways to skin is a waste of time...although it is sorta fun. Know what you need before doing what you can do and may not need to do. Simple is best. Question is: What do you need(accuracy-wise)?
 
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.


Definitely not perfect. Thank you for your comments dr.

Jose
 
Allen Bradley doesn’t have an Hour meter block? Wow!


Really? Which PLCs provide an hour-meter built-in?


I always thought of PLCs as providing building blocks like linux, not PCs (or Macintoys for the illiterate;)).


Anyway, Ken provided the right answer: the sum total of time spent on this thread would pay for dozens of real hour-meters. but apparently it is not available in ladder (cf. https://literature.rockwellautomati...[{"num":464,"gen":0},{"name":"XYZ"},52,339,0].




Also, Logix5000 has the TOT instruction, which is the general form of a process of which an hour-meter is one specific application.


Finally, don't forget Heisenberg: https://www.plctalk.net/qanda/showpost.php?p=839002&postcount=25
 
Last edited:
Why do you all make it so complicated:

S2gSezN.png
 
Over the years, we've used one of three techniques to generate an accurate one scan, 1-second pulse.

In any PLC with a real-time clock, this will work:
                         OneSecondPulse
NEQ----------------------OTE
RTC_Second
RTC_Second_LastScan

-------------------------MOV
RTC_Second
RTC_Second_LastScan


In an A-B MicroLogix 1400, we use the STI function file to trigger a program file every 1000 msec. In a Logix 5000 processor, we have a periodic task with a 1000 msec period. Both have just one rung:
                         OneSecondPulseFromPeriodicTask
-------------------------(Latch)


In either case, the main program, which executes at the start of each scan, has this as the first rung:
OneSecondPulseFromPeriodicTask     OneSecondPulse 
-----| |--------------------------------( )
|
| OneSecondPulseFromPeriodicTask
--------(Unlatch)


The OneSecondPulse bit is used as the trigger input to elapsed time meters, flow totalizers and other functions as they occur.

Once upon a time, when we used primitive PLCs without clocks, we used an actual time clock to turn on an input that triggered a daily event, such as starting pumps after the off-peak electric rates started.

Mike
 
Because the best way to get the right answer ...
What he said...

One of my high school* math teachers posted the "Rules of Room 18" on her bulletin board. Two rules that I remember are "Cheat whenever possible" and "Lie to get an answer."

*I would have said "a long time ago in a galaxy far, far away," but that applies to freshman year, and I was in this teacher's classes junior and senior years.

Mike
 
to generate an accurate one scan, 1-second pulse.

In an A-B MicroLogix 1400, we use the STI function file to trigger a program file every 1000 msec. In a Logix 5000 processor, we have a periodic task with a 1000 msec period. Both have just one rung:
                         OneSecondPulseFromPeriodicTask
-------------------------(Latch)


In either case, the main program, which executes at the start of each scan, has this as the first rung:
OneSecondPulseFromPeriodicTask     OneSecondPulse 
-----| |--------------------------------( )
|
| OneSecondPulseFromPeriodicTask
--------(Unlatch)



From the Gilding the Lily Chronicles;), a minor nit about levels of accuracy:


The plot below is a histogram of times between 256 consecutive runs of a 2000ms STI routine that toggles a bit, as measured by counts of the 10kHz free-running clock (100μs period = 0.1ms) of a MicroLogix 1100 in a free-running main routine; the average was ~0.2ms long*, so 0.01%, or possibly 0.02% for a 1000ms pulse, which is plenty accurate for any practical cases, but still with a detectable offset. More details are here; the STI-based program's Project Report is here.


The most accurate way to do this, at least that I found on A-B MicroLogix, would be to put a rising-edge one-shot on bit 12 (4096; one pulse every 0.8192s) or bit 13 (8192; one pulse every 1.6384s) of the 16-bit free-running 10kHz clock. That's not a 1s pulse of course, but for accumulating time that does not matter. That provides 100μs accuracy, excluding the issue of oscillator accuracy, which can be calibrated away if the lily needs even more polish.


* I ran it again just now and got the same average to within 1μs.



sti_1000ms_freq.png
 
I understand the whole idea is to use programming, but hour meters are about $15 or so and only have two wires.

Just buy an hour meter, IMO.
 

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