Countdown Timer Logic

[Lancie1]

Sorry, but I don't see those problems in my LogixPro version. It counts down correctly, as long as the orginal Panelview Display times are set to something other than 0.

Check your instructions for errors. (And Alaric said this was trivial. It is only trivial if you get it to work! Trivial for one is rocket science to another...)

 

[Christoff84]

I think he is probably right about the minutes going negative. After some more thought this might be better done using 1 counter for just minutes and the timer for seconds. That way you can use math to calculate the total minutes of the cycle and then more math to display hours/minutes/seconds on the panelview. (Using division)

I find the more trivial you think something is, the more rungs it ends up being in the end.

 

[bikerdude]

Hi,

This is not as easy as it seems at first glance. I tried it myself without much success. I converted the inputs into total seconds with a "CPT" instruction & then used a one minute self reseting timer that increments a counter. The problem I have is converting total seconds back into minutes & hours. The DIV instruction rounds the integer.
Bd

 

[bernie_carlton]

Some AB processors, after a DIV instruction, have the UNROUNDED quotient in one of the math registers and the remainder in the other.

 

[Christoff84]

You can use a CPT instruction to divide remaining minutes by 60, then subtract 0.5,

(((# Minutes Left) | 60) - 0.5)

this should get the rounding right. Remember to use floating point numbers for the math and then move it to integers.

 

[Lancie1]

Christoff
Yes, you are correct, my program has an error. Sorry, FSPT. I will try to come up with one that works.

 

[Lancie1]

Here is revision 3, with no counters, 1 timer, and fewer rungs. I tested the logic extensively this time. It works, as long as total minutes set are less than 60. Normally they would be 59 or less.

 

[FSPT_Tech]

I just tested your revised program Lancie1. Works great! Thanks for the time and help. I appreciate it tremendously! I guess this wasn't as cut and dry as some originally thought. This forum is great for guys like me who need all the help they can get. Thanks to all you helped. Thanks again!

 

[rdrast]

Just one point / question... WHY does everyone insist on using a free-running TIMER as a timebase?

The SLC-5/03 and above have a real time clock. Use that as your time base. Just check for every time it is different from the last value.

NEQ RTC_SECONDS OLD_RTC_SECONDS BST OTE SECONDS_ONESHOT NXB MOV RTC_SECONDS OLD_RTC_SECONDS BND

 

[FSPT_Tech]

You're totally right rdrast. The real-time clock is the way to go for accuracy. You explained this to me once before in a similar thread I started. Others supported your point as well. I should mention that I tested Lancie1’s program using the real-time clock as my time-base for seconds based on what you explained in that previous thread. I used counters for the minutes and hours. This would be more accurate. Thanks for the reminding me of this important point. And thanks everyone for the help and support.

 

[FSPT_Tech]

Sorry that the link I referenced didn't work. Here's the link to the thread I was referring to:

http://www.plctalk.net/qanda/showthread.php?p=195752#post195752

Just wanted to make sure rdrast gets his credit due in full!
Thanks.

 

[Lancie1]

Yes, the built-in clock is more accurate, but regular old timers are accurate enough for most applications. Otherwise why would they be available as a programming command?

Unless you are making a moon shot, or doing motion control, you could be making your program more difficult to understand, without gaining any real benefits.

The degree of accuracy in your program should be dependent on the accuracy required by the process. Many processes are pretty sloppy.

 

[rdrast]

Yes, the built-in clock is more accurate, but regular old timers are accurate enough for most applications. Otherwise why would they be available as a programming command?

Unless you are making a moon shot, or doing motion control, you could be making your program more difficult to understand, without gaining any real benefits.

The degree of accuracy in your program should be dependent on the accuracy required by the process. Many processes are pretty sloppy.

For a short process, I'd agree. But for something where the operator is entering a countdown in "Hours and Minutes", I disagree. I will guarantee that if the expected time differs from the actual time by more than a minute, even over several hours, an operator/supervisor/production engineer will start complaining.

And using a one shot off of the RTC to me seems much simpler than a string of timers and counters anyway.

 

[Lancie1]

As requested by member kiwijohn007, I am reviving this thread long enough to post my last solution in PDF format. So here you go, John. Maybe it is close enough to what you need to give you some ideas.

 

[kiwijohn007]

Thanks for this Lancie1 much appreciated.