Hours run calculation

[Conor 4]

Hi guys, I have written code in a Function Block to calculate run hours on a machine. I am using the following. run_hrs.bmp I never seem to get 24 hours, even if the machine has ran for 24 hours. I always seem to get just under 24. Can someone tell me where I am going wrong Thanks, Conor

[Michael Lloyd 85]

I'm going to guess that it's a scan time thing. I can't see anything wrong with the logic. Try running the result through an ABS block. It will turn 23.8 into 24

[Conor 4]

Hi Michael, I suspected it may be something like that. I wish it was that easy . What happens when there is 23.3 actual run hours. It would round that off too? Thanks Edited 29 Feb 2012 by Conor

[PLCMentor.com 60]

I tend to agree with Michael. One question would be what stops it from going over 24? Possibly the inaccuracy is due to how you stop the accumulation or reset it. If it is a timing issue - what type of task is it in? Possibly you could put this in a fast periodic task and make the problem go away.

[JRoss 84]

Is there a reason the preset of the retentive timer is 86500000 instead of 86400000? Also, what are the data types of your variables? DIV and MUL do various interesting things to the results when you mix integers and reals.

[gbradley 0]

Sounds reasonable maybe the 24 is not really an integer? Based on the numbers in your pic. 8.092316 / 0.33719236 = 23.9991084 The 24 looks suspect.

[b_carlton 61]

Why not just divide by 36000000 instead of the DIV then MULT?

[slcman 9]

Like plcmentor say, use a periodic task. It is the best way to do this type of counter. Set the period to the min resolution you need. In the task you just have to add value to maake it work: Eg period is 0.1sec HundredSecondTag + 1 if hundredsecondtag =10 then second + 1 If second = 60 then minute + 1 And so on...

[TConnolly 13]

Use the TOT instruction and configure it to totalize time instead of using a timer. In the TOT tag configure input at 1.0 and gain at 1.0. Set timebase to 2 to totalize hours. Set enable to 1. Set ProgProgReq to 1. My preference is to place it in a periodic task but it will run just fine in the continuous task. Refer to the instruction set reference manual to learn more about this useful instruction - ie, you can use the targets to trigger maintenance flags or other time based notifications. When you use a timer and counters you miss two full scans plus a portion of a third scan for each interval. A PLC timer is a computer instruction, not a device. Your actual time interval will complete at some point in the middle of a scan. You will loose the elapsed time until the instruction is next executed, then the subsequent scan to reset the timer, and then the scan after that to restart the timer. It may not seem like much but over the course of one day a one second interval timer in a program with a 1msec scan will loose between three and four and a half minutes of time. There are tricks you can do to avoid resetting the timers and loosing the 2 to 3 scan interval, but since you're using FB just use TOT instead. It won't have that problem. Edited 1 Mar 2012 by TConnolly

[Crossbow 295]

I've always just used a timer to time 60 seconds (1 minute) and counter to count those for 60 minutes (1 hour), then another counter to count the hours. The value in my timer is the number of seconds, the first counter minutes, and the second counter hours. So I can display those 3 integers on an HMI. BTW I don't program AB, but the concept should work for any PLC...

[rdrast 3]

Considering every time I even mention it, I get my butt chewed out, I should remain silent, but once again... Don't use bloody timers, interrupt routines, or periodic tasks for measuring accurate time. Use the real time clock in the processor. You have a Logix processor, it has a real time clock built in. Even if you don't set the clock, it times more accurately then any timer function. Let the trashing of me begin anew.

[Conor 4]

Why is it that we can overlook easy things like this. I might try and use a Totalizer in the FB instead, as per TConnolly's post. P.S. Tried this but it doesn't work. Does this not need a REAL input? Thanks guys, I will let you know how I get on Edited 1 Mar 2012 by Conor

[Conor 4]

Can you post an example please

[Shiner 2]

I was going to mention something along these lines. At the start of a process, I sample and record the processor time. At the end I sample it again, then do the math to get the difference and add it to the total run time. There is no incremental loss from scan time or issues about setting up periodic tasks. You may get a slight deviation between actual shutdown and when the scan reads the time, but it is not an accumulating figure.

[JRoss 84]

Never occurred to me to use the RTC for run time calculations, but I definitely will use that in the future! How do you handle power outages in the middle of a run? Is there a way to capture the RTC at the moment of power failure?

[Conor 4]

The 24 hours that I look at is 6 am to 6 am. Will this add some extra calcs when I go through Midnight?

[TConnolly 13]

The Real input is fixed at 1.0. Open the TOT tag and enter 1.0 for the .IN element of the tag. Same for the other values I listed. The result is a real indicating how many hours have elapsed.

[daba 4]

rdrast makes a convincing shout for using the internal RTC for timing in your process, and yes, undisturbed, it provides the most accuracy, even if it is not set to today's date/time. but consider what might happen to your process values if... 1. Twice a year someone resets the clock for DST 2. You are accumulating "Run Time" for a process, a pump, a sequence, or whatever - what happens if the processor is powered-off for a time ? The process, sequence, or whatever, doesn't proceed, but the processors clock does !! sometimes you just have to use the timing instructions provided, even though they are not microsecond accurate. "Horses for Courses"

[daba 4]

I really don't think "measuring accurate time" is important for an "Hours Run" situation. If it's a few milli or micro seconds wrong, it's not important I think you make valid points about timing with accuracy, and i teach it all, but sometimes the instructional timing is good enough. Edited 2 Mar 2012 by daba

[daba 4]

Before I get asked for an example, I'll provide one - this from a CIP (Cleen-In-Place) process.... Functional Spec says "Circulate Hot Caustic solution for 25 minutes" 1 minute into that process, the power goes off.... 2 hours later the power is restored. We can get the "hot caustic solution" back to strength and temperature as needed... But we CANNOT recover the ABSOLUTE TIME lost !! Using the PLC's RTC would say we have finished the CIP stage. A good systems engineer needs to know when to use absolute time (the inbuilt clock), and elapsed time (timing functions), and how much accuracy is required.

[Conor 4]

If I was to add a new periodic Task, what settings should I use for it? I have never set one up before

[daba 4]

You make the periodic task run at whatever suits the application. Examples : 1. Send some gathered data to a data-logger - doesn't have to be done rapidly, spec says every 10 seconds, so configure the task to run once every ten seconds. 2. Scan PID instructions for process control - needs to run every 200mS (an example only, I've seen some that update every 5 seconds), so configure a periodic task to run every 200mS 3. Check and record the levels in water supply reservoirs - these things don't change rapidly, every half-hour would be OK. 4. .... run out of ideas...but the main point I'm trying to get over is that a periodic task is code that runs at a rate you determine by configuration to suit the application it is working with. A ControlLogix controller can have up to 32 tasks. 1 Cyclic or Continuous Task (you can only have 1 of these), and 31 others, Periodic, or Event-driven You can if you want, not have a Cyclic/Continuous Task, I've never seen an application that doesn't, but you absolutely don't have to have one. Your periodic tasks can all have different periodic rates, so you can construct chunks of code to do what you want, when you want it. The longest period is 2,000,000 mS, which is just over 33 minutes. Periodic and Event tasks are assigned (edit: no, you assign it) a Priority level. The lower the number, the higher the priority of execution. Give the most critical (i.e. accurate timing) task the highest priority. Lower priority tasks just wait until they are highest priority to execute. Tasks of equal priority are "time-sliced" - both tasks execute simultaneously, the controller shuttles back-and-forth between the tasks, and thus slowing their execution time. Edited 6 Mar 2012 by daba

[Shiner 2]

Isn't there a way to have the processor record on power loss data into a register. I know I heard someone talking about the time it takes between the processor detecting a power loss and the time it shuts down being long enough to store some information. Is this only on a larger power supply that has the capacitence for a bit of ride thru"

[daba 4]

IMHO logging real-times and doing loads of maths is just complicating things, trying to keep track of all these "fragments" of real-time. Surely the PLC's RTO Timer instruction does what you want, simply and effectively. I feel that some are taking the timing of hours-run to too much accuracy. What about the time after you turn off the motor output and it is "spinning down" ? Is the motor "running" or not ? Does it matter ?

[Shiner 2]

I feel that some are taking the timing of hours-run to too much accuracy. What about the time after you turn off the motor output and it is "spinning down" ? Is the motor "running" or not ? Does it matter ?