Sign in to follow this  
Followers 0
bjump

Timer Logic

10 posts in this topic

I'm using RSLogix 500 and I need to time how long a set of conditions has occurred. Basically, I know that if this set of conditions are true, then the machine is standing by. If the machine has been in standby mode for 72 hours, I want to start it up and run it. How could I do this without having to use 9+ timers? I need to stop the timing if the conditions become false. But as long as they are true, I want to time up to 72 hours.

Share this post


Link to post
Share on other sites
To be clear, by 'stop the timing' do you mean 'pause - keep the accumulated time at the current point' or 'reset - set the accumulated time back to zero'?

Share this post


Link to post
Share on other sites
Regardless of the answer to the previous post in general you will create a 1 minute timer. Feed its done (DN) bit to the count input of a counter with a preset of 4320. The done (DN) output of the counter will be your trigger to start. I assume after 72 hours a variance in turn on of a minute would not be too much of a problem. If you want the timer retained when the condition is not true the use an RTO (Retentive Time On) timer. You will have to use a RES command to reset it to zero when needed. If you want the time to reset then use a standard timer (TON) and specifically reset the counter (RES) when the conditions are false.

Share this post


Link to post
Share on other sites
b_carlton has given you an excellent answer for your question, much like my answer would have been. I'll add one thing to consider. If the machine has been "idle" or standby for 72 hours most people will assume it is off. I strongly recommend a "wake up" subroutine that sounds a horn or horns and flashes some lights before the machine actually starts moving again. Don't believe there are any regulations that you must it is just best practice to do so.

Share this post


Link to post
Share on other sites
Thanks for the help! I have just one question. If the "standby" conditions are true for this entire time, how does the 1 minute timer reset when its constantly being triggered by these conditions? Also, the timer would not be retentive. It just needs to reset every time the "standby" conditions are false. Edited by bjump

Share this post


Link to post
Share on other sites
The one second timer only gives you 32,767 seconds...not enough in and of itself. So you either need to trigger a second counter to keep track (already mentioned), or use the real time clock. In the case of the clock, use a CPT instruction to calculate days*24+hours+minutes|60.0+seconds|3600.0 into a floating point value. Let's call this absolute hours. Now trigger a one shot to store the value into a starting value whenever it is TRUE. Then while it is true (not one-shotted) calculate the current absolute hours minus the old (starting) absolute hours. If this number is NEGATIVE, what happened is the the month rolled over. Simply add 720 (30*24) whenever this happens. Now if the difference exceeds 72, then trigger your "start" function. If you use latching/sealing logic then it will continue to run until stopped for some other reason once the trigger occurs. The advantage here is that it is as accurate as the real time clock in the PLC. The clock isn't terribly accurate but it's not too bad. The original suggested logic has a slight problem. The problem is that the "done" bit won't trigger until the NEXT scan. So you get a slight amount of additional time (somewhere between zero and the maximum scan time) every time you wait for a timer done bit. There are three ways to fix it. You can switch to the real time clock as I mentioned above. Second, you can reduce this tendency by making the timer run as long as possible, say timing for 1 hour or even better yet, 8 hours, reducing the number of partial scan times added in a 72 hour period to just 9. Or set the timer much larger than you intend on counting to and manually subtracting the total off the timer accumulator whenever it exceeds your preset limit. Finally with any of the timer-based methods, don't forget that if the conditions go false, make sure to zero the auxiliary counter. A TON instruction will automatically zero itself.

Share this post


Link to post
Share on other sites
I'm sorry that I did not say so in my reply. The one minute timer would be a self resetting timer, one with an NC of its own DN bit as its other condition, besides the 'standby state'. [font="Courier"] Standby Timer/DN ------| |----------|\|---------- Timer .01 6000 [/font] This produces a one-scan pulse of Timer/DN every 1 minute to be used to trigger the counter

Share this post


Link to post
Share on other sites
b_carlton, Thanks a bunch! I never though of using the Done bit to reset the timer. This is very helpful.

Share this post


Link to post
Share on other sites
It is one minute PLUS a part of a scan. This is a classic "free running timer". The reason is pretty obvious. When the conditions go true, the timer starts at zero. On the scan that finally triggers the DN bit, it will take approximately one scan time before the NEXT scan when the timer DN bit is finally triggered, because the timer finally reached the preset (done) value some time between the current scan and the previous scan (or it would have stopped already). This is normally a small number but when you watch the timer value over a period of hours or days, it makes a small but perceptible difference. This doesn't usually matter until you start watching over a long period of time (days) and start noticing that the timer always runs a little long. You will mostly notice this when trying to collect statistical data over a period of a week or so. The longer you make the timer, the smaller the effect. If you want to avoid it, you have to either use the highest resolution timer available and manually manipulate things (by subtracting a value out of the accumulator) or else by giving up on the timers entirely and using the real time clock. Free running timers are great for flashing lights and things where timing is non-critical. If you want a much tighter timing system then beware of the problem with free running timers and don't use them when timing is critical. PLC clocks aren't tremendously accurate either (usually 1 second per day accuracy) so if you truly need accurate timing then it is better relying on a PC or some other external timing source.

Share this post


Link to post
Share on other sites
OK - there's accurate and there's ACCURATE. The free running minute time would average up to 1/2 of a scan long on each timeout. Let's say you have a 10 ms scan time. 1/200th of a second per minute. That's (hold on to your hat!) 21 seconds off in 72 hours!!! If that's a problem then jump through all the other hoops to get some of that 21 seconds back. Otherwise, chill out and take it easy. Since this application appears to be based on a non time sensitive beginning (whenever the system goes into standby) then the end of the 72 hours is probably not incredibly time sensitive either. When super accuracy is needed get yourself an atomic clock.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now
Sign in to follow this  
Followers 0