canned logic for run hour meter rslogic500

i need to display machine run time, i was looking for some canned logic for a run hour meter. rslogic 500 to pv 550.

What does canned logic mean?

HJTRBO said:

What does canned logic mean?

Click to expand...

Someone has already done it. Make it once then reuse the logic
when needed. "Cookie Cutter". No need to re-invent the wheel.

Mickey said:

Someone has already done it. Make it once then reuse the logic
when needed. "Cookie Cutter". No need to re-invent the wheel.

Click to expand...

Oh, nice. I don't do that, i'm still an amatuer. I think I might make me a 32,767 day run hour meter with a password reset. Thanks.

Probably get attacked because of scan time and I should use 59 instead of 60 etc. Lol! I also remember reading something here about how much out it is after a day. I'm always up for suggestive improvements...

HJTRBO,
I wasn't able to open your example but from memory if your clock is out by a consistent amount, every 24 hours add or subtract a few seconds.
Roy

Good call.

So whats the story with RS logix 500, I use the latest version 8.1 but I have caught out other blokes with 7.1 Whats with that?

that sounds like a subject of a "new" thread

See

http://www.plctalk.net/qanda/showpost.php?p=290984&postcount=11

Also there are some links at that post on other things to be aware of.

My hour meters are done using one six-second free-running timer in the processor (one timer regardless how many pieces of equipment are involved) and then a typical (using very generic names) rung for a piece of equipment would be "If Motor_Run and Timer.DN ADD Motor_Time 1 Motor_Time". Because the DN bit is set for only one scan, no one-shot is needed. Very clean.

So, if the motor is running, each time the timer goes DN a value of one is added to Motor_Run. This is plenty accurate for our stuff (which starts and stops infrequently). HMI displays the value of Motor_Run (times .1) (with one decimal place) as "Hours & Tenths".

HJTRBO said:

Probably get attacked because of scan time and I should use 59 instead of 60 etc. Lol! I also remember reading something here about how much out it is after a day. I'm always up for suggestive improvements...

Click to expand...

The reason you are off at the end of the day is because you use a conditional rung for your timer. If your PLC has a 20 millisecond scan time and you are resetting it conditionally, then every time its reset you loose up to 40 milliseconds of time between when the timer actually times out, when its reset on the next scan, and then when its restarted on the scan after that. 40 millisceonds dosen't sound like much, but do that once a minute and at the end of a day your time totalizer is off by more than a minute. If you're totalziing time by 100ths of an hour you'll be off by almost two minutes at the end of the day.

When a timer rung first goes true the timer instruction get the current system time reference word and stores the least significant 8 bits in the low order byte of word T4:x.0. The second time the timer instruction is scanned true the system gets the current system time again, subtracts the value in the low byte of T4:x.0, and if the result is greater than the timebase, the accumulator is incremented by the appropriate amount. Then the amount the accumulator is incremented by is also added to the time reference in the low order byte of T4:x.0. The timer keeps accurate time this way. Remember that a timer is a computer instruction that operates on an area of memory, it is not a device, so the actual time period being timed almost always elapses while the processor is doing something else besides running the timer. That means that the amount of actual time elapsed is always slightly longer than the amount of time timed. When the processor gets around to executing the timer instruction again it sees that the time (and then some) has elapsed, so it sets the /DN bit. If you program a self resetting timer, now you will have a full scan elapse before the rung is scanned as false, which resets the timer, and then another full scan elapses at which point the processor sees the timer rung as true again and it restarts the timer. It wont be until the third scan after the timer timed out that it starts comparing elapsed time to the new time reference value stored in in T4:x.0 again.

If you prevent the timer from ever timing out however by directly manipulating the ACC value instead of resetting the timer, you preserve the time base reference value in T4:x.0 and you don't loose the time of two scans from resetting the timer.

See my previous post for the link showing one way to avoid the scan time issue.