Building Automation Knowledge Base

Issue What is the difference between the TimeOfLog and TimeStamp columns in an Alarm or AccessEvent listview? Environment Alarm or AccessEvent listview Cause One reason as to why there could be a difference between the two is that the controller did not have communications with the workstation that is logging the events so it buffered the events until such time as it could send them. Another reason is that this is a remote site (RAS) setup and the controller was buffering the events until the controller or workstation requested an update of the alarms and events. Resolution Generally these two timestamps should be close to the same value. The difference between these 2 columns is that the TimeStamp column is actually when the Alarm or Access Event happened, the TimeOfLog column is when these events were logged into the database. 

Issue What does a network switch need to be configured as to connect to a Continuum controller? Environment Network switch CX99xx CX94xx CX92xx CX9702 B4920 BCX series controllers  Cause The configuration depends on what model of controller is being connected to the Ethernet switch. Resolution If you are connecting any of the CX99xx, CX94xx, or CX92xx models of controllers: The switch port needs to be configured as 10 Mb Half duplex. These series controllers only support a 10 Mb connection type and they do not auto detect the connection type.  If you are using any of the newer model controllers like the CX9702, B4920, or BCX series controllers  they support an auto detect connection type of 10/100 Mb connection. These newer controllers will also auto detect the mode for either full or half duplex. An additional feature on the BCX series controllers is that they will also auto detect whether the CAT5 cable being used is a Cross over cable or Straight through cable.

Issue  "Maximum IOU/Infinet controllers reached" when adding an IOU module or Infinet controller. Environment IOU module Infinet controller Cause This generally means exactly what the message states. You have a node limited controller and you have reached the maximum number of nodes. Resolution Edit the controller through Continuum Explorer Click on the options tab. Verify the node counts on the controller on the options tab. If you have reached the maximum number of nodes contact the repair department to get a node upgrade flash file. There is a cost associated with this option.

Issue The time keeps changing between the workstation and the controller. Environment Continuum controllers Cause UTC offsets handle time zone differences between controllers and workstations and may need to be set. Also, a time synchronization program may be required to keep the times the same. Resolution Check the UTC offsets in Cyberstation Explorer. Verify that the Network UTC offset matches the Workstation's UTC offset. Check and verify you have a Time Sync program that synchronizes the time between the workstation and controller.

Issue After running a listview of Personnel records and sorting it by card number, the sort is incorrect. What is the proper procedure to sort Personnel records by Card number? Environment Personnel records Cause The sort is looking at the wrong attribute. Resolution Edit the listview and change your sort to sort based on the attribute NonABACardNumber.

Issue Bit Count not Supported errors in the Active Event view and Event log Environment Active Event view Event log Cause Custom cards will be required if bit count is not supported. Resolution On the door configuration screens make sure the correct card type is selected. (Note: On the door you can select multiple card types). If the card bit count and/or format is not one that is supported natively by the door then it may be necessary to configure a custom card.

Issue Since I have upgraded my CyberStation it seems that my distribution of Personnel records takes a very long time. Also I have noticed that I am having intermittent communication problems with my field bus controllers, why is this happening? Environment Cyberstation Cause This could be caused by the new personnel distribution engine. The new personnel distribution system takes advantage of all the workstations running CyberStation to load balance the distribution so not just one workstation will do this. With this feature added it was also necessary to include settings to adjust to optimize the process. Below are the settings and where they can be found. Resolution Workstation preferences can be found on the Preferences tab of the workstation editor. Workstation preferences Line 19 (Added in the 1.62 Version of CyberStation) Enables and disables the immediate distribution of personnel records from this workstation to controllers on the local area network (LAN). A value of “True” is the default. When this feature is enabled, the workstation inspects the status of the database, and if there are pending personnel distribution transactions, it performs the distributions. When to disable this preference — Typically, you would set this preference to “False” if the workstation is running a lot of applications, such as graphics. If there are several workstations at this site, disabling it on the web server may result in better performance. It also gives you the choice of turning it off for a workstation that is shut down at the end of a day. When to enable this preference — Typically, you would set this preference to “True” for workstations that are dedicated servers (running 24 hours per day and seven days per week, typically in a back room) and for other workstations based on the number of distributions and throughput. The more workstations that are distributing, the faster the distribution occurs. NOTE: If you have too many workstations with the above set to true it could actually slow down the distribution to field bus controllers by overwhelming them from different workstations. This could result in slow or no response from field bus controllers when polling them for information. It also could result in very slow personnel distributions to the field bus controllers. It is recommended not to set this to true for all the workstations but only to set it true for a few. Workstation Preferences Line 20 (Added in the 1.62 Version of CyberStation) Enables and disables the immediate distribution of personnel records from this workstation to controllers on remote access services (RAS) networks. If there are no RAS networks on this site you want to make sure this setting is false, true is the default. This feature should only be set to “True” on workstations that have modems in them used to connect to remote sites. When this feature is enabled, the workstation inspects the status of the database, and if there are pending access distributions, it performs the distributions. General Preferences are found by right-clicking on the Infinity icon in the task tray and selecting General Preferences. General Preferences Line 12 (Added in the 1.73 version of CyberStation) Number of Concurrent Fieldbus Personnel Distributions — This is the number of concurrent personnel distributions that are sent from each workstation to controllers on each field bus network. The default (and minimum) value is 1. Maximum value is 4. This setting, which works in conjunction with setting 13, improves performance by preventing or large numbers of personnel records from flooding field bus controllers. General Preferences Line 13 (Added in the 1.73 version of CyberStation) Time Interval Between Fieldbus Personnel Distributions — This is the amount of time (in milliseconds) that CyberStation waits before it sends another personnel distribution to controllers on the same fieldbus network. The default value is 30. Minimum value is 0. Maximum value is 15000 (15 seconds). This setting, which works in conjunction with setting 12, improves performance by preventing large numbers of records from flooding field bus controllers. It is also useful when there are many workstations performing access distribution. (That is, set it higher if there are many workstations.)

Issue Access Event messages say, "Access Mode No Communications." What does this mean? Environment IOU module Access Server Cause This message means that the controller/IOU module is losing communications with the Access Server (Workstation that is selected as either the Primary or Secondary Access Server). Resolution  Troubleshoot your communications network. Note: When you are in No Communications mode, your personnel records will be validated based on of how you configured the door to validate while in No Communications mode.

Issue Access Event messages are showing that are say, "Access Mode NoDatabase." What does this mean? Environment Access Server Cause This means that the controller cannot get to the personnel database to validate a personnel record.  Resolution Generally this means that the controller has lost its personnel database and needs to be reloaded. Note: When you are in No Database mode your personnel records will be validated based on of how you configured the door to validate while in No Database mode.

Issue Change the LED pattern on card readers Environment Continuum Site Cause How to Change the LED pattern on card readers Resolution On the ACX line of Infinet controllers and also the AC1+ modules you can change the dynamics of the reader LED. The Alternate LED pattern is selected by creating a numeric point whose name is AccessLEDPattern. When this point exists, the Alternate LED pattern will be employed by the access controller. When this point does not exist, the standard LED pattern will be employed. It should be noted that cold-starting or resetting the access controller does not delete or destroy the AccessLEDPattern.

Issue An ACX781 controller or AC1 IOU module keeps locking up and going offline. What can be done to determine why this is happening? Environment ACX781 AC1 IOU module Cause The most common cause of communication problems is electrical noise getting to the controller. Resolution Rule out any kind of hardware failure The most common scenario resulting in electrical noise and controllers going online and offline is that there are no 39v MOVs installed at the door strikes. The reason for needing these MOVs is that when the door strike relay de-energizes it creates a field collapse electrical spike that can travel back down the output wiring to the controller. When this happens, it generally will not damage any of the hardware in the controller but it could cause it to reset or cause its memory to get scrambled. Generally a reset and reload of the controller clears out the problem. It is strongly recommended to put MOVs on all outputs that have relays on them.  Put the MOVs at the end device and not the controller end.

Issue Access Event messages say, "Access Mode Normal." What does this mean? Environment Access Event messages Cause This is generally seen after you see either "Access Mode No Database" or "Access Mode No Communications" messages and the problem has been corrected. Resolution This means the system is running Normally again. Note: When in Normal mode, personnel records will be validated based on how the door is configured to validate while in Normal mode .

Issue What is the difference between Remote validation and Local validation of personnel records? Environment Personnel Records Cause Differences in remote and location validation scenarios. Resolution The difference between Remote and Local validation of personnel records is: Local validation - the personnel records are validated at the controller itself Remote validation - the personnel records are validated at the workstation.

Issue When right clicking on some BACnet objects within Cyberstation (like EventEnrollments and Schedules) and clicking on "Rename", you may receive the following error message when you click Finish: "Cannot set the Name. An attempt has been made to write to a BACnet property with a value that is outside the range of values defined for the property." Environment CyberStation Cause This issue occurs when you specify a Name that does not conform to Alias constraints (16 characters, letters, numbers, period, and underscore only). Resolution Rename the object through its properties page to work around this limitation.

Issue When trying to save a program in the Plain English editor, you receive the message "Infinity controller error: File took too long to open" Environment Plain English editor Cause This is typically caused because the program in the controller is busy executing a command that cannot be interrupted. Resolution A workaround for this issue is: Right-click within the PE panel of the editor Clicking "Configuration..." Set the program state to Disabled, click OK Save your program Repeat the steps above but select Enabled and then click OK

Issue What are the differences between Standard Continuum Import/Export and Continuum BACnet COV? What issues can arise from programming a Bacnet system if you are using the Continuum Import/Export concepts. Product Line Andover Continuum Environment Standard Continuum Import/Export Continuum BACnet COV Cause Information on Continuum import/export and BACnet COV concept to help select the method that meet the environment. Resolution Using standard Continuum import/export where one or more controllers reference a point from another controller creates a relationship in the controllers such that whenever the exported value changes (or exceeds the threshold setting), the point value will be sent out in a broadcast to the network and the controllers that are looking at that point will intercept this single broadcast message and use the new value in their programs. It is very efficient in that no matter how many controllers on the network require a point value from a single controller, only one export message is required. The down side of that is that if there was a network interruption when the message was sent, one or more of the receiving controllers may miss the data update. For critical data exchange, especially if the value rarely changes, such as a schedule point, the use of a refresh program should be used to occasionally retransmit the value by setting the refresh attribute of the point to true. BACnet utilizes Change of Value (COV) data sharing. The main difference here is that for every controller that references a point from another controller, an individual subscription for that point is registered in the exporting controller. So if 10 controllers wanted the same point exported from one controller there would be 10 subscriptions made to that controller. When the point value exceeds the COV Increment (which is equivalent to threshold) there are 10 individual point to point messages sent to the 10 subscribing controllers. The benefit here is that the delivery of the data to all the subscribers is guaranteed. The down side is that there is much more traffic on the network and much more strain put on the exporting controller. Although the data exchange is very reliable, if you were, for instance, to have an MSTP controller possess a global OAT sensor, and 100 other controllers wanted that value exported, every change in value would require 100 point to point messages to send it to the 100 subscribers. MSTP devices default to a Max_Info_Frames of 2, which means that the controller can only deliver 2 of these messages when it gets a chance to talk on the network. The MSTP controller only gets a chance to talk after every other controller on the network has had a chance to, plus the BCX controller which is interlaced between each MSTP controller when using enhanced MSTP. So, if there were 100 MSTP controllers on the network, the exporting controller could only send updates to two of his 100 recipients every 200 token passes on the MSTP network. The data would get backed up, especially if the value was frequently changing, so the updates may never get out. If this amount of data sharing is required in BACnet, the best method to perform it would be to first set the COV Increment to a reasonable number to limit the amount of exports required, and then map the point in one or more BCX level controllers which have much more bandwidth on the network and capability of data sharing and let them export the COV's to the required recipients.

Issue How do I share data between standard Continuum controllers and Continuum BACnet controllers? What communication method is used (COV, Import/export, or point to point)? What problems can I encounter? Product Line Andover Continuum Environment Continuum Controllers (CX9200, CX9400, CX9900,CX9702, CX9680, bCX9640, ACX5720, ACX5740) Continuum BACnet Controllers (b4920, bCX4040) Cause All communication between Continuum controllers and Continuum BACnet controllers is done using point to point protocol. Since BACnet controllers do not support Import/export and Continuum controllers do not support COV, point to point is the only common method to communicate. Resolution The method of programming the data sharing can be the same as standard Continuum programming, however because of the point to point protocol a specific method should be used. Using typical Continuum programming techniques, you would create a mirrored point in the BACnet controller (a BCX for instance). You would then write a PE program in the BCX that mirrors the point, for instance: Line Mirror BCX DataPoint1 = CX/Infinet/DataPoint1 goto Mirror Line E: goto mirror This method would perform a point to point communication every BCX scan and retrieve the data whether it has changed or not. It will create a lot of unnecessary network traffic and slow the scans of both controllers. The line E is necessary because with a point to point communication, the program will disable if the target controller temporarily goes offline. Now consider if you were mirroring many points between the systems for instance you were using the BCX as a BACnet gateway for the Continuum system. That same program would have many points that are being transferred. You would also write multiple programs because of the number of points being polled. The net result of this programming method would be that the entire system would be brought to its knees! Extremely slow scan rates in both controllers because these point to point data requests have to be completed end to end during the scan. Congested Infinet communications because to get the Infinet points we go all the way down the 19.2K Baud Infinet to get the data. The system would just plain no longer function correctly. The only reasonable method to accomplish this type of data transfer would be for the owner of the data that you want to transfer to the other controller sends the data to that controller, and only on an as needed basis, such as a change in its value. Therefore in the scenario described above where you want to mirror points in a BACnet BCX from a Continuum system, you would write the transfer program(s) in the CX controller, and within that program use a local variable for each transferred point to allow you to know if its value has changed since the last transfer, and not retransmit if the value is the same, thereby significantly decreasing network traffic and burden on the system. This method has the added benefit of eliminating the need to clog up the Infinet network, because the program in the CX automatically creates an import/export relationship between the CX and the Infinet controller's points so the normal export broadcast will transfer the data to the CX. One example of the program in the CX to perform the data transfer is as follows: Numeric num1 Line Mirror If num1<>CX/Infinet/datapoint1 then set BCX dataPoint1 to CX/Infinet/datapoint1 num1 = CX/Infinet/datapoint1 endif goto Mirror Line E: if TS>5 then goto Mirror You could also streamline the programs using such methods as creating an InfinityFunction that would be called to minimize the redundant portions of the data comparison and transfer in the programs for multiple point transfers. The function could be named “Exporter” look like this: Arg 1 RemotePoint Arg 2 LocalPoint Arg 3 TestPoint If TestPoint<> LocalPoint then Set RemotePoint to LocalPoint TestPoint= LocalPoint endif Return And now any point that you want to be exported would call this function so the above program would be reduced to: Numeric num1, ..... numX Line Mirror Exporter (BCX dataPoint1, CX/Infinet/datapoint1, num1) . . Exporter (BCX dataPointX, CX/Infinet/datapointX, numX) goto Mirror Line E: if TS>5 then goto mirror After the initial scan when we send all the current data to the BCX, only changed data would be sent thereafter. This syntax would be repeated for each point that you wanted to mirror. This program is setup to be looping. You could create a similar program to be fallthru and trigger it from a minute or seconds system variable. If kept looping it would be recommended to go to a delay line between scans if there was a lot of data transfer going on. There should also be many programs like this if there is a lot of data to be transferred for a couple of reasons. First, if for some reason one of the points could not be transferred due to a temporary comm loss, the program would disable, go to line E and restart from the beginning, not executing any data transfer on the points below the one that failed. Second, if you were transferring many points, you would most likely exceed the maximum file size. Always be cautious as to how much data you try to transfer, and how often. There is no fixed limit per controller, but system performance will degrade proportionally to the speed and amount of data being transferred. As an additional note, it would also be extremely beneficial to put thresholds on the exported points to decrease un-necessary traffic.

Issue Problems and cautions when communicating with TAC (Viconics) Bacnet communicating thermostats Product Line Andover Continuum Environment BACnet Continuum Viconics Cause Need troubleshooting and cautionary information when working with Viconics Stats and Continuum Resolution Integrating SE/Viconics' Devices on an MSTP Network SE7000 Series Room Controllers do not support the COV service but SE8000 do support it. For the SE7000 controllers, special attention should be given to the polling time settings at the Supervisory Controller and Workstation level when using a graphic interface or an application program to read or write to a room controller object. Enhanced MSTP Continuum BACnet devices support enhanced MSTP, which is a proprietary service which allows the BCX level controller to receive the MSTP token between every MSTP controller on the network. This feature allows the BCX to have speedy access to send and retrieve data to any MSTP controller on the network for such things as graphics and data polling. The SE/Viconics stats, as well as any other 3rd party BACnet device, does not support this feature. So a network of stats will perform normal BACnet token passing and for instance, if you had 100 stats on the MSTP, the BCX controller would only be allowed to talk once for every 100 token passes on the network. This will make for slow responses to such things as graphics requests for data. Sending too many requests for data on the network will bottleneck the requests. Graphics Continuum graphics will poll the SE7000 series because they do not support COV. It is very important that you set the request interval on the Thermostat device object editor to a large number such as 5000 ms. This will avoid overwhelming the stat with poll requests. This becomes even more critical in area graphics where a single graphic might poll many devices. If proper poll rate is not respected, devices may be reported offline by saturating the traffic handling capacity of BACnet MSTP without COV subscription. Plain English programs As for the application programming, you should be very careful when programming things such as sending setpoints, or mirroring the Stat's points in the BCX controller for such things as trend logs or graphics polling. You will need to write the setpoint change programs to send only on change, and any data mirroring on a once in a while basis. Otherwise, any read or write request will occur at the controller's scan rate, which might be in hundredths of milliseconds. This can easily bog down a network as single commands can be sent to all ASC devices down the MSTP trunks every hundredths of milliseconds. Programs writing to the devices should have a structure similar to the following: Line setschedule Numeric ScheduleState Schedulestate = Schedule If Schedule = On then MV11 = Occupied If Schedule = Off Then MV11 = Unoccupied goto TestForChange Line TestForChange if Schedule <> Schedulestate then goto setschedule line E if ts>5 then goto setschedule Retries and Timeouts Another thing to look for in a BACnet integration is the Device object of the Supervisory Controller (and the Operator’s Workstation). This object contains the 2 following required properties: Retry Timeout: The Retry Timeout property specifies the time between re-transmissions if the acknowledgement has not been received. When you are experiencing problems with controllers dropping off-line, increasing this value may help. Number of APDU Retries: The Number of APDU Retries property specifies the number of times unsuccessful transmissions will be repeated. If the receiving controller has not received the transmission successfully after this many attempts, no further attempts will be made. For example, if one of the thermostats does not reply to a Supervisory Controller (SC) request, and the SC’s Retry Timeout is set to 2000 msec and the Number of APDU Retries is set to 1, then the SC will send one other request, 2 sec later. If the MSTP device does not reply, it will be considered Off-line by the workstation. So having a Retry Timeout value of 10000 msec and a Number of APDU Retries property set to 3 at the SC level may prevent device from dropping Off-line. These properties should also be changed at the Workstation device editor since the workstation will likely issue requests to any MSTP devices when the graphics are used. For more detailed information on programming for these stats see the installation guides and instruction manuals for these devices.

Issue Creating an object in a BACnet B3 or Infinet controller results in "Invalid Handle ID" or "Unable to insert row in Database Table" error Environment BACnet B3 Infinet controller i2 controller Cause Most commonly this is caused by having too many objects in a B3 or Infinet controller. There is a maximum amount of objects 255, Approximately 50 of them are reserved for system reserved variables and objects, leaving approximately 200 that can be user created in these types of controllers. Resolution One way to determine if this is the problem is to select the controller through Continuum Explorer and get an object count of how many objects are in the controller. If you are seeing roughly 200 objects then try and delete one object to see if you can create a new one. If you can then you have run into the above problem and you need to re-think the programming of the controller.

Issue Error on login to the webClient: "Max user connections has been reached" Environment Continuum webClient Cause webClient support up to 5 users simultaneously. Resolution Make sure the key is enabled for webClient. Make sure all the DCom settings are set correctly. Make sure the IIS and WebClient software was not installed through a remote terminal service type of software. If this was done they will need to uninstall the IIS, WebClient, etc… and then go directly on the server and re-install the software. Make sure the IIS server was not rebooted through a remote terminal service application and then subsequently logged on through remote a terminal service. If this is done they will need to go directly on the IIS server and reboot it while physically on the machine. Verify how many users are actually logged on. Should not display something like 5 / 5. In this case you “have” exceeded the maximum and one user must log off. Users typically run into this on standalone systems where the key is configured for two users and the person shuts down the browser and neglects to log off. Users are NOT disconnected in this case until the 20 minute session timeout occurs. In this state the administrator can close the ACWebServerProxy dialog to disconnect ALL users with one click.