Building Automation Knowledge Base

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.

Issue Since both products -- Xenta programmables and the UNC 520 -- speak LON protocol, there is some assumption that integration should be seamless.  In the case of ASCs, this is true, but Xenta programmable controllers use some forms of proprietary communication that can complicate the integration. Product Line TAC IA Series, TAC Vista Environment Xenta programmables Xenta 280, 281, 282, 283, 300, 301, 302, 401, 401:B UNC-520 Niagara Tridium Cause Xenta programmables use proprietary communications for three main purposes: To communicate their online status between group members and group masters To communicate between a base unit and associated I/O modules To pass proprietary TAC Network Variables between two programmable controllers In a UNC-520, the first function would be taken over by the new network manager (Local Lon Device).  However, the second two must use Group Bindings set through a Vista compatible network management tool like LonMaker or NL220.  If the controllers are commissioned into the UNC-520, that communication will be broken and I/O modules will go offline and no network variables will pass. Resolution  It is possible to engineer a TAC Vista network as usual, using an LNS management tool to create group bindings to facilitate proprietary communications.  A UNC-520, set to non-network management mode could then be implemented on top. However, any attempt to commission the devices into the UNC-520 network will break that proprietary communication.  To prevent this scenario from occurring, the simplest method is: Do not use proprietary TAC Network Variables to pass data between controllers. Use only SNVTs which will be available to a third party LON network manager like the UNC-520 Make no SNVT bindings in a temporary LonMaker or NL220 database.  Let the UNC-520 handle all network management duties. Do not define Xenta I/O modules in the Menta Device Specification. Use only Xenta 421A, 422A, 451A and 452A I/O modules.  These have the capability to act as stand-alone LON nodes. Define the modules as LON nodes, configure them using Configuring inputs on Xenta 421A or 451A when using the controller as a stand alone Lonworks node. Bind to the inputs and outputs of the I/O modules in the UNC-520.

Issue Receiving the following error when attempting to navigate to the Xenta web interface. "TAC C503Boot/x.x.x.x not configured". Product Line Satchwell MicroNet, TAC INET, TAC Vista Environment Xenta Server 511, 527, 555 Xenta Server 701, 721, 731 Cause Device web interface has stopped working or flash drive / hard disk has been corrupted on the Xenta Server. Resolution Attempt the following steps to resolve this problem: Try restarting the device and see if the unit comes back online, remember to wait 1-2 minutes for the unit to restart.  Check the RUN LED on the panel, if the LED is a solid green this indicates the device is running normally, and your access should be restored. If the LED is RED, solid or flashing this would indicate a problem with the device. Attempt to restore or upgrade the device to the latest firmware.    You can download the latest firmware version from the Schneider Electric Exchange. If this fails then then reference Xenta Server "Run" light is solid red with no communication via Ethernet.

Issue Problems receiving emails from Xenta 511/527 Product Line TAC INET, TAC Vista Environment Xenta Server Xenta 511, 527, 701, 711, 721, 731, 913 Cause Some email servers have been found to filter UTF-7 character encoding as spam. The Xenta products require this encoding to support Swedish characters, but this can be configured by manually editing some files. Resolution Use an FTP program (Internet Explorer) to connect to the Xenta you are trying to change and download the \sys\langstring.cfg file. Edit the file and modify the following lines to replace all instances of 7 with an 8: ALARM_CODE_1= =?utf-7?Q? ALARM_CODE_3=charset=UNICODE-1-1-UTF-7 Upload the edited file back to the Xenta device Cycle power The device will now use UTF-8 character encoding which is more commonly used in the United States. For more troubleshooting tips, see Troubleshooting sending emails from a Xenta Server.

Issue Where are the reports of fixed issues/bugs for the various product lines located? Product Line TAC Vista, TAC INET, Andover Continuum, Satchwell MicroNet, Satchwell Sigma, TAC IA Series, EcoStruxure Building Operation, EcoStruxure Building Expert, Access Expert, Security Expert Environment Technical Product Announcements Cause TPAs contain information of changes made per version of the different product lines. A TPA may report enhancements and/or broken functionality. Resolution Navigate to Exchange Extranet to view all TAC Vista documents tagged as TPA. The documents will be listed in reverse chronological order. Log in to view these documents. See Register for The Exchange Download Center for more information on registration.

Issue Error Messages: Windows - Delayed Write Failed Windows was unable to save all the data for the file D:\VISTA DB _23032011\$queues\insertevents. The data has been lost. This error may be caused by a failure of your computer hardware or network connection. Please try to save this file elsewhere. Windows - Corrupt File The file or directory \VISTA DB _23032011\$queues\insertevents is corrupt and unreadable. Please run the Chkdsk utility. Product Line TAC Vista Environment TAC Vista Cause Problem with Operating System (or) Hard Disk Fault (or) Link between $queues with Vista Database. Resolution As there may be several issues that are causing this, there are three options to look at: OPTION 1: Restore the OLD TAC Vista Data Base Backup. Refer to TAC Vista Technical Manual chapter 26 for re-storing database procedure.   OPTION 2: There might be a linking problem with this folder and Vista.  Here are the steps to check if this is the problem: If the problem still exists, Check for hard disk errors. Find the $queues - folder in existing database folder ( \DB\$queues) Copy the files to an other location and delete current folder (Refer to An efficient method for deleting all queued files in the $queues folder) Recreate it with same folder names and copy back the files into $queues-folder. If the problem still exists, Check for hard disk errors.   OPTION 3: Check for hard disk errors, follow the below procedure: Go to "My Computer", Right click on Hard Disk Drive – typically - C, and Click on Properties. Go to Option "Tools" and Click on "Check Now" under "Error-Checking"

Issue Need to use a Xenta I/O module on another channel from the base device Product Line TAC Vista Environment Xenta I/O Modules Xenta Programmable Controllers LON Channels Cause Using traditional I/O modules you are not allowed to span channels when placing your base unit and I/O modules. Resolution Use the 421A/422A or 451A/452A models. You can span channels by using SNVT based communication rather then Xenta group communication. You will be required to bind the values to the base unit. See Configuring inputs on Xenta 421A or 451A when using the controller as a stand alone Lonworks node for more information on configuring the Xenta I/O modules for stand alone operation.  

Issue When accessing Webstation through Internet Explorer, receive the error “8000401A. Code:-2147467238” Product Line TAC Vista Environment Vista Server 5.x and Webstation. Internet Explorer Windows 7 Cause Improper DCOM settings. ASP.NET not installed Incorrect Remote work station License used Resolution Set DCOM settings as per Vista Installation Manual (04-00001-04) Section 3.6. ASP.NET Start - Controlpanel- Programs - Turn windows feature on or off Navigate to Internet Information Services - Word Wide Web Services - Application Development Feature Make sure ASP.Net are checked, if not install it.Try webstation again. Helpful Vista Utilities - Configure DCOM instantly, Register ASP.NET is a link to a tool that can assist with setting DCOM and ASP.NET   Ensure correct Webstation licenses are installed.  Below are the options available.   0-008-8270-1      "Vista 5.1 Web station 1 CAL - One concurrent user license for Web station 5" 0-008-8271-1      "Vista 5.1 Web station 3 CAL - Three concurrent user licenses for Web station 5" 0-008-8272-1      "Vista 5.1 Web station 6 CAL- Six concurrent user licenses for Web station 5" 0-008-8273-1      "Vista 5.1 Web station 12 CAL- Twelve concurrent user licenses for Web station 5" 0-008-8274-1      "Vista 5.1 Web station Unlimited- License for unlimited users for Web station 5"

Issue LonWorks Device is Offline in Vista, but Online in LonMaker. For Xenta Programmable devices refer to Xenta Programmable Device is Offline in Vista but Online in LonMaker. Product Line TAC Vista Environment LonMaker, NL220 Vista Workstation LonWorks Device Cause If the Vista database has some LonWorks devices that are not communicating, one cause could be due to changes in the system such as moving controllers to a new channel for example. Updating the Vista database with the system plug-in might not fully overwrite all the node properties causing the device not to communicate in Vista Workstation even though it is communicating in the LNS database. Resolution Delete the LonWorks device from the TAC Network in the System plug-in. "Update Vista Database" in the System plug-in to remove the device or devices from Vista Workstation. "Update TAC Network" to add the devices back to the TAC Network. "Update Vista Database" again to add the devices back to the Vista database.