Building Automation Knowledge Base

Issue I have upgraded a BAS site to Sigma, but my controllers will not return correct values when using my Lookosn.rec files. Environment Sigma Cause Lookosn.rec are not used with Sigma. Resolution All controller specific tables must be copied to the universal Lookup.rec. These should be in the range of 1000 to 1999. By the use of 'Download Lookup Tables' from System Diagnostics, a local copy of Lookup.rec is sent to the controller.

Issue Renamed SQL server or Single User Cyberstation and now workstation will not connect to the database Environment SQL Server Single User Cyberstation Cause When initially installing the database the computer name is registered as part of the SQL Server/MSDE install. If after the SQL server/MSDE you change the computer name the database will not start up which in turn causes Cyberstation not to start up. Resolution The correct method to change the computer name of the computer running the SQL Server/MSDE database is to: Backup the database Uninstall SQL Server/MSDE Change the computer name Re-install SQL Server/MSDE Re-initialize a blank Continuum database Restore the backup database

Issue Import Export table and alarm delivery troubleshooting procedures for CX, Infinet controllers, and Cyberstation Environment CX Infinet controllers Cyberstation Cause The below troubleshooting outline can be used when trying to determine why point values are not being transferred from one controller to another. Also there is a section to troubleshoot why alarms are not being delivered correctly from the controllers. Resolution Programming import export problems: Open point editors for the source and destination points, verify whether or not the point value is being transferred. If the values are not being transferred then verify the program that is transferring the values is enabled and active. If the program is disabled then go to the runtime tab and determine why the program is disabled. If the program is not disabled then manually run the program, if it is a fall through, and see if the values update. If the values update when manually running the program then the problem is not an import/export problem but a programming problem. If everything with the programming side of things checks out then get a dumb terminal dump of the source and destination controllers. Use the command “Dump All” at the R prompt through dumb terminal. Look at the Import/Export entries in the source controller’s dump file and see if the Import/Export entry is in the dump file in the Import/Export section of the dump file. The format of the entry should look similar to the below. If the Import/Export entry is in the dump file then the problem is not an import/export problem but more than likely a communications problem. Verify the integrity of the Infinet bus and see if there are any problems there. If the bus integrity looks good then the problem could possibly be an intermittent communications problem. If the transfer of these point values are critical then one recommendation would be to add a “Point refresh” program that runs at certain intervals. If the import/export entry is not in the controller dump file then try selecting the first option, “Do not reload attached objects”, in the “Send to Controller” options and reload the controller. What this will do is resend just the Import/Export table down to the controller. Check to see if the point is now sharing correctly via the point editors. If so then the problem was a corrupt Import/Export entry in the controller. If the problem still exists then go to the next step. If the problem is still there then get another dumb terminal dump of the source and destination controllers and verify whether or not the Import/Export entries are in the controller. If the entries are there then review step 5. If the Import/Export entries are not there then run the Import/Export fix up utility against the database and repeat steps 6 through 8. If after going back to steps 6 through 8 the entry is still not there then backup the database and send it to TSD with all the specifics on the points that are not sharing, controller names that owns the points, and programs that transfer the point values. Open the point transfer program and re-save it. Go back to step 7 only.   Alarm Import/Export problems. The below describes how to check to see if an alarm delivery problem is Import/Export table related. Did the alarm get logged into the database? If the alarm did get logged then this is not an Import/Export problem. If the point is still in alarm does the point editor reflect that the point is in alarm? If not then this is not an Import/Export problem. If the point is in alarm and it is not logged check the NewAlarmCount system variable on the CX level controller. If the value of NewAlarmCount is NOT zero then this is not an Import/Export problem. If the point is in alarm and the NewAlarmCount system variable in the CX is zero and the alarm is not logged then this could be an Import/Export problem. If you disable the point and cycle it out of alarm and then back into alarm does the alarm come in? If the alarm comes in then this is more than likely a communications problem and not an Import/Export problem. Check the Continuum error log and see if there are any errors being posted for the delivery if this alarm. Run the ACCTrace utility, from the workstation that is supposed to be logging the alarm, when cycling the point in and out of alarm. Send trace file to TSD for review. To determine which workstation is logging the alarms use the below calculation: The Netcontroller will take it’s own AccNetid and mask it with 63 stripping off the 2 high bits of it’s id leaving a result in the range of 1 to 63. For those of you who are binary mask challenged, NetControllers with Ids between 1 and 63, result is their ID NetControllers with Ids between 64 and 127, result is their ID - 64 (ID range of 0 to 63) NetControllers with Ids between 128 and 190, result is their ID - 128 (ID range of 0 to 62) That result is then added to 190 and that is the ID of the first Workstation to get the Alarm and Log it in the Database. If there is no Workstation with that ID (or the workstation with that ID is offline), the NetController will send the alarm to the Workstation with the next highest ID above the one calculated by the ratcheting algorithm. If no Workstation Ids are higher than the one calculated, the routine will loop around and use the lowest Workstation ID to send to first. Do a dumb terminal dump of the controller that is having the problem. The command to dump it is “Dump All”. Capture this dump file to a text file and check the Import/Export table section of the dump file. The Import/Export section of the dump file should have an entry for the points that have alarms attached to them. The format of the entry is: pointname  to Alarm. If the Import/Export entry is in the dump file then the problem is not an import/export problem but more than likely a communications problem. Verify the integrity of the Infinet bus and see if there are any problems there. If the bus integrity looks good then the problem could possibly be an intermittent communications problem. If the transfer of these point values are critical then one recommendation would be to add a “Point refresh” program that runs at certain intervals. Using the calculation above to determine which workstation is logging the alarm verify that workstation exists in the database. If that workstation does exist in the database make sure that that workstation is pointing to the correct database. We have run into situations where one workstation switches between databases using the same workstation ACCNet ID and IP Address. Doing this will cause problems with alarm and Access Event delivery. If you are doing this kind of installation you must have a unique ACCNet ID and IP address for each database. If the import/export entry is not in the controller dump file then try selecting the first option, “Do not reload attached objects”, in the “Send to Controller” options and reload the controller. What this will do is resend just the Import/Export table down to the controller, it does not reset the controller. Go back and retest the point and see if it goes into alarm and delivers the alarm correctly. If so then the Import/Export entry for the point was corrupted in the controller. If the alarm still is not logged or delivered do step 8 again. If the Import/Export entries are not there then run the Import/Export fix up utility against the database and do steps 10 and 11 again. If the alarm is still not logged then backup the database and send it to TSD with all the specifics on the points that are not sending the alarms. Please include the controller names that owns the point and also what alarm link is not working correctly. Edit the point, remove the alarm attachment and save the point. Then re-edit the point, re-attach the alarm and resave the point. Check and verify that the alarm functions as it should.

Issue No stencils in VisiSat software for the new MicroNet 50 series range Environment MicroNet 50 series range VisiSat Cause An upgrade is required to receive these stencils. Resolution Go to the help menu, and select about VisiSat. If you are running VisiSat 2.0 then you need to request the latest version of VisiSat 2.1. VisiSat 2.0 to VisiSat 2.1 is a free upgrade If you are using VisiSat 1.1 or VisiSat 1.2, then you will need to purchase VisiSat 2.1.

Issue Installing VisiView and VisiSat 2.1 build 14,17 and 137 Environment VisiView and VisiSat 2.1 build 14,17 and 137 Cause Installation Resolution The installation of VisiView automatically installs VisiSat 2.0 If you have installed VisiView, you will need to Uninstall VisiSat 2.0 Then install VisiSat 2.1 If you install VisiSat 2.1 first, When you install VisiView your VisiSat 2.1 installation will be left at VisiSat 2.1 VisiView will not work with VisiSat 2.1 Build 148

Issue Installing MicroNet View software with I/O server installation. Environment MicroNet View software with I/O server Cause Installation Resolution If you have purchased MicroNet View and an NCP/ARCnet or SNP I/O server, only install the MicroNet View software. You should not install the I/O servers from the disk supplied with the I/O server. When MicroNet View installs it also installs both NCP/ARCnet or SNPI/O server software. Installing the I/O servers again can cause a conflict. If you have installed both, then Uninstall all the software and re-install MicroNet View only.

Issue Transferring VisiSat version 2.0 license to Computer running VisiSat 2.1 Product Line Satchwell MicroNet Environment VisiSat 2.1 Cause A computer needing to run VisiSat 2.1 with a transferred license from a computer running VisiSat 2.0. Resolution Install VisiSat 2.0 onto the target machine. Transfer the license. Once you have a licensed copy of VisiSat 2.0, you should Uninstall VisiSat 2.0 and install VisiSat 2.1. Your VisiSat 2.* license will be held in the registry.

Issue What does "Commence Communication" do? Environment LonMaker TAC Vista System Plug-In Cause The menu option in the System Plug-in to commence communication is a common troubleshooting step. Understanding exactly what occurs when this option is selected is beneficial to know when it will be helpful. Resolution The function of "Commence Communication" is to upload the Vista group and configuration parameters to the Vista database. When creating a new network, it is necessary to execute the "Commence Communication" command as the final step of the process.

Issue VisiSat 2.1 project upgrade program Environment VisiSat 2.1 Cause The VisiSat 2.1 upgrade program supplied with VisiSat 2.0 and 2.1, is to upgrade projects originally created in VisiSat 1.1 or 1.2 to the VisiSat 2.* format. VisiSat version 1.* stored all project information under the main project folder. VisiSat 2.* stores all project information and controller configurations under a folder "VisiSat" under the project folder. Resolution Projects must be upgraded and import if originally created in VisiSat 1.*. DO NOT just copy VisiSat 1.* files into a folder named VisiSat under your project folder, then run it in VisiSat 2.*. You will experience problems with your project if this is done. Note: The way VisiSat 2.* stores and accesses the point information is completely different to VisiSat 1.*.  

Issue TAC Vista and Peripheral Software Installation Outline Product Line TAC Vista Environment Microsoft Windows 2000/XP (Microsoft) LonMaker (Echelon) Microsoft Visio PCLTA-10/PCC-10/PCLTA-20/SLTA-10/PCNSI Adobe Acrobat  LNS  lmw31.exe lmw313U1.exe LNS3SP8.EXE LNSSP8U1.EXE HASP device driver h4_hinstall hdd32.exe Privilege Licenser 2.01 Aladdin Privilege Administrator 2.01 taclicense201.exe taclicense202.exe .NET Framework 1.1 TACVistaConfig1.2.0 .NET Framework 1.1 SP1 Microsoft SQL Server (MSDE)2000 SP4 MSXML 4.0 MDAC 2.8 Vista Server IV WorkStation TAC ToolPack 4.X   Cause The correct installation procedure for Vista IV and necessary peripheral software. Resolution Below is an outline that can be followed to install Vista in the proper order. Each "*" denotes a software package followed by the associated files/programs that are included. Depending on your specific application, some of the software may not be needed. For example, a Vista Classic network will not need LonMaker. Call Tech Support if you have any questions concerning the software needed for your application. *Microsoft Windows 2000/XP (Microsoft) *LonMaker (Echelon CD) LNS Utilities: Microsoft Visio, PCLTA-10/PCC-10/PCLTA-20/SLTA-10/PCNSI (only if using an Echelon LNS interface), Adobe Acrobat (if you don't already have it) *Update LonMaker to 3.13 and LNS to 3.08.05 (TAC Extranet) lmw31.exe, lmw313U1.exe, LNS3SP8.EXE, LNSSP8U1.EXE *HASP device driver utility (TAC Extranet) h4_hinstall - MUST Execute from a Command Prompt! or... hdd32.exe if using Windows Server 2003 *Privilege Licenser 2.01 - "taclicense201.exe" or 2.02 - "Privilege Windows XP crash hotfix" (TAC Extranet) *.NET Framework 1.1 (Microsoft) *TACVistaConfig1.2.0 (TAC Extranet) .NET Framework 1.1 SP1, Microsoft SQL Server (MSDE)2000 SP4, MSXML 4.0, MDAC 2.8 (Reboot) At this point you could be prompted to choose which type of Licensing to be used. Select which option is best for you, the Site License (Order Entry Department), 30 Day Demo (TAC Extranet), or Engineering dongle. This will write the appropriate license files to the Privilege License Server. *Vista Server 4.X with WorkStation (TAC Extranet) (Reboot) *TAC ToolPack 4.X (TAC Extranet) If you encounter any errors during the installation process, be sure to make a note of specific errors received so Technical Support can better troubleshoot your issue. A simple way to record errors are to capture a "screenshot" (Ctrl+PrintScnr). The screenshot can then be pasted (Ctrl+V) into Paint a text editor like wordpad for later reference. Note: Beginning 2012, PSS will no longer support the Privilege License System. The Tamfs26 Server will be retired along with TAC License Server software. It would be wise to inform the customer of this important information to plan for future upgrade in the event that their site license has issues.

Issue The actuators or devices terminated off of the V outputs are not working properly. Environment ZBuilder 121 FC/HP controllers Cause The triac outputs on the TAC Xenta 100-series controllers are sinking (switching the ground connection) rather then voltage sourcing (switching the hot connection) except for the Xenta 104-A. Resolution Since most equipment requires voltage sourcing then there are two possible solutions:   For the TAC Xenta 121, use the Zbuilder to reassign the I/O to use a relay output (max 4). This is sufficient for basic applications such as cooling, heating, and fan on a Fan Coil Unit or reversing valve, compressor, fan, and strip heat on a Heat Pump. Install interposing relays on the triac outputs.

Issue Continuum BACnet controllers are sending out incorrect or large amounts of unnecessary COV data on the network. Environment Continuum BACnet controllers Cause The Continuum BACnet controllers cannot be programmed the same as the Non BACnet Continuum controllers when it comes to points that are being exported to other controllers. There are 2 main differences that the programmer must be aware of when programming these exported points. Resolution The first difference to be aware of is that in a Continuum BACnet controller every change of the value of an exported point is immediately sent out at the time of the change regardless of when the point changed within the controller program scan. What this means is that unlike standard continuum programming which latches and exports the final value of a point after the entire controller scan is completed, the Continuum BACnet controller will send out any change it sees during the scan. So if you were toggling a point's value several times within the same program or within multiple programs, all the changes to the value are sent to recipient controllers during the scan, not just the final value. This will cause both incorrect and unnecessary data exports. The second difference is that, in the case of standard Continuum points such as InfinityNumerics and InfinityOutputs, some values can be sent to them that are not reflected directly when the values are translated into BACnet. For example if you had an InfinityNumeric and used it as a binary value in the BACnet world, a program could set it to "On" and later in a program you may perform Boolean logic on it and it would be set to a logical "1", or "true". In the Standard Continuum, these values would be different, however in BACnet, both of these values would be translated to the same value. Because the evaluation of the COV point change is done before we translate it to the BACnet standard we would transmit this as a change of value even though the value transmitted in both cases would be the same. In this case we would transmit the COV during the scan every time we saw this value toggled to what BACnet would think was no change. This would cause unnecessary COV data to be transmitted. The bottom line is that if you, through "Plain English" need your logic to set a value to a Continuum BACnet object more than once during the program scan and it is being exported, you will need to use an intermediate point such as a local variable or an InfinityNumeric to store the changes and only commit the final value to the exported point at the end of the manipulation.

Issue Increase/decrease (floating) outputs on Xenta 121s resynch to 0 at least every 18 hours. Environment Xenta 121-HP Xenta 121-FC Cause Resynchronizing outputs ensures that the actuator is at the same position the programming thinks it is and allows for more accurate control. Resolution Consider forcing Xenta 121s to unoccupied at least every 12 to 16 hours, even in a 24-hour facility. This will allow time for the valve to resynch while the fan is stopped and all dampers are shut. If the valve is resynchronizing during a time when pulling in unconditioned air could take the space outside of the deadband, it's better to control when the resynch happens.

Issue When swiping a card, an Invalid Parity error occurs in the Active Event view or in the Access Event log. Environment Active Event view Access Event log Cause This can either be caused by a reader malfunction or the reader being wired incorrectly. Specifically on the reader wiring they may have swapped the Data and Clock lines. Resolution Try swapping the Data and Clock line on the connector of the controller/IOU module.

Issue What is the pin out for a cable to commission a netcontroller (CX99xx)? Environment CX99xx Cause Need to create a cable to commission a controller. Resolution RJ Connector <- - - - -> 9 Pin RS232 PC Controller Comm3 Pin 1 - DTR <- - - - -> Pin 1 - CXD Pin 2 - CTS <- - - - -> Pin 7 - RTS Pin 3 - CXD <- - - - -> Pin 4 - DTR Pin 4 - RTS <- - - - -> Pin 8 - CTS Pin 5 - GND <- - - - -> Pin 5 - GND Pin 6 - RD <- - - - -> Pin 3 - TD Pin 7 - DSR <- - - - -> Pin 6 - DSR Pin 8 - TD <- - - - -> Pin 2 - RD On the RJ connector for the controller's comm3, Pin 1 is the furthest to the left with the insert clip facing away from you and the gold teeth facing you.

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.