My trouble continues on firmware 52.2. with T3000 of June 12, 2020
For some reason (let’s say for arguments sake that it’s my fault because I don’t have enough RF shielding around Panel 5), my panel 2 can not read some of it’s Bacnet points for temperature. I can see they are blank on the Network Points table. I can reboot Panel 5 but the network points on Panel 2 do not automatically reset. My only option is to reboot panel 2. I hate to do that because it takes my chillers offline. But I did it anyway.
Now the network points table on panel 2 shows the right point#'s but the wrong BACNET iD.
Here is the 2 programs that get data from panel 2 to panel 5:
10 REM PROGRAM TO READ OUTSIDE TEMPS AND SET WATER TEMP
20 ROOFTOP = 108805AI1
30 HUM = 108805AI2 * 10
40 REM ROOFTOP = 5IN1
50 REM HUM = 5IN2 * 10
60 REM REMOVE REMS ON 40+50 AND REM-OUT 20+30 IF DATA GRAB FAILS
80 RUUFTOP = ROOFTOP
100 IF ROOFTOP > 0.210 THEN ROOFTEM = ROOFTOP * 18 + 32 ELSE ROOFTEM = 32
120 IF HUM < 1 THEN HUM = 50
130 DEWPOINT = TEM - ( 100 - HUM ) / 5
140 REM NEXT LINES SET TEM AS AN AVERAGE OF THE ROOF TEMP AND NORTH GARAGE DOOR TEMP
150 REM WITHOUT THIS IT COULD TURN OFF CHILLERS ON BAD TEM READ OR
160 REM WITH THIS IT COULD PREVENT THE FREEZBLOK FROM WORKING
170 REM IF THE DIFF IS TOO GREAT THEY WE RELY ON THE NORTH GARAGE DOOR TEMP
180 REM BECAUSE IT IS HARD-WIRED TO THE CHILLER T3
190 IF ABS ( ROOFTEM - NORTHTEM ) > 10 THEN TEM = NORTHTEM ELSE TEM = ( ROOFTEM + NORTHTEM + ROOFTEM ) / 3
200 IF HUM > 88 THEN HUM = HUM * 0.970
210 REM UTIL = SCANS
300 END
and
10 REM GET TEMPERATURE DATA ONLY FROM THE HOT WATER PANEL
20 REM TWO STYLES BELOW TO GRAB TEMPS FROM HW PANEL
30 REM TOGGLE BETWEEN FULL BACNET STYLE AND PANEL# STYLE BY REM-ING 40&50
40 SOLARTEM = 108805AI6
50 LITELEVL = 108805AI16
60 REM SOLARTEM = 5IN6
70 REM LITELEVL = 5IN16
80 REM IF SOLAR TEMP GAUGE IS CRAZY HOT IT WILL
90 REM SKEW THE AVERAGE TEMP FOR CHILLER SETTINGS
100 IF SOLARTEM - 20 > TEM THEN SOLARTEM = TEM + 20
200 END
You can see I have some lines “rem’d” out so that I can try either method of accessing the data. It was my attempt to find a workaround so I would not have to reboot Panel 2.
After rebooting Panel 2, here is what my Network Points table looks like:
For some reason, it went out and grabbed the correct point#'s but on panel 4! (107607 is panel 4)
There’s got to be some way of straightening out the Bacnet access and resetting the network points without rebooting both T3’s.
Ted
In general I would use the intrinsic method to refer to points from controller to controller.
Looking at your network table here, we can see you are referring to remote points by bacnet instance and object ID, this is OK and is working but it’ll be easier to use the intrinsic method:
10 IF 2IN10 > 50 THEN START FAN1
Where 2IN10 is an input on a remote controller with panel ID=2.
And FAN1 is an output on the local controller.
This is a little more efficient than dealing with the Bacnet instance and checking the object ID and specifying if its an analog or binary object. Here’s an example of that for reference, note that we need to specify AI or Bi whereas with intrinsic method you can just use IN1:
10 IF 107607AI1 > 50 THEN START FAN1
So mainly you will use Bacnet Objects to bring in points on other Bacnet devices like the (Carrier?) chiller controller and I guess your (Temco) outdoor weather station.
While troubleshooting network points there’s no need to reset any controllers to refresh the network tables, they are automatically built and updated as you work. If a remote point is not used any longer on the local controller it will eventually drop out of the table after about thirty seconds.
You can get rid of the two END statements, the end of the program is automatically implied when the last line is executed. They don’t hurt anything but the’re redundant.
I can ask the team to add more info to this table such as the panel name and whether its a
Hope I got your question correctly.