Unity Pro Timers running slow?

clehmann

Member
Join Date
Aug 2006
Location
Fort Collins, Colorado
Posts
11
Hi guys, I would have thought this was a simple part of my program, but it seems that things are not going as I would have thought. All I'm doing is attempting to record run hours for various motors in a plant. I'm using a DFB that does all the motor control and includes a recycling 1sec timer that triggers a "count up" block to record seconds, then another for minutes once the seconds reach 60, etc. I recently implemented code to record the total runtime at midnight and compare it with the total runtime from 24 hrs ago to create a daily run hours tag for the operators. To my surprise, motors that were certainly running for 24hrs straight were only showing 23.4 hrs....??? I've since contacted Schneider for some advice, but I thought I'd bounce it off you guys as well. The memory in the PLC is less than half full and the scan times in the processor status are in the 7-9ms range.

I did do a test yesterday where I ran a stopwatch for 5 min and compared it to a motor runtime that had been running the whole time and the PLC only recorded 4m 52s! (2% error consistent with the daily run hrs figure) Has anyone else experienced timers that do not run for the amount of time they claim to? Any idea the source? And how to resolve it?

I'm working with a Schneider Premium PLC with Advantys remote I/O and programming in Unity Pro 4.0.

Thanks to everyone for your thoughts,

Chad
 
This will happen with any plc using this arrangement.
Has to do with scan time and timer. The timer completes but is not reset (and count incremented) until program scans it. So the total time is 1 sec + a portion of the scan time.
Couple of options to fix
1.Use a longer time, then the scan component will have less effect
2.Read system time at start and then again at stop and calculate the difference
3.Set your timer preset to 2 sec, but compare the elapsed time with 1 sec, when elapsed > 1 sec accumulate the elapsed time and reset timer
 
Thanks for the input guys. I've just heard back from my Schneider tech contact and he is proposing using the system clock and recording start/stop times and calculating the different (as you proposed, Geoff).

Using a FAST section is a great idea, but I don't have one set up and I'd have to take the plant offline to add it in (which could be done, but isn't desirable).

I do like the idea of using a 2sec timer and just resetting it when 1sec has elapsed, but isn't this comparable to the way it is running now? I suppose the pulse to the CTU would happen on schedule, but if it took an extra scan to get the TON to restart, then we're back where we began. Either way I'm intrigued so I might give it a shot as it's the most easily implemented at this point. Otherwise it looks like I'm off to do some TIME math. =/

Thanks again!
 
I do like the idea of using a 2sec timer and just resetting it when 1sec has elapsed, but isn't this comparable to the way it is running now? I suppose the pulse to the CTU would happen on schedule, but if it took an extra scan to get the TON to restart, then we're back where we began. Either way I'm intrigued so I might give it a shot as it's the most easily implemented at this point. Otherwise it looks like I'm off to do some TIME math. =/

Thanks again!

This will work well because the accumulated time will be the actual elapsed time, it wont be truncated to 1 second.
 
OK, got it all sorted.

I did try the 2sec timer with the 1sec elapsed time reset and I got the same errors in timing. I guess the scan time delays just have too much compounding effect on a recycling timer.

Calculating the difference between the start time and stop time, while effective, leaves a bit to be desired as far as determining hours run within a current day. If you went this route, I guess you could have a cyclic evaluation of the time stamp in the case of a motor that doesn't turn off often - or at all.

What I did that is working - using the real-time clock, I compare the RTC seconds to a temp value and if they are not equal and the motor is running, add 1 to seconds AND write the current RTC seconds into the temp value (so they are equal). Then when the RTC.Sec increments again it will add to the CTU, etc. *whew* What a pain! But it's going sweet now.

Thanks for the input!
 
I did try the 2sec timer with the 1sec elapsed time reset and I got the same errors in timing. I guess the scan time delays just have too much compounding effect on a recycling timer.
Just a question, when you used the 2 second timer, did you increment your run timer with 1 second, or did you use the actual contents of the accumulated time register? You need to do the latter for this method to have any chance of being better.
 
I used a GE_TIME block and compared the ET of the TON to T#1S and when it was true, I pulsed the CTU for my "run seconds" tally and also interupted the IN to the TON for one scan (R_TRIG) to start the 2sec timer over.

So I think based on what you are saying, that this isn't going to be any better - I would agree, that's the concern I had in my previous post, but it sounds like I didn't understand the heart of the solution anyway. If you used the accumulated time in the 2 sec timer, how would you get it to reset without having to wait an extra scan? I suppose if this was the only way to do it, you could have two 1 sec timers that ran opposite each other, that way one would have time to clear and reset while the other one is running....?

If you've got further thoughts I'm curious to hear them. Thanks for the followup.
 
I used a GE_TIME block and compared the ET of the TON to T#1S and when it was true, I pulsed the CTU for my "run seconds" tally and also interupted the IN to the TON for one scan (R_TRIG) to start the 2sec timer over.

So I think based on what you are saying, that this isn't going to be any better - I would agree, that's the concern I had in my previous post, but it sounds like I didn't understand the heart of the solution anyway. If you used the accumulated time in the 2 sec timer, how would you get it to reset without having to wait an extra scan? I suppose if this was the only way to do it, you could have two 1 sec timers that ran opposite each other, that way one would have time to clear and reset while the other one is running....?

If you've got further thoughts I'm curious to hear them. Thanks for the followup.

The way i would try to do this, and i have done it in other plc's, is whenever the ET is greater than 1000 (ie 1 second), increment your run seconds counter, and then subtract 1000 from the ET. This means you would never have to reset the timer block.
 
OK, yep I see what you mean. I'll certainly keep that in mind if this issue comes up again. Through this I've learned that the RTC is run off of it's own timing crystal rather than the processor scanning, so evaluating based on its increments is a bit more reliable for periodic events.

I've attached the Tech Note that Schneider made up for me. I tried it out and it's a good solution in case somebody wants to give it a try. The only thing that annoys me about it is dealing with a "time" format for the total run hours and trying to get into something useful... but it certainly could be done and might be preferrable depending on what you're doing with the run hours.

Thanks for the discussion, it's been great to have some outside input.

Cheers,
Chad
 

Similar Topics

i have a problem with using timers in unity pro. the scenario is as follows, tank fills to 240 inches then fill stops, starts agitating for 2...
Replies
3
Views
2,161
Hello I have a question for those familiar with Unity Pro. I have a TOF when the rung goes false the Q bit stays set to 1 until the preset time...
Replies
6
Views
3,581
Hello everyone, I am a new member but have visited the forums many times in the past. Currently I am converting a ControlLogix RSLogix 5000...
Replies
7
Views
6,881
Hi everyone, My name is Chris and I'm pretty new to PLC programming. I am currently in the midst of trying to teach myself how to program...
Replies
1
Views
8,095
Hello, I am using Unity pro V15. I have Quantum CPU 671 and Ethernet NOE 77101 configured. I have configured IO scanning on NOE. I have attached...
Replies
5
Views
137
Back
Top Bottom