Building Automation Knowledge Base

Issue What are the effects of a connection object on the I/NET controller lan? Product Line Satchwell MicroNet, TAC INET, TAC Vista Environment Xenta 527/913/731 I/NET Cause The I/NET communication protocol has a maximum baud rate of 19,200 bps and this allows for a maximum of 10 messages a second to occur on the I/NET controller lan. This limit applies to the entire controller lan not just a single controller. Optimal performance will be at 5 or 6 messages a second on the controller lan. Resolution Any connection objects involving I/NET points need to be aware of the limits imposed by the controller lan protocol and adjust the periods of connection objects to avoid exceeding these limits. Every connection object that the source is from I/NET requires the value to be read from the I/NET controller before it can determine if the value has changed to send to the target of the connection object. If the default period of 10 seconds is used for all connection objects then only 100 points will consume 100% of the bandwidth on the I/NET controller lan to meet the demand and negatively impact the performance of the I/NET network. Instead count the number of connection objects with source values from I/NET. Divide this number of 4 to allow room for values being written to the I/NET network to determine the minimum recommended period for your connection objects to avoid overloading your I/NET controller lan. Ex: 250 points being sent from I/NET to a 3rd party system / 4 writes a second = 63 second period. This could result in some larger then expected periods and some points might be more critical then others which will require some prioritization. If of the 250 points only 15 require faster response time then they can use a lower period, but this will affect the period used for the lower priority points. It is recommended to avoid periods below 10 seconds if at all possible. Ex: 235 points at lower priority / 4 messages a second = 59 second period 59 second period for low priority points / 10 second period of high priority points = 6 polls per point * 15 points at high priority = 90 reads for high priority points. 235 points + 90 polls = 325 values read from I/NET / 4 messages a second = 82 second period for lower priority points to accommodate 15 high priority points.

Issue When exporting a pointslist from VisiSat 2.1 build 148 to XBuilder (See pdf link in Resolution below), the format of the TACXBuilder.xmlm is not aligned in a manner that XBuilder fully understands. Environment Xenta VisiSat Points list Export Cause TACXBuilder.xmlm is not aligned in a manner that XBuilder fully understands. Resolution Install service pack 1 for VisiSat 2.1 build 148. For further information see TPA-LOND-08-0006.00 The Service pack for VisiSat 2.1 build 148 can be downloaded here. The current version of VisiSat is version 2.1 build 201 (September 2018) VisiSat 2.1 Build 196 can be download here. Two service packs are available: - for information and a download link for service pack 1 software click here. for information and a download link for service pack 2 software click here.

Issue Product Rationalisation Environment Global Cause The IAC-420-F part number for an IAC-420 with fixed terminals has been made obsolete. The IAC-420-P specification number should be used. The only difference between the two devices is fixed (F) terminals against plug in (P) terminals. Resolution The replacement for either an IAC 420-F or an IAC-420-P is the IAC-420-P

Issue Lost or unknown access password for Micronet View.  Environment Global  Cause Lost user password for Micronet View Resolution Back up the MicroNet View project before carrying out the following: Take a copy of the default password file from MicroNet View default project1 Copy the password file from C:\MicroNet\Projects\Project1\View\password.bin Paste this file into Your project. C:\MicroNet\Projects\YourProjectName\View\password.bin

Issue Require Windows 7 version of Remote Alarm Manager. Environment MicroNet View Sigma 4.05 SEB Vista BAS 2800 2800+ Remote Alarm Manager (RAM) Windows 7 Cause Microsoft's continued upgrade of its operating systems. Remote Alarm Manager Version 1.1 will not work under Windows 7. Remote Alarm Manager Version 1.2 will not work under Windows 7. Resolution Product Support has received and uploaded a copy of Remote Alarm Manager 2.0 to an online storage area. Note: - While it is the final software, it is subject to change (probably via the Readme1st.txt) Issuing software before it has been put through full production is not standard company policy, it is due to the importance we place on delivering the software quickly, that we have got it agreed. Contact Product.Support Please provide the following information regarding the installation: - Once the site information is received and checked for compatibility I will email you the link to download the software. Site company name:  Site address:  Copy of RAM registration form  Current Version of RAM installed  Method of licensing (for example Sigma dongle):  BMS software and version of software on site:  Computer operating system you will be installing RAM on:  Installation method (Engine, interface host and consul locations):

Issue Even though Windows Server 2008 R2 is exclusively a 64-bit operating system, 32-bit applications are supported by enabling the WoW64 optional feature. NOTE: These are general instructions for utilizing the WoW64 function. Not all Schneider Software will be able to run in an emulated environment. If uncertain, please check with Product Support Services to ensure proper installation. Product Line Andover Continuum, Field Devices, Other, Satchwell MicroNet, Satchwell Sigma, TAC INET, TAC Vista Environment Windows Server 2008 R2 WoW64 feature. All 64bit OS Cause If the WoW64 feature is not enabled and you try to run a 32-bit application, the application will fail to execute. WoW64 option in in undesired state. Resolution If the WoW64 feature is not enabled and you try to run a 32-bit application, the application will fail to execute. The WoW64 execution layer is an optional component that is installed by default on R2 releases. You can save resources by removing the feature if you are not going to be running 32-bit applications on your Server Core install. Install the WoW64 Execution Layer using the following command: dism /online /enable-feature /featurename:ServerCore-WOW64 If your solution has a .NET 32-bit dependency, then also invoke the following sequence: dism /online /enable-feature /featurename:NetFx2-ServerCore dism /online /enable-feature /featurename:NetFx2-ServerCore-WOW64 Note: In Windows Server 2008 R2 RC1, WoW64 is enabled by default. If you don't want WoW64 enabled, just disable the feature as follows:  dism /online /disable-feature /featurename:ServerCore-WOW64

Issue Generating a Xbuilder project results in the error message "The size of the generated project is xxxx KB, which exceeds the maximum size 8192 KB". Environment Xbuilder 5.x.x Cause The generated project size exceeds the maximum limit due to the following reasons: The project contents made up of graphic pages, inserted networks (LON, I/NET, etc), large images (BMP, GIF, etc), or imported files in the UserTargetImage directory cause the project to exceed the limit. The option "Send Project backup file to target device" is checked and this causes pushes the project size over the limit. Resolution Generate the Xbuilder project to see how far above the limit the project currently is. Open the Project\Settings and uncheck the "Send Project backup file to target device" and regenerate the project to see the difference in file size. If the size difference is significant then check for large files in the project directory that should not be sent to the device such as project or device documentation files such as PDFs. Remove these files from the Xbuilder project directory and generate the project again.  Search the Xbuilder project directory for the largest size files such as graphic pages and try to find way to reduce the size by converting background image formats that will result in smaller file sizes. Example convert BMP file to PNG or JPG format.

Issue Remote Alarm Manager 2.0, RAM 2.0 when first started after an install starts up in Demo mode. Environment Sigma, Micronet, Vista Cause RAM 2.0 has been installed and the RAM Console is started, RAM starts up in Demo mode and gives a 2hr trial period. Resolution This is correct. The demo mode will disappear when the Input interface e.g. Sigma R4 is created and at this point the customers dongle or the engineers PC ID code is read.

Issue No link LED on a Desktop's and Laptop's Network Interface Card (NIC). Environment Windows OS Cause Network interface card has power management feature enabled.  This will shutdown the network interface card if no activity is present, battery is low on power, or battery is intermittent. Resolution Disable power management features under Device Manager Network Adapters. 

Issue Public time sync Servers for the United States Product Line Andover Continuum, Satchwell MicroNet, Satchwell Sigma, TAC IA Series, TAC INET, TAC Vista Environment IP Level Devices USA Cause Time synchronization is required for accurate alarming and reporting Resolution Here is a web site referencing several US based Time Sync NTP Servers. http://tf.nist.gov/tf-cgi/servers.cgi

Issue What to do and who to contact when a controller needs to be repaired or upgraded. Environment All Product Repairs Cause Require information on what to do and who to contact to arrange repairs of defective product, order Controller option upgrades, order Cyberstation option or software version upgrades. Resolution   PROCESS FOR CONTINUUM REPAIRS   NOTE: Repaired items are set-up in Pronto with the part number prefixed by “4-“. This is done to allow visibility for follow-up if required and costing.   Engineer completes “Andover Continuum Hardware Return Authorisation Form”; one for each controller requiring repair. Email completed form/s to TAC AP – Logistics Replenishment ( NOT the US Repair Centre). Do nothing with the controller/s at this stage. Logistics email the completed forms to US Repair Centre requesting cost to repair and turn-around time. Repair Centre replies with cost, turn-around time and RA number/s Logistics pass this information to the requesting engineer who will decide Y or N. If yes, the engineer enters a Sales Order in Pronto, informs Logistics and forwards the goods to Melbourne DC. Logistics raise a Purchase Order on Repair Centre and instruct Melbourne DC to despatch goods. After the goods are repaired they are returned to Melbourne DC where they are receipted and despatched to requestor.   Repair Forms Fill out one of the forms below (whichever applies) and send to local Logistics. Andover Continuum Return Authorization Forms - Americas & APAC OR Andover Continuum Controller Upgrade Forms - Americas & APAC

Issue Using special characters or certain regional characters in the VisiSat Points gallery Environment special characters regional characters VisiSat Points gallery alt Cause This issue is specific to VisiSat version 2.1 Build 185. VisiSat 2.1 older releases (Builds 14, 17,137,148 sp1) are not affected. Example of some of the special characters available: Ù, Ú, Û, ©, è, é, ®, ±, ¼, ½, ¾, Ò, Ó, Ô, Õ. ° (Degree “alt+248”) Resolution Details of the issue and some options available to you are covered in TPA-SACH-12-0005.00 - VisiSat Build 185 Pointlist issue.

Issue What is the accuracy of the I/A Series MN-SX S-Link wall sensors? This information is required for submittal purposes. Environment MN-SX MN-S1 MN-S2 MN-S3 MN-S4 MN-S4-FCS MN-S5 S-Link Cause Published sensor accuracy information required for project submittal Resolution TPA-RKFD-09-0021.00 details sensor accuracy and stability as shipped from the factory and states:- Element Type: Precision Thermistor Operating Temperature Range: 0 – 50 °C (32 to 122 °F) Stability: < 0.02 °C (< 0.04 °F) per year, typical Accuracy Temperature °C Accuracy Temperature °F Accuracy 24 °C ± 0.6 °C 75 °F ± 1.0 °F 0 to 50 °C ± 1.7 °C 32 to 122 °F ± 3.0 °F

Issue Vista central time chart and TAC Xenta Server  time chart - what happens when communication between Vista server and TAC Xenta Server is lost When is TAC Xenta Server time chart updated from Central time chart? Central time chart overwritten from TAC XBuilder Environment TAC Xenta 731, TAC Xenta 721, TAC Xenta 711, TAC Xenta 701, TAC Xenta 511. TAC Xenta 527, TAC Xenta 555 TAC XBuilder  TAC Vista Cause The Xenta Server only knows about its own time objects that is defined in XBuilder (or TSCHI in Menta). There are no synch between the central chart and the local time object. If you download the project from XBuilder, times defined from the central chart will be overwritten. To avoid this you have to perform a Get from Target before download, or you have to open the central time chart again and click ok to update the local time object once again. Resolution When you change a time in a central time schedule the change gets written down to the TAC Xenta Server time object the same way as a manual update. After the correct time has been set in the TAC Xenta Server time object,  from the central time chart,  the controller will operate using these times until it gets new information. It does not matter if the connection to the TAC Vista Server is lost. To perform get from target: In TAC XBuilder go to Project > Get from target Select "Get online changes" Click OK

Issue Some managed switches have settings that have to be configured to match the communications type and speed of the connected devices. Environment Xenta 511, 527, 527-NPR, 555, 701, 711, 721, 731, 911, 913 Cause Some managed switches have to be configured to match the communications type and speed of the connected devices. Resolution Most switches automatically detect the speed and configuration of the connected devices. However, for those site where these configurations must be manually configured, the specs below should be noted. All Xenta Servers use a standard 10 Base T network port. These ports operate at 10 Mbits/sec. and are half duplex.

Issue A change is made to a public signal in TAC Vista Workstation, which was created in a Xenta Server XBuilder project, changed back to the initial value after performing a download to this Xenta Server. Environment Xenta Servers (Xenta 511, Xenta 515, Xenta 555, Xenta 527, Xenta 701, Xenta 711, Xenta 721, Xenta 731, Xenta 913) XBuilder Tested with Windows Server 2003, Window XP SP3 Cause If a path name is changed of a signal, for example, change the "the site name" folder name to another name, Vista consider this change as a major change, and Workstation will not be able to find the new path of the signal. Therefore, the signal will return to the initial value which is initialized in the Menta object. Resolution Suggestion is making all the infrastructure change at the beginning if you can. If there is a need to change the path, make sure all the initial values are reflect to the current values in Workstation. Then, make the download to the Xenta Server.

Issue Technical support contact information for Design 360 and Studio 360 Product Line Andover Continuum, EcoStruxure Building Operation, Field Devices, Other, Satchwell MicroNet, Satchwell Sigma, TAC IA Series, TAC INET, TAC Vista Environment Design 360 Studio 360 Cause Design 360 or Studio 360 has issues requiring technical support assistance which is not provided by PSS. Resolution Schneider Electric Employees should contact PSS who will provide you with your Branch Administrator and Technical Expert contact information. Partners may contact Smartware directly for any support of the tool at: Email: techsupport@smartwaretech.com Phone: (716) 213-2222

Issue Remote Alarm Manager - What TCP ports are used? Environment RAM TCP Ports Cause Customers RAM Console is unable to communicate with the RAM Engine. Customer cannot communicate with RAM webserver. Resolution Remote Alarm Manager uses TCP ports 8090 and 8091 between the RAM Console and RAM Engine. Remote Alarm Manager uses TCP port 80, but also recommends this to be changed to 781 - 785 as defined in the settings page.  

Issue Fault Finding on an IC-SNP / IC3-SNP and associated IAC controllers. Product Line Satchwell MicroNet, Satchwell Sigma Environment IC-SNP IC3-SNP IAC Communications Cause How should testing be carried out where communications between an IC-SNP / IC3-SNP and IAC controllers is not possible. Resolution Overview  The purpose of this article is to advise of the methods and techniques available when fault finding on an IC-SNP SubLAN.  Using the Alarm Manager on the Sigma default/backup Server. The Alarm Manager is a valuable source of information when investigating a problem SubLAN. All system messages generated by the controller will be displayed here. Check system messages (priorities 22 – 30) from the appropriate controller. Unable to open gateway.txt file. This generally indicates that an error has been made in an entry in the gateway.txt file. When initially setting up the gateway.txt file add just one or two entries, as this cuts down the chances of making a mistake. Make sure the basic gateway.txt file is known to be good, or download it from Exchange-On-Line. If an error is reported, check the file for obvious mistakes, if none can be seen, then make a copy of the file. Working on the gateway.txt file, remove all entries, except for one. Download the file and then warm-start the controller. If the file is now processed correctly, then from the backup of gateway.txt, copy a small section of the entries back into the gateway.txt, download and warm-start again. Repeat this process until the problem is located.  Controller??? Is not responding  A specific controller is not communicating. Investigate the controller locally. Will the controller communicate with Visisat via a LIB-4-485 converter, are the LAN connections correctly connected, does the controller have power?  Multiple controllers reported as not responding  Dependent on the number of controllers involved, this may indicate a partial or total failure of the SubLAN. Investigation starting at the IC-SNP will be required.   Investigation at the IC-SNP  The SNP SubLAN, channel 2 should have its BIAS jumper position set to D, for full biasing. The 120-ohm, end of line termination resistors should be fitted. If the controller is warm-started, then shortly afterwards the channel 2 TX LED should be seen to start flashing. This proves that the gateway.txt file is being processed. If the channel 2 RX LED flashes, then the IC is receiving replies to its requests. If the channel 2 RX LED remains permanently on, then this suggests that an IAC controller communications driver is faulty, and is stopping the LAN communications – see below.  IC-SNP Retry Mechanism  Having completed a warm or cold-start, the IC-SNP will process the gateway.txt file. Assuming the file format is correct, then the IC-SNP will start to process the text entries. The IC-SNP will read each line of text in sequence and try to communicate with the appropriate IAC controller. If the IAC controller does not respond, then the IC-SNP will repeat the message three times before marking the IAC controller as off-line. It will also send an “Unable to Communicate with Controller ???” message to the default server. The IC-SNP will then try the next controller. Communications with the off-line controller is retried every 30 minutes, on the hour and half hour. Testing – IC-SNP channel 2 RX LED is permanently on. Try to assess the mid point of the LAN, and instigate a binary chop by separating the twisted pair comm’s at the nearest controller. Check the IC-SNP, RX LED. If the LED has gone off warm-start the IC-SNP: If communications restarts to the remaining controllers, it suggests that the fault must be in the section of the LAN beyond the mid point, and further investigation must be pursued from there. If the LED remains on, it indicates that a fault is still present between the IC-SNP and the mid point of the LAN. In both of the above cases, the next action is to split a section of the LAN into two again, to be working on either 25% of the twisted pair, or by adding the first half of the remaining LAN to be working on 75% of the whole LAN. Using a voltmeter set to DC volts, measure the voltage on each LAN cable. Communications cable +ve and the controller 0volt terminal Communications cable -ve and the controller 0volt terminal Communications +ve and the Communications -ve  Below are some example voltages, these are only as a guide, they will vary dependent on LAN conditions.  Communications cable +ve and the controller 0volt terminal             2.5 volts Communications cable -ve and the controller 0volt terminal               0.15 volts Communications +ve and Communications –ve                                                                     2.31 volts  When checking voltages, a minus value is a good indication that something is wrong. For example if testing at the 75% position, the fault could be in either direction. If when measuring the voltages, cable 1 gives a reading between +ve and –ve of 1.6 volts and cable 2 gives a reading of –2.4 volts, then cable 2 would be the cable to investigate further. The above process is continued until the faulty controller or controllers are located. Once it is believed that all problems have been resolved. The full gateway.txt file should be downloaded, and the IC-SNP should be warm started. Allow a few minutes and then check the Alarm manager for any new error messages. Testing – IC-SNP channel 2 RX LED gives no indication at all  Having warm-started the controller, channel 2 TX LED should be seen to start flashing. If at this stage channel 2 RX LED does not flash, then this suggests that there could be a problem with the IC-SNP, SNP SubLAN, or the controllers connected to it. At this stage there should be fair confidence that the IC itself is working correctly and therefore the controllers or the SubLAN would be suspect. The method for determining the problem will be the same in both cases. Identify the first controller on the SubLAN, and disconnect the twisted pair LAN going to the next controller at this point. Warm-start the IC and observe channel 2 RX LED to see if any flashing occurs. If communications with the controller is possible, then it will be necessary to proceed as in the previous examples, using the binary chop method to locate the problem. If the controller will does not communicate with the IC, then this could be a cable fault or the controller could be faulty. To test the cable, ensure that both cable ends are disconnected and that the cores are separated. Check the resistance between cores and each core to earth. All values should be infinity. And one cable end, short the cores together. At the other cable end, check the resistance between cores, should be almost zero, and each core to earth, should be infinity. To check the controller, connect to it using an LIB-4-485 converter and Visisat Engineering software.

Issue The UNC and Enterprise server, as well as many other Schneider-Electric Buildings products, use a TIME protocol server to provide clock synchronization. The address of that Time Protocol Server no longer works. NOTE: The nist.gov sites will no longer be providing TIME protocol services over TCP port 37 as of March 1, 2013. Product Line Andover Continuum, Satchwell MicroNet, Satchwell Sigma, TAC IA Series, TAC INET, TAC Vista Environment Schneider Electric Buildings products that rely on the use of TCP TIME protocol servers for time synchronization. This includes the I/A Series R2 UNC & ES and the I/A Series G3 ENC & ENS as well as other IP ethernet based products. Cause Many server sites are discontinuing support for the TCP TIME protocol because it is so bandwidth intensive. NOTE: The nist.gov sites will no longer be providing TIME protocol services over TCP port 37 as of March 1, 2013. The site http://tf.nist.gov/tf-cgi/servers.cgi lists most of the currently available TIME protocol servers as well as the status of the entire TIME protocol system. Resolution If the product supports the use of the NTP time sync protocol, switch to the use of that protocol. If the device only supports the TIME protocol, consult the web site http://tf.nist.gov/tf-cgi/servers.cgi for currently available sites.