I couldn’t find any reference to this on the forums, but perhaps I’m just not looking in the right place…
Is there a reason up timers and down timers are only global? Every now and again I run across a scenario where I’d like to use a down timer (because of the convenient timer commands) but I don’t want it to reset / clear out in the event of a code change / re-download.
Hi aec_dan,
Can you give us a little more detail on what you’re trying to do here? Perhaps an example? I’m not clear on what you’re asking here.
However, you can use/reset a global timer without making a code change. For example, if I start a timer in my strategy and let it count up, I might have a button in my HMI to write a value of 0 to that timer (to reset it) and it will count up from there. No code change required.
FYI - when you refer to a “global” variable, to me that means one that’s not in a subroutine. (Variables in subroutines are “local.”)
-OptoMary
Sorry, PAC Control has corrupted my terminology. I’m still thinking in 8.5 terms when Control describes your variables as either “global” or “persistent” in scope, which didn’t make much sense anyway.
What I was wondering why there are no persistent timer variables? If I have an up timer counting and have to re-download the strategy for some reason, the timer will reset. I’m assuming it has something to do with how memory is allocated on the controller when a strategy is started, perhaps?
So far we’ve gotten around this for some time by using timer variables to measure scan time of a chart, and then adding that repeatedly to a persistent variable. Sadly, this prevents us from using some of the more convenient timing commands (start, stop, pause).
I will need a day or three to dig up the old strategy to double check, but from memory, the way we got around this at the hospital is that timers were handled in different ways depending on just how long the timer was…
Short timers (from memory, around 10 minutes or less) were just zeroed out when we did a download. Stuff happens. Eh.
Mid range timers were moved into a persistent variable every time they were checked by their respective logic. In the power up chart those persistent variables were simply moved back into the timers - thus restarting them from where they left off. They were only ever in sub second error. It also meant that we could use the conventional timer commands, start, stop, pause etc.
Long term timers were handled by not using timers. We looked at the current seconds since midnight, and then calculated how many seconds since midnight it would be when the timer was going to expire. This new value was a persistent variable and thus could survive a download.
Hope that helps.
Thanks, Ben. I think I’ll have to take a better look at how we choose to time things (alarm conditions, mostly) in general if I seek to change the way we do it.
Doesn’t the mid-range timer strategy you mention Ben only work for down timers? Up timers just get the preset set at the value you move to them, and you can’t change the value they start from via a command that I know of…
Correct. You cant change them.
Also, keep in mind that we should be looking at using the I/O as much as possible for timers using the ‘start on pulse’ and so on.
The benefit of this is they survive a download with no added code.
I would really like to utilize the start on pulse and start off pulse features, but unfortunately you can’t check if a pulse is currently running from PAC control, so you still need some sort of status flag to let your strategy know you sent the pulse command. Might as well use a timer in the strategy at that point.
I would like to be able to do something like this:
//Start the fan after 30 second delay
if( IsOff(Fan) && PulseTime(Fan) == 0.0 ) then
StartOffPulse(Fan, 30.0);
end if
Without some sort of way to check if the pulse is running, that code won’t work.