Building Automation Knowledge Base

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 The calectro smoke detektor has too long pipe to fit Environment Calectro Smoke detektor Venturi pipe Cause The Venturi pipe is long, but also possible to cut Resolution You can cut the Venturi pipe to size but you must only cut it from the end that does not have the sleeve. See Installation instruction for more information.  

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 Performing database maintenance with Vista 4.5.0 Product Line TAC Vista Environment Vista 4.5.0 SQL Server Cause It is necessary to perform backups for two reasons, first to be able to recover the system in the event of a fatal error and second to be able to manage the size of the database. Resolution Vista has a means of backing up databases on a Vista Server.  It is necessary to perform backups for two reasons, first to be able to recover the system in the event of a fatal error and second to be able to manage the size of the database.  The Vista database probably won’t grow very much after the initial engineering activity but the event and trend log database grows as events are received in Vista.  In many installations maintaining an archive of event data is required so that is another reason for backing up the database.  This paper presents a way to accomplish the backing up of the Event and Trend database and creating an archive file. Before the backup process can be implemented it is first necessary to have a good estimate of the Event and Trend Log traffic anticipated for the installation.  In the Vista 4.3.0 Technical Product Information (TPI), Ref No: C88-1-D43, there is section entitled Strategies for Calculating and Controlling Database Size.  On page 5 the method for determining database size is explained and used in the following example: Right clicking on the $Backup_LDB object in the Server View brings up this dialog.   Note that this example has an Event and Trend database that has reached 1121 (MB) in size.  The default Size Alarm Limit is shown to be 1640 and if the database grows past that size, Vista may not operate reliably. The TPI states on page 4 that events contain on average 2Kb of data.  Combining that value with the expected traffic provides a reasonable estimate of the database expansion rate.  If the installation traffic estimate is 4000 Events and Trend samples per day, the database expands at the rate of 8Mb per day.  If the installation traffic estimate is 10,000, the database expands at the rate of 20Mb per day. A conservative approach would limit the size of the active database to half of the alarm limit.  That means the backup process must be done so that the size does not get to 820Mb.  At 10000 Events and Trend samples per day that value would be reached every 41 days.  Vista is designed to allow Event driven backup operations and the closest choice it offers to the 41 days is once a month so that is what will be chosen. The configuration of backup is done in Vista Workstation by opening the Properties of the Workstation object in the tree.  The first step is to select a location for the backup files to be saved.  In the example shown below it is the folder outlined in red.   The “Max number of files” limits the number of backups that are retained by Vista on the hard drive.  The number chosen here was two (2).  The procedure that is described further down will actually move backup files to new directories which could be a network drive or a CD/DVD rom.  (The latter option requires operator action so it might not be the most desirable especially since backups are usually done at off times when an operator might not be available)  Next the event that is to trigger the backup must be defined.  The configuration of when the backup is done is set on the Log Backup tab of the Vista Server Properties dialog.  In the example shown below the backup is scheduled to occur on the first of every month at 12:40AM. The selection of Event object is made from the options made available by the browse button.     The browse selection brings up the Select dialog from which the selection of Event type and properties is done.  In the following example the selection is Monthly.   Right clicking on the $Event_LDB object opens the properties dialog box to configure the Event_Month object.  The final configuration option is what to do with older records.  Vista will remove Events from the database if you so desire.  The removal does not shrink the database but does make space available for new events to be written without expanding the size of the database.  This is the key to keeping the database from exceeding the Alarm Limit. The Event Log tab provides a way to delete old records from the database.  In the example shown below records older than 30 Days will be deleted after the backup that was done be the Event_Month object has been completed.  This means that each month the backup should have the most recent 30 days of Events and Trend samples.   The final step that can be taken is to also copy the backup file to a server that is backed up or to a CD/DVD Rom. This operation creates an archive in which Event and Trend data is stored.  Windows task scheduler can be used to run a cmd at some time after the backup operation was scheduled.  For the above example schedule it to run a 1:00am on 1 st of each month.  If backing up to a network drive create a folder such as shown below.  J:\Engineering\Vista Event Log BU.  In order for the task scheduler to run it is necessary to setup a user account on the pc that is not related to any actual user.  I added a user to the User group named, vista xcopy dbmgr.  This will be the user account used by the task scheduler.  The Vista backup folder must have modify/write permissions for this user and the folder into which the backup is going to be copied must have Full control.   The command line for this example is shown below: C:\WINDOWS\SYSTEM32\xcopy.exe "C:\Program Files\TAC\TAC Vista 4.5.0\Db2\$bkp" "J:\Vista Event Log BU" /M The Windows task scheduler is configured in the Control Panel, Scheduled Tasks as shown below:   In the Run as: box enter the name of the new User created described above: vista (xcopy dbmgr) Schedule the task to run on the first of each month at 1:00AM.   The backup files can be restored to a Vista Server that is not performing actual site monitoring.  This method is only way the “archived” event and trend data can be viewed as of Vista revision 4.5.0.

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 While attempting to import files to through WorkStation or libraries from the Script Editor, the program crashes with the error message below. It can even happen when doing mass create or mass change, or when adding columns to a list view. "StruxureWare Building Operation has stopped working" Environment Building Operation WorkStation Building Operation Script Editor Cause It has been identified that a program called "F-Secure Key" interferes with other installed programs, and can ultimately leed to other programs crashing. "F-Secure Key" hooks into the Microsoft dll "UIAutomationCore.dll" which is used to idenitfy and manipulate elements in the user interface. If "F-Secure Key" is installed, it can easily be identified, as you will see a blue circle with a key when logging in through WorkStation Resolution Uninstall all "F-Secure Key" related program from "Programs and Features" in the Control Panel on the PC

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 The cooling and heating will not work on the Xenta 121 FC/HP even though the terminal load is building. Product Line TAC Vista Environment ZBuilder Xenta 121 FC/HP Cause The default setting for both the Xenta 121 Fan Coil and Heat Pump is to have no fan feedback. If the fan interlock options are selected then the heating and cooling will not work on the Xenta 121. The controller sees the absence of the fan feedback as a fan failure, therefore locking out the heating and cooling.   Resolution If fan feedback is not required then the primary heating, secondary heating, and cooling interlock need to be unchecked. You can access these options by launching ZBuilder, click the Configuration tab, and go to Control > Fan > Interlock.   If fan feedback is required then this feature needs to be activated. Launch ZBuilder, click the Configuration tab, and go to Control > Fan > Feedback. Here you can check to activate fan feedback and choose whether it is a hardwired point.   Once the configurations have been set, go to the I/O Setup tab where you can see that "Fan proof" has been added to a DI point. You can click and drag the "Fan proof" point to any available input.  

Issue Invalid or phantom Links, Hosts and IP's in Netcon.  This symptom exists when you penetrate Network Configuration and there are Links and NPRs that you have no clue as to who they are or where they came from. Product Line TAC INET Environment I/NET NPR-2000 Xenta 527 Cause This can happen is if a laptop was used to connect to the system from a different Network or from the outside. Once connected, its IP address and any link it shares are broadcasted to the other devices like PCs and NPR’s, thus populating the table with entries that do not belong or are non-existent for this location or system. It can also happen if you install an NPR/527 or replace  one with a unit that has been used elsewhere. If that use NPR/527 is being used as a reference host, it will infect the system with every IP address and Link in its routing tables. Resolution At this point there is no way to get it out of the tables except to Telnet into all devices, remove the IP tables and rebuild them from scratch. This may be a cumbersome process depending on the amount of devices that make up the system (PCs, Laptops and NPR’s). All of these would need to be set back to 0 reference host while the cleanup is being done. To get this cleaned up, follow the steps to start a Telnet session:   Go to Start > Run and type Telnet then hit Enter. Type open at the end of the prompt, hit the space bar and then put in the IP Address of the NPR/PC and hit Enter. A logon prompt will come up, type csi and hit enter Now type LA, this lists all the entries in the table. Type delall and hit enter. This clears out all the IP’s of the other devices. This would have to be done on all the devices. Once completed, start I/NET to verify that those are gone and then start referencing other PC’s, Laptops and NPR’s to get the system back online again. Note: The proper way to use a Service/Maintenance laptop that is used for multiple customer sites is to direct connect to the NPR to see the controllers of the other links that exist at the site. However, before starting I/NET on the service/maintenance PC, open Windows Explorer, C:\Program Files\Inet Seven and delete the XXX.dat files. These get rebuilt when I/O Server restarts, it also clears out all entries in the routing tables. See .DAT files.  You may also create a different configuration profile for each site. This will also keep the tables separate.

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.