Maurice,
I know you want to throw-up every time you see a GOSUB but it’s just something I feel comfortable with. Here’s a small program (program 13) I use it to monitor cooling Tower Water temps. The whole reason for the GOSUB is to make sure the error condition still exists after waiting 300 seconds. I have found that my cheap 10k thermistors sometimes throw out short bursts of funky temperatures.
Other than the mere fact that this program has a GOSUB, is there any reason why it would throw a “prgm13 error”??
12 REM THIS CONTROLS THE TOWER AND GARAGE TEMP ALARMS
20 REM FOR HIGH TEMPS OF TOWER AND LOW TEMPS OF GARAGE
420 REM IF TW THEN START TWALARM
430 REM IF GARAGE < 34 THEN START TWALARM
432 IF TWRTEMP > 86 THEN GOSUB 600
440 IF TWRTEMP <= 82 THEN STOP TWALARM
500 END
600 REM THIS STARTS THE ALARM TIMER ROUTINE
610 REM WE WANT TO MAKE SURE THE CONDITION ISNT JUST A BLIP
620 REM SO WE WILL WAIT 5 MINUTES AND CHECK IT AGAIN
650 WAIT 300
660 IF TWRTEMP > 87 AND TWRTEMP < 111 THEN START TWALARM
699 RETURN
Ted
Let us work on emailed alarms and then tend to this.
Or allow me to restructure your program so you don’t need gotos or gosubs. I know its not the response you are after but we have a lot on the go.
Thanks for your response. If you’re willing to take the time to restructure my program, I am certainly willing to implement it. We both want the same thing. To make the T3 as bullet-proof and robust as possible.
And please let Chelsea know that the Faraday cage I built around the T3-LB that’s near the shortwave radio transmitter has virtually eliminated all Bacnet data errors when passing data from one T3 to another. That crazy environment would have been impossible to recreate in your lab.
As for emailing alarms, you are certainly correct in making that a very high priority.
As for the forum, that might be your best achievement. It not only strengthens the T3 community, it helps your company see on no uncertain terms what your priority should be.
Create a new variable to signal the PREALARM state, line 670 keeps track of how long the prealarm state is met and triggers the full alarm state after five minutes. Line 680 turns off the alarm and the prealarm variables when the temperature finally falls below 82.
660 IF TWRTEMP > 87 AND TWRTEMP < 111 THEN START PREALARM
670 IF TIME-ON( PREALARM ) > 0:05:00 THEN START TWALARM
680 TWRTEMP <= 82 THEN STOP TWALARM , STOP PREALARM
Much simpler, right!
Yes this looks a lot more efficient. There are several programs where I could have implemented the TIME-ON function. So I will give this one a go today. Thanks!
