Building Automation Knowledge Base

Issue The STR-250 will not respond to any input and the display is incorrect, typically flashing random characters or 00. During this behavior the Xenta 102-AX will remain offline and unresponsive, no longer controlling room temperature. Product Line TAC Vista Environment Xenta 102-AX STR-250 Cause A firmware error has been identified in the TAC Xenta 102-AX (and 102-AX-U8) version 2.14, when they are used together with STR-250, the LCD version of STAT. A certain sequence of key strokes will cause the Xenta 102-AX to lock up. A firmware upgrade is available. Until that has been downloaded a power cycle will in most cases recover the controller. See the full TPA-MALR-10-0004.00. Resolution The 102-AX Firmware error is fixed in version 2.16 and later. Instructions on how to properly upgrade the 102-AX are located here: Upgrading a Xenta 102-AX to version 2.16 or later

Issue During Vista Installation, receive error message “SQL server service cannot be started” or "Failed to start SQL Server service!". Product Line TAC Vista Environment TAC Vista 5.X.X (Tested on Windows XP SP3 with SQL server 2005 EXPRESS) Cause This issue typically happens after uninstall an earlier version of Vista, and then install a newer version of Vista with the built in SQL server (SQL server 2005 express). Sometimes the SQL server registry key is remained on the computer during the uninstall process. When new installation happens, Vista thinks there is an existing SQL sever; however a failure will occur when try to start the SQL Server service. Resolution It is recommended to use the installation file to uninstall TAC Vista 5.X.X. Follow How to uninstall and completely remove TAC Vista 5 to make sure all files and folders are removed.   Check if SQL Server Service still exists: Right click on “My Computer” and choose “Manage”. Chose “Services and Applications" -> "Services". Check if “SQL Server (TACVISTA)” is listed, if yes, go to next step. Otherwise, restart the computer then run the installation again, issue should be solved now.    Go to “start->Run->regedit” to open “Registry Editor”.   Go to “HKEY_LOCAL_MACHINE/SYSTEM/CurrentControlSet/Services/”. Find “MSSQL$TACVISTA” and “MSSQLServerADHelper”. Then delete both registry folders.   Repeat step 4 for “CurrentControlSet001” and “CurrentControlSet003” under “HKEY_LOCAL_MACHINE/SYSTEM/.   Restart computer and run the installation again. Issue should be solved now.

Issue The B0cfglog.txt file located in the Vista database $log folder and Alarms in Vista are getting the error: Physical unit "Unit Name" on node "Node Name" is a duplicate by uid=### with "Unit Name" on node "Node Name" Product Line TAC Vista Environment Noded Vista Server Master / Slave Vista Cause Conflicting UID in a Master/Slave node network. Master Vista Server or Master. In a Vista network/system containing several Vista Servers, one of the Vista Servers is the Master Vista Server, managing and communicating system-specific information and global settings throughout the Vista network/system. Slave Vista Server or Slave. The Slave Vista Servers in a Vista system receive system-specific information and global settings from the Master in the Vista network/system. If once standalone servers are all added to one Master network, the Master assigns a unique ID to each slave. Normally when a UID gets duplicated the master tells the servers correct the duplication. Sometimes this automated fix cannot occur because the duplication prevents the proper communication. In this case, the slaves need to re-establish communication with each other and be restarted. Resolution Delete the slaved node Update Vista to reflect the node is removed Adding the node back Restart Vista Server The UID should be resolved and the error should not be present.  If the error still comes up please try the following steps: Make current backups of all Vista Databases Close the slave server Open the mater server When asked, "Do you want to change identities on this node?" select Yes Close the master server and reopen both the mater and the salve server and the error should be gone Instructions on how to add the Vista Slave node onto the master can be found in Creating TAC Vista multi-server network. For this to work, the slaves need to be able to see each other as well. If you do not want the slaves to see each other, add them while balancing the load on the network. They can later be removed when the problem is not occurring anymore. 

Issue "No license available" message appears some while after having logged in to Webstation. Product Line TAC Vista Environment Vista 5.1.6 Windows 2008 Server Internet Information Services (IIS) IIS 7.0 or higher Cause This is most likely due to a corrupt IIS installation. Resolution Reinstall IIS Reinstall Webstation The steps for this are outlined in Problems installing Vista Webstation 5.1.5 or newer.

Issue If a Xenta I/O module has experienced a hardware failure it may be necessary to replace it with a new controller. Product Line TAC Vista Environment Xenta I/O Modules Xenta 411, 421, 422, 422A, 452, 452A, 471, 491 Cause Hardware failure of a Xenta I/O module requires it to be replaced. Resolution Physically replace the I/O module The next steps depend on whether the I/O module is part of an LNS system or a Vista Classic Network. LNS System Right click on the I/O module in the LNS management tool (LonMaker or NL220) Select Replace Service pin or manually enter the new neuron ID Open Vista System Plug-in Update the TAC Network Update the Vista database Download the base programmable controller Vista Classic Network Go to How to set the neuron ID of an I/O Module in a Vista classic network for instructions on setting the neuron ID for the new I/O module. Service pin or manually enter the new neuron ID Download the base programmable controller

Issue Xenta server trend logs are mixed up or missing when logged to SQL. For example log a from Xenta server 1 is logged under log a in Xenta server 2. This causes duplicates for some logs and missing logs for others. Product Line TAC Vista Environment Vista 5.1.X Xenta server 5.1.X with trendlogs that are retrieved by Vista and logged to SQL. Cause When creating the Xenta servers, copy/paste has been used in Vista. Using copy/paste causes certain references to be created incorrectly. Resolution !If you have already encountered the behaviour described contact Product Support! Otherwise read on... The correct way to engineer Xenta servers in Vista when the XBuilder project is to be reused. Right-click on the server object in Vista and select New->Xenta Server X5\7\9xx Right-click the newly created Xenta server and select Edit In the XBuilder project that opens, configure and download your project to the Xenta server. Close the XBuilder and save the changes to the current project when prompted. Refresh Vista and ensure that everything is online and correct in the Xenta server. To reuse this project in another Xenta server Right-click the Xenta server in Vista and select Edit. Make the appropriate changes to the project e.g. change the IP address. You can now either save the project as a template or choose Save as from the file menu. Rename the file and save it. After saving, select the menu item Vista Database->Save As and navigate to the Vista server object in the dialogue that opens. Right-click in the dialogue window and select New->Xenta Server X5\7\9xx. Choose an appropriate name and then click on Select. Go to Vista workstation and update the server object. The new Xenta server should now appear. Now it has been created it can be edited further and then downloaded to via XBuilder.   Note: If the trend log values are mixed up also in the Xenta Server itself (i.e. in a trend log page) it may be a different issue, see Trend log values from M-bus meters under a Xenta Server are mixed up.

Issue When the need arises to change object paths in OGC graphics the Vista reference changer does not work. Product Line TAC Vista Environment Vista 5.x.x Cause For unknown reasons the reference changer does not seem to work well on all OGC databases. Resolution The first thing to try is to edit the OGC after an attempt has been made with the reference changer. If the links have been updated saving the OGC back to the Vista database can sometimes work. If this did not work you can use the reference changer in the OGC editor. Graphics binding were broken after a Vista upgrade to 4.5 from an earlier version is a link on that process.

Issue Site License is not working after upgrading to Vista 5.1.4 or newer. Product Line TAC Vista Environment Vista License Cause The path to the License Server (lmgrd.exe) and License File (Licensename.lic) is incorrect because the default Vista installation folder changed from TAC in 5.1.3 and older to Schneider Electric 5.1.4 and newer. Resolution Stop and close TAC Vista Server, Workstation, etc. Open the LMTOOLS utility from the Start menu: All Programs/Schneider Electric/TAC Tools 5.x.x/LMTOOLS Under "Config Services Tab", ensure the path to licenses file is correct ,C:/Program Files/Schneider Electric/License. Under "Start/Stop/Reread" tab, check "Force Server Shutdown" box. In order click, "Stop Server", "Start Server", "Reread License File". You should receive a message stating the Reread License File Completed. Start any TAC application other than Vista Server (for example: TAC Menta). You will be prompted to "Specify the License Server System" or "Specify the License File". Select "Specify the License Server System" and enter the computer name. Alternatively, If the License Server resides on the local machine, you may type "localhost" as the computer name. If the above is unsuccessful, follow the full steps in the resolution of TAC Vista 5.0 to 5.1.7 license does not work after installation which will also correct the path name to Schneider Electric.

Issue Multiple instances of Tacos running in Task Manager Product Line TAC Vista Environment TACOS.exe Vista Server Cause It is possible that Vista Server will try to start multiple/additional instances of Tacos.exe when starting. Resolution Re-register the service. This can be accomplished by executing Tacos.exe with command line switches.  End all Tacos.exe processes. From the Start Menu "run" command prompt perform the following: tacos.exe /unregserver (to unregister Server) tacos.exe /regserver (to re-register Server) This should re-register Server. If Server executes as a result of the command, you have most likely entered it incorrectly. Restart Server and observe. See Registering/Unregistering TAC Vista Server as a Windows service for more information on registering Vista Server as a service.

Issue Multiple Vista Servers can be noded together in a network. See Creating TAC Vista multi-server network for details. If a PC should crash, it may need to be replaced and should be done with as little interruption to the Vista network as possible. Product Line TAC Vista Environment Vista Servers noded together Cause PC crash Hardware upgrade Any replacement of the physical server Resolution If possible, obtain a backup of the Vista database from the PC that is to be replaced. Bring up the new PC, install all necessary Vista software Restore the backup of the Vista database that is to reside on this PC. Because the Vista server nodes communicate with other Vista servers over IP using server names, this will restore communication for all nodes.  There is no need to perform any other maintenance  If no backup of the database is available because of a PC crash, etc, then ensure the Vista server name matches that of the previous computer's Vista server.  See Rename a Vista Server for that process. Recreate the Vista database, and the node should be communicating with the other nodes.

Issue Webstation can't load the menu tree. The following messages appear: Exception: Attempted to read or write protected memory. This is often an indication that other memory is corrupt. Stack Trace: at TAC.Interop.TACOSOI.ITACOSobjectMgr.GetObjectByOid(UInt32 dwOid) at TAC.WebStation.Modules.TreeView.TreeViewPageScript.TreeNodePopulate (Object sender, TreeNodeEventArgs e) at PowerUp.Web.UI.WebTree.TreeView.OnNodePopulate (TreeNodeEventArgs args) at PowerUp.Web.UI.WebTree.TreeView._() The following errors have occurred. Please correct these errors and/or contact the system administrator. An unexpected exception has occurred: Error loading type library/DLL. (Exception from HRESULT: 0x80029C4A (TYPE_E_CANTLOADLIBRARY)) (0x80029c4a) System.Runtime.InteropServices.COMException at TAC.Interop.TACOSOI.TACOSObjectTierMgrClass.GetManager(Guid& riid) at TAC.WebStation.Modules.Alarms.AlarmListPage.GetAlarmsFromServer(TACOSViewObject view) at TAC.WebStation.Modules.Alarms.AlarmListPage.DataBind() at TAC.WebSTation.Modules.Alarms.AlarmListPage.Page_Load(Object sender, EventArgs e) at System.Web.UI.Control.OnLoad(EventArgs e) at System.Web.UI.Control.LoadRecursive() at System.Web.UI.Page.ProcessRequestMain(Boolean includeStagesBeforeAsyncPoint, Boolean includeStatesAfterAsyncPoint) Product Line TAC Vista Environment Windows 2008 Server TAC Vista 5.1.5 Webstation IIS 7.0 or higher Cause A webstation function does not have permission to access information from TAC Vista (TACOS.exe). Resolution This article assumes that Webstation has been installed according to the instructions in Problems installing Vista Webstation 5.1.5 or newer. Check which user is running Internet Information Services (IIS) Go to the start-menu and type inetmgr in the search field. Once the IIS Manager console is open locate and select Application Pools in the menu tree. Right-click on SE ASP.NET v4.0 Classic and select Advanced settings. Locate the Process Model\Identity setting and note which user is running the application pool - NetworkService by default. Grant the user running the application pool access to TAC Vista Folders Locate the ...\Schneider Electric\Tac Vista 5.1.5 folder. Right-click on the folder and select Properties. Go to the Security tab and select Edit. Add the user account network services and grant the account Read & Execute, List Folder Contents and Read Permissions.  Webstation functions should now have access to the required folder and files.

Issue Webstation Displays the error: The current identity (NT AUTHORITY\NETWORK SERVICE) does not have write access when attempting access. Product Line TAC Vista Environment Vista Webstation ASP .NET Cause Incorrect setting in ASP and .NET Resolution Please run the DCOM Config 1.0.3.0.exe utility located in Helpful Vista Utilities - Configure DCOM instantly, Register ASP.NET.

Issue Error message when opening Vista 5.1.5 Webstation: "HTTP Error 404.2 - Not found. The page you are requesting cannot be served because of the ISAPI and CGI Restriction List settings on the web server." Product Line TAC Vista Environment Windows 2008 server (32-bit & 64-bit). Webstation 5.1.5, 5.1.6, 5.1.7 Cause ISAPI (Internet Services Application Programming Interface) and CGI (Common Gateway Interface) services are not activated by default in Windows 2008 Server. Resolution After following the installation instructions in the Vista 5.1.5 TPA-VSTA-11-0002.01 (or Send to controller fails with "Not enough memory" error in Distribution View) do the following: Click on Start and then Run. Type inetmgr Once Internet Information Services Manager has opened, change to "Detail View" in the View menu. Double-click on ISAPI and CGI Restrictions Feature.   Under the "ISAPI and CGI Restrictions" right-click on ASP.NET v4.0.30319 and select "Allow". Webstation should now work.

Issue Group bindings are correct, Xenta programmables download successfully, and all controllers are commissioned and online in LNS. However, no programmable units will show online in Vista Workstation. Check the alarm queue in Vista Workstation (sorted by Last Change) for the following alarm (or similar):  Server-$EE_Mess  Physical device not defined/configured - TAC301: 040294360200 The controller type and Neuron ID will change each time the alarm updates (every 30 seconds or so) as it cycles through each programmable controller in the network.   Product Line TAC Vista Environment TAC Vista Workstation Xenta programmable controllers Xenta 280, 281, 282, 283, 300, 301, 302, 401, 401:B Cause Group names must not exceed 20 characters in length and must not contain any spaces. Resolution Change all group names to adhere to the standard that they must be 20 characters or less in length and must not contain any spaces. It is also good design practice to change the subsystem names in LNS if that is where they originated from. This will help future service technicians to make sense of the network structure. For alternative solution, view System alarm message, Physical device not defined/configured.

Issue No more address table slots for a device involved in the attempted connection. (Subsystem:  NS Connections, #15) Product Line TAC Vista Environment LonMaker 3.X NS Connections Error codes are not specific to any one LON environment, the display of the error may vary, but the steps to resolve should be the same.   Cause Every LON Neuron chip has 15 total address table slots inside, which store addressing information for SNVT communication.  Xenta programmable controllers utilize Address Table slots 0 and 1 for TAC and Xenta Group Binding information for reporting online status to the Vista Server and transferring TA Network Variables to each other.  This leaves 13 available address table slots in a Xenta programmable controller.  There are many scenarios by which address table slots are consumed (both in the sending and receiving controllers).  If you have exceeded the address table limitations, no further SNVT bindings (which would require additional address table slots) will be allowed.   Resolution The error message should indicate which controller has exceeded its address table limitations (sending or receiving).  First verify the current status of the address table. Right-click on the controller Select Properties Navigate to the Address Table tab.   This will tell you (a) if the address table is indeed full or (b) how many slots you have left.  Knowing this can help you determine the easiest recourse to the problem. If the address table is full in the sending controller: Information can only be sent via one-to-one bindings to 15 controllers (13 from a Xenta programmable).  Sometimes combining data into a one-to-many can save address table slots.  Instead of sending an individual occupancy to 20 VAVs, which consumes 20 address table slots, send them all the same one-to-many occupancy command, which consumes only 1 address table slot. Using a broadcast SNVT binding type will save on address table slots by only consuming one slot per receiving subnet instead of one per receiving controller.  This will increase network bandwidth, but allows one-to-one bindings to many controllers in the same subnet.  Xenta programmable SNVT output limits would be the only limiting factor. See Bind to more than 13 unique LON devices without running out of address table entries for details on creating Broadcast SNVT Bindings. If the address table is full in the receiving controller: If the binding is a one-to-one binding type: This is typically not an issue. The receiving controller does not normally have an address table slot consumed by a one-to-one SNVT binding. The only time a receiving controller has an address table slot consumed by a one-to-one SNVT binding is if that SNVT input is set to ""Poll."" (Unacknowledged, repeated, acknowledged profiles have no bearing on the number of address table slots consumed by one-to-one bindings.)   Unless dictated by the manufacturer of the device with which you are integrating, it is very rare to require polled inputs in a Menta file. Check the SNVT AI blocks in Menta and uncheck the "Poll" checkbox. Binding these inputs will no longer consume an address table slot in the receiving controller. If the binding is a one-to-many group binding type: Every member of the binding (sending or receiving) will have at least one address table slot consumed by the group binding. Freeing up address table slots may require some creative manipulation of the bindings. Options are: Convert to one-to-one bindings where the receiving controller will not lose an address table slot Do not customize every individual combination of group bindings (i.e. send the setpoint to the same controllers that are receiving outside air temp, even if they won't be using it). Every unique combination of controllers will constitute a new group and thus consume a new address table slot in each controller.

Issue Cycling power 10 times doesn't clear Xenta base units version 3.61 or later. Product Line TAC Vista Environment Xenta Programmable Controllers rev 3.61 or later Cause A change to the firmware got rid of the 10 power cycles clearing the application. Resolution To clear the memory of a Xenta 2xx/3xx/40x running system program 3.61 or later, i.e. clear out the Menta application, insert a reset plug into the RJ-45 serial connection and then give the controller power. If you don't already have one, it is quite simple to make. See How to Clear the Xenta Application for instructions on how to make a reset cable.

Issue What are the limitations of the Xenta 527 when used with TAC Vista and I/NET. What do I need to consider when integrating I/NET with TAC Vista. Product Line TAC INET, TAC Vista Environment TAC I/NET TAC Vista 5.1.6 and above TAC XBuilder TAC Xenta Server 527 5.1.6 and above I2V Cause Integrating I/NET into Vista. Resolution Below are a few considerations associated with the Xenta 527 Server that may assist when integrating existing I/NET systems with TAC Vista: As in all case the latest versions of both hardware and software should be used on any integration project. The attached datasheet indicates that the TAC Xenta 527 Web Server has been tested with up to 1000 I/NET points, if you require to integrate more points than this it is then recommended to add additional Xenta Servers to cater for this.  You may also consider segregating your I/NET System to improve performance. Currently it is not possible to pick and choose which points are imported into the XBuilder project, it can only be limited to which SAV file (or controller) is imported . Note: Each I/NET point type, as shown below, creates the following number of TAC Vista objects - these include; Alarm, State, Value, Control, Test, Manual, Alarm_ack etc, and vary according to the point type used. I/NET Point Type Number of TAC Vista Objects created DO 14 AO 11 AI 10 PI 10 DI 11 DA 11     The impact to consider here is the time it takes when adding or modifying your Xbuilder Project. This usually means that importing a large number of SAV files will cause the Vista server to get extremely busy creating / importing all of these objects.  It is best to let the process complete before selecting any other window.  Note that the total number of objects created during the import of the I/NET points is not counted as part of the 'tested' 1000 point limit stated in the above datasheet. This is a separate consideration. Network performance can be affected when a large number of connection objects are in use (so direct transfers between I/NET and Vista). There is no documented limitation, but the recommendation is not to exceed 300 connection objects per Xenta 527 Server.  For information on what the effects a connection object on the I/NET controller LAN has and how to calculate this, refer to Connection Objects in Xenta Server effect on I/NET system. Engineering of any I/NET feature apart from Point Control, Trends, Time Schedule and Alarm Configuration can only be done using the I/NET Host Tool or via an I/NET workstation.  Access to these features are via the Xenta 527 web server feature, so pages appear as HTML pages within TAC Vista, this will have a different look and feel to both Vista and I/NET users.   Other Knowledge Base Articles as listed below are also available to assist on integrating I/NET and Vista: Unit conversions when integrating LON to I/NET Vista to I/NET Integration Tips    Decoding the I/NET signal "flags" attribute Viewing I/NET Point Names in Vista Workstation instead of Addresses User Defined Units on I2V integration were accidentally set incorrectly SQL Host not passing data to Xenta 527 Web Server

Issue Vista Server can read values on a LON device, but when this same device is used in an Xbuilder project for a Xenta Server no values can be read. Product Line TAC Vista Environment FT-10 LON Network Xenta Server Xenta 511, 527, 701, 711, 721, 731, 913 Cause The XIF file of the LON Device does not conform to LonMark standards for self documentation. Vista Server can recover from this and assumes all SNVTs are from the default function block, but XBuilder cannot. On the third line of each variable declaration is the self documentation: 1: VAR nvo01Value 2 0 0 0 2: 0 1 63 1 0 1 0 1 0 1 0 0 0 3: "@1|2 The correct format is to show the functional block number and the member number separated by either a | or # character. Improperly formatted self documentation include the following: "nvo01Value - Does not define the function block or member number. "@_1|_1 - Uses _1 which is not a valid number. "&3.4@0,20000-MP580 - Uses a - (dash) which is not valid It can also be because SNVTs from devices are bound directly to Menta programs in a Xenta 7XX. If the procedure below doesn't solve the issue, refer to Graphic values not updating in a network that includes a Xenta 7XX. Resolution The XIF file must be edited to correct the self documentation. Right click on the controller in Vista Workstation and open the properties window. On the XIF file tab find the file name of the XIF file. Open this file from the $thisfil directory in the Vista database folder. Modify the XIF by manually correcting these invalid lines of self documentation. It is recommended to use the default function block (0) and start with member index 50 to ensure no overlap. Increment the member number for each SNVT. "@0|50 "@0|51 .... Once the XIF file has been updated save it under a new name in the $thisfil directory. In the device properties browse to the new XIF file. Log out of workstation. Log in to workstation. Insert the LON network into Xbuilder. Generate the project and send to the device.

Issue Xenta 102-AX version 2.19 included 6 major updates and changes. They are outlined below. Product Line TAC Vista Environment Vista Xenta 102-AX Cause M/STAT Air Flow Calibration Errors Error Description: When calibrating a Xenta 102-AX using the M/STAT a Velocity Pressure Offset is not generated in circumstances where one would be generated in the 102-AX Plug-in. This adversely affects the accuracy of the calibration, in particular at the low flow setting. Note: All steps for calibration using the M/STAT are found in Calibrating Airflow on a Xenta 102-AX (or MR-VAV-AX) using the M/STAT. Workaround: Perform the calibration using the LNS 102-AX plug-in tool or the TMGL plug-in tool Xenta 102-AX does not perform wink function properly Error Description: Attempts to perform the wink function fail. When a wink function is performed, the red light on the controller is expected to come on and flash to identify the controller and the STR-250 should display "00" with the man logo displayed as well. This should last approximately 45 seconds. STR-250 connected to the Xenta 102-AX is not controlling the fan properly Error Description: The STR-250, stat when connected to the Xenta 102-AX, reacts incorrectly to buttons being pressed when in the fan menu. The increase button causes a decrease and the decrease button causes an increase among other odd behaviors. Also, if the fan is set to shut off (this action should not be allowed) the Xenta 102-AX performs a resynchronization. Pressure dependent mode erroneously requires airflow and fan enabled Error Description: The 102AX requires 80% Airflow Setpoint to run Heat1 in Pressure Dependent mode. Xenta 102-AX Hot Water floating control resynch fails Error Description:  When the Xenta 102AX does a hot water floating control valve resynch based on being in the 10-90% "happy" zone for 60 seconds and then goes to 100% it does not resynch at the 100% open position for the full stroke time. It gets to 100% commands the resynch, then closes the valve, re-opens the valve to 100% then allows the valve to control back to a normal position. Xenta 102-AX Floating Hot Water valve control failures Error Description:  Heating outputs stop working on Xenta 102-AX sporadically causing hot water valve to open even though application is calling for it to be closed. This occurs when the 102-AX is set up for a floating valve actuator (PWM 2) and occurs sometimes within a day but could take a few of days to show up. The resynchronization of the valve seems to have no effect and the only way to fix the controller is to cycle power or by switching nviEmergCmd to something other than its default and then back again a moment later. Resolution If any of these errors are occurring, upgrade the Xenta 102-AX to version 2.1.9 or higher. Click here to download the APB file. Complete upgrade instructions can be found at Upgrading a Xenta 102-AX to version 2.16 or later Version 2.19 addresses the problems listed above as follows: M/STAT Air Flow Calibration Errors Fix: When calibrating a Xenta 102-AX using the M/STAT a Velocity Pressure Offset is now properly generated. Xenta 102-AX does not perform wink function properly Fix: After clicking Wink the a red LED on the controller flashes to identify the controller and the STR-250 displays "00" and the man icon. After approximately 45 seconds both the controller and the STR-250 return to normal. STR-250 connected to the Xenta 102-AX is not controlling the fan properly| Fix: The ability of the STR-250 to override the fan command on the 102-AX is disabled by default. If this functionality is required it can be turned on by setting DamperActuator.SCPTdirection.bit15 to 1. Pressure dependent mode erroneously requires airflow and fan enabled Fix: The 102AX no longer requires 80% Airflow Setpoint to run Heat1 in Pressure Dependent mode. Xenta 102-AX Hot Water floating control resynch fails Fix:  Logic has been corrected to only resynch open or resynch closed as needed. Additionally, the heating output resynchronization algorithm has changed to operate as follows: Two internal timers have been added to track the accumulated amount of time that heat load is 0% and at 100%. Once either of these timers reaches 30 minutes, a resynch is initiated in the respective direction of the timer. The resynch consists of activating either the open or close triac output for an amount of time equal to the user defined stroke time. Xenta 102-AX Floating Hot Water valve control failures Fix:  Heating output logic corrected to prevent failure.

Issue When starting the Vista Server, the splash screen displays the current state of the startup.  It gets to the "Trend Log Initialization" screen and then hangs. Product Line TAC Vista Environment Vista Server Cause Queued files in the $queues folder in the Vista database are being written to the SQL database.  If the queued files folder has grown very large, it can take a very long time (hours) to write this data to SQL.  If the connection to the SQL database has been broken, then it will take an infinite amount of time. Resolution Check for queued files in the $queues folder Navigate in a Windows Explorer window to the Vista Database. (If you are unsure of the location, you can verify it in the TAC Vista Server Setup Vista Database tab). Go to the $queues folder Look inside the insertevents and insertlogvalues folders. This is where data is stored temporarily before it is written to the SQL database. Having queued files is not necessarily a sign of a problem. However, if there is a connection problem, these folders will continually grow in size without older queued files being written from the folder. Allow time for the files to write the SQL Start Vista Server. Insure that TAC DSS Writer Service is running. When it gets to trend log initialization, leave the PC alone and allow time for the files to write to the SQL server.  If the size of the $queues folders are shrinking, then the process is working and after enough time, the server will start. Note: If you have cleared the $queues folder but it still hangs on trend log initialization, still allow plenty of time for the server to come up. There is a good chance that the Xenta controllers are passing all of their trend logs over to the SQL server. This could take hours or even overnight to complete. Delete the queued files If the data is not of dire importance, delete all the files inside both of the $queues folder.  For an efficient method for deleting many queued files, see An efficient method for deleting all queued files in the $queues folder. Check the SQL connection Open the TAC Vista Server Setup In version 5.1.3 and prior: Start > Programs > TAC > TAC Vista Server X.X.X > Server Setup In version 5.1.4 and later: Start > Programs > Schneider Electric > TAC Vista Server X.X.X > Server Setup Go to the SQL Server tab In the lower right-hand corner of the tab, press the Test Connection button. If it pops up a window that says "Connection test succeeded!" then your SQL connection is okay. If it fails the connection test, check the instance name. If you are using default settings it should be: SQL Server name: PCname\TACVISTA or (local)\TACVISTA Log database name: taclogdata If these are set correctly and the connection still fails, one method for reestablishing the connection is to uninstall/reinstall the Vista software. Remove TRL files This can also occur if the database has been upgraded from a lower versions, and still has information in the TRL files in the database. Stop the server Locate all TRL files in the $thisfil folder Delete any TRL file over 32Kb. Start the server again.