Building Automation Network and Point Troubleshooting
Find who is commanding a point, use trends to catch hidden faults, test MS/TP and BACnet IP networks, and leave a building automation system better documented.
Table of contents
A building automation system (BAS) can show you almost everything in a building, including things that are not true. A point can be stuck on an old override, a controller can drop off the network every afternoon, or a fan can run all weekend with nobody noticing. This is senior work: finding who is really commanding a point, reading a trend like evidence, and testing a network without guessing. It assumes you can read inputs, outputs and a sequence. Network and program changes need the site's permission, and panels can hold line voltage, so follow lockout rules.
What You Will Be Able to Do
- Work through a BAS fault in a fixed order.
- Find and release an override using the priority array.
- Use trends to catch faults that no alarm reports.
- Test an MS/TP segment with a meter.
- Explain common BACnet IP and Modbus faults.
The Order of Work
- Is the problem real? Confirm it with your own thermometer, meter or eyes.
- Is the input right? Compare the point with a real measurement.
- Is the logic right? Read the sequence and the current state of the program.
- Is the output right? Check for an override, then the signal, then the device.
- Is the network right? If data is stale or a device is offline, look here.
This order keeps you from blaming the network for a stuck damper, or the sensor for a logic error.
Who Is Commanding This Point?
BACnet is the common open protocol in building automation. Many BACnet output points use a priority array, a list of 16 levels. Each level can hold a command, and the highest priority with a value wins. Level 1 is the highest.
| Level | Common use |
|---|---|
| 1 | Manual life safety |
| 2 | Automatic life safety |
| 5 | Critical equipment control |
| 6 | Minimum on and off time |
| 8 | Manual operator |
| 16 | Often the normal program, though it varies |
When no level holds a value, the point falls back to its relinquish default.
This explains a classic fault. Someone turned a fan off at level 8 for a repair three months ago. The program writes "on" at level 16 every day, and the fan stays off. The screen shows the program is calling for the fan, and the fan is off. Nothing has failed.
To fix it, read the priority array and find the level that holds the value. Then release that level. Do not just write a new value on top of it, because that adds a second override.
Which level a tool uses by default varies by vendor, so learn your front end's habits. Do not release a life-safety level or a level you did not set without finding out why it is there.
Hunting Overrides
Make an override report part of every visit. Most front ends can list every point in manual or override. For each one, find out who set it and why. Then release it or record why it stays. An override is often the real root of an energy complaint.
Reading Trends
A trend log records a value over time. Trends catch problems that a single reading cannot, and they work while you are not there.
Set up a trend with care:
- Trend the sensor, setpoint and output together.
- Use a sample time that suits the system: seconds or a minute for fast loops such as duct static, and 5 to 15 minutes for space temperature.
- Cover at least a full occupied and unoccupied cycle, and a weekend if the complaint allows.
- Do not trend so many points so often that you load down the network.
| What the trend shows | What it suggests |
|---|---|
| Fan runs nights and weekends | Schedule error or an override |
| Heating and cooling valves open together | Loops fighting, or overlapping setpoints |
| Damper position changes with no change in mixed air | Stuck damper or slipped linkage |
| Flat line that never moves | Dead sensor or a stale value |
| Regular dip at the same time each day | Sun, a schedule or a process |
| Drop-outs in all points on one trunk | Network fault |
Alarms
An alarm system people ignore is worse than none, because real alarms get lost. Look at what repeats. A nuisance alarm usually needs a delay, a deadband or a repair. Do not disable an alarm to stop the noise. Confirm with the site who gets each alarm, and that the safety alarms still reach a person.
MS/TP Networks
BACnet MS/TP is a two-wire RS-485 bus. Devices pass a token, and each one speaks only when it holds the token.
Common limits and rules:
| Item | Common value |
|---|---|
| Layout | Daisy chain, no stars or long stubs |
| Length | About 4,000 feet at 76,800 baud with suitable cable |
| Devices per segment | About 32 full-load devices. Check transceiver load |
| Termination | About 120 ohms at each physical end |
| Addresses | MAC address unique on the segment |
| Baud rate | The same for all devices |
Use the maker's limits, as they vary. Device instance numbers are different from MAC addresses. A device instance must be unique across the whole BACnet network, and a duplicate can cause strange, intermittent faults even when the two devices sit on different segments.
Testing a Segment With a Meter
With the bus powered down and the trunk disconnected from the router or supervisor, measure resistance between the two data wires.
| Reading | What it suggests |
|---|---|
| About 60 ohms | Two 120-ohm terminators in parallel, which is correct |
| About 120 ohms | One terminator missing, or the bus is open |
| Very high | No terminators, or an open wire |
| About 40 ohms or less | Too many terminators, or a short |
Then find the fault by dividing the bus. Disconnect the segment at the middle, and see which half still works. Keep halving until you find the device or cable section. A single device with a bad transceiver or a reversed wire can bring down a whole segment.
Other common causes are a shield grounded in more than one place, a device set to the wrong baud rate, and a cable run beside a noisy drive.
Warning: Bus wiring can run in panels that hold line voltage. Lock out and verify before you open connections. Do not disconnect a segment that serves critical equipment without telling the site, because those controllers may stop reporting.
BACnet IP and IT Networks
BACnet IP runs on ordinary Ethernet, and it commonly uses UDP port 47808. Faults here often come from network changes, and the BAS team may not hear about them.
| Symptom | Likely cause |
|---|---|
| Devices on another subnet do not appear | BACnet broadcast not crossing subnets, a BBMD needed or misconfigured |
| Device suddenly offline after IT work | Changed switch port, VLAN or IP address |
| Two devices fighting | Duplicate IP address or duplicate device instance |
| Slow graphics, time-outs | Too much polling or trending, overloaded supervisor |
A BBMD, or BACnet broadcast management device, passes BACnet broadcasts between subnets.
Work with the site's IT staff, and never plug into their network without permission. A BAS is also a security target. Use individual logins, change default passwords, keep software patched and use the remote access the site has approved.
Modbus Integrations
Modbus is common on meters, drives and boilers. It has no objects, only numbered registers.
- On serial lines, the address, baud rate and parity must match.
- A value that is wildly wrong often means the wrong register, an off-by-one address, wrong byte order or a missing scale factor.
- A value off by a clean factor of 10 or 100 usually means a scale problem.
Read the device's register map closely. Register numbering differs between makers.
Replacing a Controller
- Back up the program and the settings before anything else.
- Record the address, device instance, baud rate and firmware version.
- Lock out power, and label every wire.
- Install the new controller with the same settings and the correct firmware.
- Download the program and check every point against a real measurement.
- Check that alarms, trends and schedules still work.
Worked Diagnosis
A floor manager says one wing is hot on Monday mornings. The BAS shows all setpoints normal.
- A trend across the weekend shows the wing's air handler off until 9 a.m. on Monday, two hours late.
- The schedule is correct. An override report shows nothing on the fan.
- A trend on the zone controllers shows gaps every night, on one MS/TP trunk.
- Resistance on that trunk reads 120 ohms. One terminator is missing, after a recent office remodel.
- The cable was cut and re-spliced, and the end device was left without its terminator.
The trunk dropped devices, and the optimum start logic lost the zone temperatures it needed. You add the terminator, and confirm 60 ohms. The next Monday's trend is clean. The complaint looked like a schedule problem, and the trend found the real fault.
Leave It Better Than You Found It
- Update the points list, drawings and sequence when something changes.
- Record overrides you released and any you left, with a reason.
- Back up the program after any change, and save the backup where the site can find it.
- Tell the operator what you did, in plain words.
Common Mistakes
| Mistake | What it costs |
|---|---|
| Writing a new value instead of releasing an override | A second hidden command |
| Confusing a MAC address with a device instance | Duplicates that act at random |
| Disabling a nuisance alarm | A real alarm goes unseen |
| Trending too many points too fast | A slow, unreliable network |
| Plugging into the site network without asking | A security incident |
| Changing a program with no backup | No way back |
Check Your Understanding
A point holds no value at any priority level. What does it do? It falls back to its relinquish default.
A trunk reads 35 ohms between its data wires. What are you looking for? Too many terminators, or a short.
Controllers on two different segments both use MAC address 12. Is that a conflict? No. A MAC address only has to be unique on its segment. Device instances must be unique across the network.
A flat trend line has not moved in three days on a space temperature point. What does that suggest? A dead sensor, a stale value or a point in override.
A Modbus value from a boiler shows huge, senseless numbers. What might cause that? The wrong register, an off-by-one address or the wrong byte order. Check the register map.
Key Takeaways
- Work from the real problem to input, logic, output and network.
- In a priority array, level 1 wins, and an old override can beat the program.
- Release overrides rather than writing over them.
- Trends catch faults that alarms and single readings miss.
- A healthy MS/TP segment reads about 60 ohms with two terminators.
- MAC addresses are unique on a segment, and device instances are unique across the network.