The reliability code displayed for each object on the Data List page (see section 12) will indicate BACnet client errors on a point by point basis. The reliability code generally indicates the nature of the problem.
Refer to Appendix J, Hardware Details, for a detailed description of what the LEDs are indicating.
If the BACnet slave device being queried by the gateway returns an error code, or there is simply a problem in communicating with the slave, this will be indicated by the gateway object's reliability code. When reliability code is non-zero, the fault flag is also set. Therefore, the Status Flags indication will typically be "F,T,F,F" any time the reliability code is something other than zero (zero means no errors to report).
Error codes returned by a BACnet slave device are encoded into reliability codes presented by the respective object. Reliability codes pertaining to polling of BACnet slaves (read via the Reliability property) are as follows:
BACnet client read/write timeout (82)
BACnet client received error response from slave (83)
If the object’s reliability indicates code 83, meaning an error code was returned by a remote BACnet device, the actual code returned can be learned by reading the local object’s properties 830 (class) and 831 (code). If an error exists and a reliability code other than 83 is indicated, reading properties 830-831 can also return class 64 (proprietary) and the reliability code+200 (i.e. Modbus illegal function code exception would be class 64, code 266).
Reliability codes will “latch” by default and require that you read the Reliability property in order to reset it to zero, assuming the problem has gone away. Once the non-zero reliability code has been read (by reading the Reliability property), it will reset to zero the next time the object is updated, provided the problem has been resolved.
Since many systems do not automatically read Reliability codes, but do automatically respond to the Fault Status Flag associated with the non-zero reliability code, an auto-reset option is available (on the Device page). When set, reliability codes will return to zero as soon as the problem has been resolved, regardless of whether the non-zero reliability code was ever acknowledged by reading it.
Many systems will report an object as "offline" because its fault status bit is set. It is not actually offline, and is in fact communicating just fine trying to tell you that there is a problem. But many front end systems don't recognize this and blindly claim "offline" as a result of the fault bit in the status property. If you are having this issue as the result of communication errors related to polling other BACnet devices, try setting the Auto-Reset Errors option here. This only applies if you have "Map BACnet Object" checked on one or more Object Map pages.
(a) Is the yellow LED next to the USB cable lit? If not, the PC does not recognize the adapter. Verify installation. Verify that MTX002 shows up as a Port in the Device Manager on your PC. The yellow LED next to the USB cable must be lit before continuing.
(b) Open the configuration tool. Select the port number indicated in the Device Manager. Select a known baud rate, max master setting, and unused Mac address. Click ‘Connect’. Does the log window show “USB is responding”? If not, close the configuration tool, then disconnect and reconnect the USB cable to force a hard reset of the adapter. Retry the ‘Connect’. If you get an error message about the COM port, see that the supercom.dll is found in the same directory as the configuration tool, and recheck the port number on the PC’s Device Manager. You must get “USB is responding” followed by “Ready” or “Auto connected” before continuing.
(c) Is the Token LED on the USB adapter flickering? If not, either there is nothing on the MS/TP network or the network has not recognized the adapter’s reply to poll for master. If the network was online before the adapter was connected, the adapter will wait for the token indefinitely. If no other device on the network grants the token, the adapter will never begin communicating. Failure to get in sync, assuming all devices appear otherwise functional, is most often caused by either a mismatch in baud rate, mismatch in max master setting, or unusable choice of mac address.
(d) Is the PFM (poll for master) LED on the USB adapter nearly solid on? This means the adapter is busy sending out polls for master but not seeing any response. This can be caused by nothing being on the network, a mismatch in baud rate, or other low level communication problems. The normal LED activity when the adapter is connected and in sync with the network will be continuous flickering of the Token LED, usually but not always some periodic flickering of the PFM LED, and occasional flashing of the Data LED. The error LED could also flicker once in a while, but hopefully not often.
NOTE: The two “not really connected” indications you are most likely to see are (i) None of the LEDs next to the terminal block on the adapter ever flash; (ii) The PFM (yellow) LED is always flickering (nearly constant on). It is a somewhat random coincidence whether other devices on the network or the adapter gets ahead in polling. Devices on the MS/TP network always wait for the right opportunity to respond. If they never get that opportunity due to being out of sync as a result of incorrect baud rate, etc, they will appear to be “offline”. Meanwhile, a device polling to look for other devices will constantly just poll because it is not getting any response. Because the device doing the constant polling will generate enough traffic on the line to make the line look busy to other devices, the other devices will never come online.
TROUBLE SHOOTING TIP: If LEDs are not flashing on the MTX002 and/or you cannot discover any device on the Who-Is page, try disconnecting the MTX002 and restarting the configuration tool. Then, instead of selecting a baud rate and clicking Connect, just click Auto Connect. This will search for MS/TP on all possible baud rates, automatically determine the network's Max Master setting, and automatically assign an unused MAC address to the MTX002. When the MTX002 has found MS/TP (after a minute or two), it will say "Auto connected" where it normally just says "Ready". Discovering that the gateway is not set for the baud rate somebody thought it was is a common technical support finding.
The above discussion is focused on getting the USB to MS/TP adapter connected. However, the situation involving one device being out of sync with the network can happen with any device on the network. This is the situation that creates the appearance of a single device refusing to go online, or a single device taking down the network. If a gateway appears to work normally when connected to only the USB adapter, but either refuses to go online or appears to take down the network when connected to a running network, its port settings are out of sync with the rest of the network. It will take a few seconds for the network to re-sync any time a new device is added, but if the network does not return to normal token passing within a reasonable time, the newly added device needs attention.
Trouble shooting the BB3-3101 MS/TP Connection
(a) Does the device have power? A blue LED inside the case, visible through the air vent slots, will be on if there is power present.
(b) Are any LEDs flickering on the front of the BB3-3101? If not, look through the vent holes to see if a red LED near the blue LED is on or blinking. If so, see System Fault Indications below. There should be a green LED near the blue LED that is mostly on, flashing off briefly about once every two seconds.
(c) The Token yellow/green LED on the front of the BB3-3101 should be flickering some color rather constantly. Green indicates token passing, yellow indicates poll for master. Constant yellow (never green) means no other devices are responding. Constant off (both colors) means other devices are generating traffic on the network, but it is not being recognized by the BB3-3101 as anything it can respond to. No token passing activity means either there are no other devices on the network, or there is a low level communications problem, namely one or more communication parameters are mismatched. There could also be a wiring problem. Check for reversed polarity on the data lines. If uncertain, just try swapping them – no physical harm will be done.
The red LED visible inside the BB3-3101 case, viewed through the vent slots, near the blue power LED, is the system fault indicator. It will be on during initial power-up boot mode operation, but should otherwise be off.
Following a device reinitialize upon command from BACnet, the system fault LED will flicker at a very rapid rate for approximately 10 seconds, then turn off (or indicate system fault). The rapid flicker is verification that the restart has occurred.
During normal operation, a watchdog timer is always running to force a soft restart the system in the event of a software hang. Should the system restart as a result of watchdog timeout, the system fault LED will flicker at a very rapid rate for approximately 10 seconds. An intentional software hang followed by watchdog timeout is used to force a restart upon receiving a restart command from BACnet. Therefore the indications are the same. However, if the restart indication is observed without sending the restart command from BACnet, please notify technical support.
System fault indication past the initial few seconds of boot mode followed by possible soft restart indication would consist of the red LED being mostly on, flashing off briefly some number of times, followed by a longer pause remaining on. Count the number of ‘off’ flashes. This is the fault code.
Fault codes are as follows:
(1) Processor hard fault
(2) Unhandled IRQ
(3) Stack overflow
(4) Other OS fault
(5) Resource allocation fail
(6) System configuration checksum error
(7) EEPROM read/write fail
(8) Flash read/write fail
(9) Application checksum error
(10) Invalid application image
(11) Unknown fault
Report any of these to technical support. There are both a primary copy and backup copy of system configuration information. Both need to fail before the fault code will be indicated. These may indicate a hardware failure requiring factory attention. You should really never see any fault codes.