<img height="1" width="1" style="display:none" src="https://www.facebook.com/tr?id=2854636358152850&amp;ev=PageView&amp;noscript=1">

So I was talking with a buddy of mine yesterday on Skype. He and I started discussing communication trunks and the best way to troubleshoot them.

There is nothing more frustrating and difficult then troubleshooting communication trunks in existing buildings.

I know, I know... There are a ton of things that are technically more complex.

BUT

Usually, these things can be reduced to a series of yes or no questions. However, with communication trunks (which we will now call comm trunks to save me from typing...) there are a ton of variables that can affect the comm trunk working.

Before you ever start troubleshooting there are three questions you should ask. If you don't ask these your troubleshooting life will be SOOOO much harder...

Questions to ask

  • Do you have a network riser?
  • Do you know the technical limits of your communication bus?
  • Did all the controllers fail in a row or did they fail randomly?

Do you have a network riser?

A network riser describes how a building automation system network is installed. In an ideal world, this would be 100% accurate but it's usually not.

However, let's take what we can get. You want to get a copy of the network riser.

You will be using this during every step of the troubleshooting process.

Do you know the limits of your communication bus?

BACnet MS/TP trunks can have 3 runs of 5,000 feet and 100 total devices on the comm trunk

but...

That is significantly reduced if you have multiple different controller manufacturers on the bus...

Understanding your trunk limits will help a ton.

Did all the controllers fail in a row or did they fail randomly?

Knowing how the controllers failed will tell you where to start. Did they all fail in a row? Then you are most likely dealing with a physical wiring issue.

If the controllers failed randomly then you are most likely dealing with a voltage or signaling issue brought about by trunk limitations.

It's important to understand how your controllers failed before starting the troubleshooting process!

Troubleshooting Steps:

Assuming that you are within the limits of the protocol and media you are using then follow these steps.

Based on my experience there are 5 troubleshooting steps that when done properly will eliminate most comm trunk issues. These are:

  • Identify the first controller that has failed
  • Replace the comm trunk between the good and bad controller
  • Check to make sure the bad controller's address is not duplicated
  • Check communication speed
  • Replace the controller

Let's dive in!

Identify the first controller that has failed

Pretty simple right? Using your riser diagram move down the comm trunk from the supervisory device to the first controller that failed. Verify that the riser accurately represents the installation and markup as necessary (right address, right location, right termination details)

Replace the comm trunk between the good and bad controller

This one is pretty simply using the existing comm trunk as a pull cable quickly pull a new section of comm trunk and re-terminate the wire. The other option is to use a continuity tester to ohm out the wire "making sure there are no breaks in the wire. You will have to do this for each wire (conductor) inside the wire sheath.

Check to make sure the bad controller's address is not duplicated

A quick way to kill communication on your comm trunk and generally drive your BAS tech crazy is to duplicate hardware addresses. This will make your comm network blink on and off unpredictably. That's why as you move down the riser you need to make sure you have the CORRECT physical address set on each controller.

Your address switch will usually look something like this.

Check communication speed

You may run into this issue depending on the protocol you are using. Now I know a lot of folks have heard use the same bus speed. But do you know why?

The reason why is when a controller communicates on the network it sends its data at a specific speed.

if another controller at a different speed it could end the message it is receiving to quickly or could send messages back onto the network while a controller is communicating

This causes collisions. Collisions are when to data messages run into each other. This causes a communication failure.

This causes a communication failure. Too many failures will cause a network to go down.

Replace the controller

The final solution is to replace the controller. If you've checked all of the items above and you still are having issues then it's time to replace the controller with a new one. If this works then you're golden.

If not then you have even deeper issues. The good news is that 95% of the time these steps work.

Conclusion

So there you have it! You're ready to get troubleshooting!

It's that simple using these 5 steps has solved the majority of my communication trunk issues. What steps do you use to solve your comm trunk issues?

Go down into the comments section right now and share your best troubleshooting step!

Phil Zito

Written by Phil Zito

Want to be a guest on the Podcast?

 

BE A GUEST