Building Automation Knowledge Base

Issue Can not Add, Delete or copy Individuals. Environment I/NET Seven Cause When the display order is based on the hexadecimal card number, the Add, Delete, and Copy functions become disabled in the Individuals Summary. This is not an issue with the database or password rights   Resolution Choose some other display order to re-enable the Add, Delete and Copy functions. Go to Access > Individuals. If you have multiple Tenants SELECT the respective Tenant From the Individual Summary display select OPTIONS Change the Display order to Individual, Last Name, First Name or Group Name. Do not put it on Card Number (Hexadecimal). This is option disables the Add, Delete and Copy buttons. OK out of the Options editor The Add, Delete and Copy buttons should now be available.

Issue Deleting Last Tenant from a given door in the System Environment I/NET site with Access Control Cause After deleting last tenant from a given door in the System, issue with cause individuals to not gain access Resolution Are you having an issue with individuals not gaining Access to a given door after the last Tenant is deleted from a Mipped 7920 and the SCU? This may have come about after a door was modified and the last Tenant may have been mistakenly deleted by the user. To correct this, a DPU Restore needs to be done to get the Tables realigned again. Once this is done, then access will be granted to the individuals. This will only take place if you are using I/Net Seven rev 2.11 and below. It was addressed in I/Net Seven rev 2.12, so all you have to do is upgrade your system.

Issue How do I time sync my controllers to my workstations? Product Line Andover Continuum Environment Continuum site Cause The workstation will only synchronize its time to the controllers automatically when the controller is reloaded. It is common practice though to have the controller synchronize its time with the workstation on a periodic basis, commonly once a day. Resolution The only way to synchronize time between the Controller and the Workstation is through a Plain English program running the Workstation. This Program only needs to be created in one Workstation. Below is an example of the program as well as how to trigger the program to run. If Minute = 3 then Goto SetTime Else Stop SETTIME: Set NetworkName\LowestNodeCXName\Date to Date Stop E: Stop Note: This program needs to be triggered off the minute system variable. The program is a Fallthru program which resides in the CyberStation. You only need to do the lowest ACCNet Id controller in each Continuum network. Also ensure that the UTC offset has been correctly entered in every Workstation and BACnet device, and that each Network has the correct Time Zone setting.

Issue How do I set up a Continuum system to do automatic log truncation to save database space? Product Line Andover Continuum Environment Continuum Trend logs Cause Database maintenance. Resolution Setting up Automatic Log Truncation with SQL Server and MSDE Database  MSDE Engine For MSDE, you can download the Stand Alone MSDE Database Utilities from Buildings Download Center.  These utilities are capable of automatically truncating the logs, as well making automated backups, checking for low hard drive space, etc.  SQL Server For full SQL Server, you can easily create a scheduled Job. Details are described below.   To create a scheduled Job that will truncate the Continuum logs in the SQL Server: Open up SQL Enterprise Manager  (Note that the SQL Server Agent service must be running in order to create a Job) Highlight the Continuum database From the Menu, select Tools \ Job Scheduling A wizard opens: "Welcome to the Create Job Wizard." Click Next Select Transact-SQL Command,  Click Next For the Database Name, select ContinuumDB (or whatever the name of the DB is) In the large white space for the Transact-SQL Command, cut and paste the code from our web site: ****** Replace 90 with the number of days to maintain in each log ******** delete from accessevent where DATEDIFF(day, timestamp, getdate()) > 90 delete from activityevent where DATEDIFF(day, timestamp, getdate()) > 90 delete from alarmevent where DATEDIFF(day, timestamp, getdate()) > 90 delete from errorevent where DATEDIFF(day, timestamp, getdate()) > 90 Click Next On the next screen, you are asked when you do want to run this job Select "On a recurring basis" and hit the Schedule button On the Schedule page, set up whatever schedule you desire Click OK to close the Schedule Page • Click Next On the Job Notifications screen, you can choose (if you want) any email or net send alerts. This is optional • Click Next In the final page, you are given a summary of the Job you have just created and you can change the name of your Job to anything you want. It might be a good idea to give it a more descriptive name like "Weekly Log Truncation" Click Finish and you are done. You should get a message that the job was created successfully. To verify that the Job is running correctly, you can go to the Enterprise Manager of SQL Server and click on the Management Folder, then expand the SQL Server Agent folder and click on Jobs. On the right-hand pane, you will see a list of created jobs. Scroll down and find the job that you just created. You can get information about the history of the Job, whether it ran successfully or not.

Issue What should I set the Access Server System variable to on Continuum access controllers? Environment CX9200, CX99xx, ACX57xx or CX9702 controller with an ACX780 or ACX700 controller. Access Server, AccessServer Cause Below are the different configurations and what their different AccessServer system variable settings mean. Unlike Infinity when changing the setting in the controllers the controller does not reset. It is best if you set the AccessServer setting to the ACC Net ID of the Primary Access server workstation. This will keep the Access Control system operational should there be any distribution problems. Resolution CX9200, CX99xx,  or CX9702 controller with an ACX780 or ACX700 controller. The CX can stay at the default of it’s own ACC Net ID. In the above configuration the AccessServer variable in the CX is ignored. The AccessServer variable in the ACX controller can be one of the following: AccessServer value set to 0 in the ACX (Default setting).This means that access validation of personnel records will only be done locally in the ACX. If the person is not found in the ACX or the person is denied access locally in the ACX the person will not get in. AccessServer in the ACX controller set to the ACC Net ID of the Primary Access Server workstation (valid values are 191-253). This means that access validation of personnel records will be done locally in the ACX first. If the person is not found in the ACX or if the person is denied access the controller will double check at the workstation to verify whether or not the person is supposed to have access. If the person is also denied access at the workstation then the person will not get in. If the AccessServer value in the ACX controller is set to the ACC Net ID of the parent CX controller it has no effect and is ignored. CX99xxor CX9680 controller with AC1 modules  or ACX57xx. The CX can stay at the default of it’s own ACC Net ID.  AccessServer value set to the CX’s own ACC Net ID (Default). This means that access validation of personnel records will only be done locally in the CX. If the person is not found in the CX or the person is denied access locally in the CX the person will not get in. AccessServer value set to the ACC Net ID of the Primary Access Server workstation (valid values are 191-253). This means that access validation of personnel records will be done locally in the CX first. If the person is not found in the CX or if the person is denied access the controller will double check at the workstation to verify whether or not the person is supposed to have access. If the person is also denied access at the workstation then the person will not get in. AccessServer value set to 0. This is not a valid setting for a CX controller.

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.