Building Automation Knowledge Base

Issue What track is used for ABA data? Environment ABA Magnetic stripe cards and readers. Cause Card format information required. Resolution ABA data is usually stored on Track 2 and requires a track 2 reader to decode the data. ABA Magnetic Stripe Format.

Issue Using STR-350 Bypass button as On/Off button in LNS Network Product Line TAC Vista Environment Vista STR-350 STR-351 Cause The Bypass button will only toggle the output of the nvoOccManCmd if the input nviEffectOccup matches the current button value. Resolution The STR-350/351 Sensors allow you to configure the Bypass button as an ON/OFF button but if it is not setup correctly it can get stuck in a single position. If using an application specific controller, the effective occupancy of the controller should be routed back to the STR-350 and bound to the nviEffectOccup. If using a 3rd party controller that does not have a SNVT for the effective occupancy, follow the step below. If using a programmable Xenta controller the nvoOccManCmd coming from the STR-350 should be bound to the programmable controller that with some logic programmed to follow the toggle of the button. Then that signal should be sent back to the nviEffectOccup of the STR-350. For the application used in the Classic network, refer to the Using STR-350 Bypass button as On/Off button in Classic Network.

Issue After configuring a Niagara R2 station with BACnet MSTP communications, the UNC displays an error in the standard output window: "Cannot load BACnet MSTP Driver". Error details below: *************************************************************** ERROR: Cannot load BACnet MSTP Driver tridium.nre.DriverException: Not found [mstp]    at tridium.nre.Platform.installDriver (bytecode 98)    at tridium.nre.Platform.getDriver (bytecode 42)    at tridium.nre.Nre.driver (bytecode 4)    at tridiumx.bacnet.services.link.mstp.MstpLinkService.init (bytecode 3)    at tridiumx.bacnet.services.network.NetworkPort.linkInit (bytecode 14)    at tridiumx.bacnet.services.network.NetworkPort.linkStart (bytecode 😎    at tridiumx.bacnet.services.network.MultipleNetworkService.start (bytecode 29)    at tridiumx.bacnet.services.network.RouterNetworkService.start (bytecode 1)    at tridiumx.bacnet.services.BACnetService.startService (bytecode 44)    at tridium.foundation.Sys.startServices (bytecode 49)    at tridium.foundation.Station.startStation (bytecode 63)    at tridium.foundation.Sys.boot (bytecode 27)    at tridium.foundation.Sys.bootLocalSns (bytecode 17)    at tridium.tools.StationMain.bootSns (bytecode 0)    at tridium.tools.StationMain.doIt (bytecode 352)    at tridium.tools.StationMain.main (bytecode 10)    at java.lang.reflect.Method.invoke (Native Method)    at tridium.nre.Nre.mainImpl (bytecode 271)    at tridium.nre.Nre.main (bytecode 1) *************************************************************** Product Line TAC IA Series Environment Niagara R2 Cause BACnet MSTP driver does not load on a UNC reboot. Resolution Add the line illustrated below to the drivers.properties file and reboot the UNC: driver.mstp=tridium.nre.vxworks.mstp.VxWorksMstpDriver

  Issue Using active directory with Change Control  feature does not authenticate when signing  Product Line EcoStruxure Building Operation Environment Building Operation release 3.1 and above Building Operation Enterprise Central  Building Operation Enterprise Server Building Operation SmartX Controllers Cause The interaction of Active Directory and Change Control is not clearly defined in the documentation when both are in use.  Although Active Directory within Building Operation Domains can use both the Fully Qualified Domain Name (FQDN) and Netbios Windows Domain names it is recommended that only the Netbios Domain name be used if Change Control is implemented. Refer to EBO Known Issues & Solution topic  Change Control and Windows Active Directory not authenticating - Communities (se.com)  for updates.   Resolution When using Active Directory with Change Control only add the Windows Netbios name to the Building Operation Windows domain name entry:   Using the Full DNS Domain Name (examples include - apa.gad.schneider-electric.com ; pss.apa.local etc.) although these will allow user accounts to log on to servers it currently does not work when used to authenticate change control.    The easiest way to identify which domain name to use is to open WorkStation and refer to the name shown next to:  Log on as:    Secondly when authenticating change control actions with active directory user accounts, irrespective of the Default Building Operation Domain selected, the user account name must be prefixed with the Windows Domain Name 

Issue References Guide and changes from release 1.3 to release 1.4.x and forward Product Line EcoStruxure Building Operation Environment StruxureWare Building Operation site with regards of release 1.3 to release 1.4.x Cause In release 1.3 and earlier the reference system was relaxed allowing for bindings to be created in ways that made the applications error prone. In release 1.4 this is now being more strictly controlled, which will allow the system to: Help the user to not unintentionally create faulty combinations of references, resulting in bad/unpredictable application behavior and last man win situations Better understand and control how references will behave in copy/paste/move/delete situations. Improve performance in the system, e.g. the limitation of variable connectors is removed. For the complete Reference Guide, please download the pdf from the Download Center For instructions on how to upgrade an Automation Server and how to get the conversion log, See Upgrading Automation Servers from 1.3 to 1.4. For explanations of the entries found in the conversion log, See AS Conversion Log Analysis. Resolution What has changed There are 2 areas which have changed:   1. Rules Programmatic control: A reference means that data is sent from A to B. In Release 1.3 it was possible to send data from A to B and from C to B. This gave a "last man win" situation. In Release 1.4 it is only possible to send data from exactly one source to a recipient. This means A to B and C to B is no longer allowed. User control: This is where properties are displayed in graphics, watch windows and other client components. In release 1.3 it was possible to change a property that was programmatically controlled. This gave a "last man win" situation. In release 1.4 it is not possible to change a property as a user if this property is programmatically controlled by something else. The property will automatically be read only for the user.   Public signals: In release 1.3 and earlier, it was possible to programmatically control a public value in programs. Public signals are intended to be used for user control, while inputs are intended for programmatic control. In release 1.4 this is now changed to the following: Public signals in programs (FB/Script/Menta) can be referenced by user control - NOT by programmatic control Public signals intended for programmatic control must be changed to inputs and rebound. This will give the following benefits: Public signals cannot be forced, while inputs can. If a user needs to take control of a programmatically controlled input, via e.g. graphics or watch window", he will force the signal and there will be no risk of a program overwriting the user value. As stated above - if an input is programmatically controlled, this will for the user be read only. However, force is still possible. There is no more risk for "last man wins" situation between user control and programmatic control. The system will remove any ambiguity with these new sets of rules. Update: Release 1.4.1 and later version add the feature of binding to PVB/PVI/PVR back. But for Script, it still keeps the same. LonWorks Local Node nvis: In release 1.3 it was possible to programmatically write to local node NVIs. These NVIs exist to receive data from the LonWorks network. This gave a "last man win" situation. In release 1.4 it is no longer possible to programmatically control local node NVIs.   2. Definitions In release 1.3 a reference could be a) relative b) system absolute c) server absolute In release 1.4 a reference will be a) "normal" b) Locked A reference created by the user will always be normal (which means relative). In the bindings view the user can then choose to "lock" a reference (which means server absolute). The references will behave identically until a copy/paste (or import/export)  operation is done.         Upgrade Upgrading from release 1.3 to release 1.4 will apply the new sets of rules. It is there for very important to read the log to understand if any existing references in release 1.3 will be impacted during the upgrade For AS: In the Device Administrator the logs are available before the upgraded DB is deployed to the AS. It is up to the user to either examine the upgrade log, make changes in running release 1.3 and rerun the upgrade, or to make the changes after upgrade. It is recommended to do changes prior to upgrade to ensure a fully functional system directly after upgrade. Some warnings are benign and can be disregarded, please refer to release notes for more information. IF an upgrade detects that references will be impacted, the user will be informed about this with a orange progress bar indication and a written information that the upgrade succeeded with warnings. After upgrade, all invalid or unresolved references will be visible from WorkStation for further examination if needed.

Issue When using Microsoft Vista and IE 8, the calendar picker pops up a window but does not show the calendar. Product Line TAC INET Environment I/NET Seven 2.40 Microsoft Vista Internet Explorer 8 Cause Security of Internet Explorer Resolution Go to the Internet Options, Security Tab, and disable the protected mode for the Internet.

Issue Procedure to upgrade SQL database from TAC Vista 5.x.x to 5.1.7 Environment TAC Vista 5.x.x TAC Vista 5.1.7 MSSQL Express 2005 SP4 MSSQL Express 2008 R2 -SP1 Cause Revised TAC Vista SQL database layout: TAC Vista 5.1.7 introduces a revised and improved SQL database layout in order to improve the overall performance in the TAC Vista system with large databases. The revised database layout is utilized by default for new installations and current installations can be upgrade either automatically or manually depending on the installation type. SQL 2008 R2 Express SP1: Microsoft SQL Server 2008 R2 Express SP1 is now included in the TAC Vista Server 5.1.7 installer. The TAC Vista Server installer can upgrade an existing SQL Server 2005 Express installation to SQL Server 2008 R2 Express SP1; only supported in a typical TAC Vista installation.     Resolution Follow the Instructions before Implementing this procedure: Take the Vista Backup and SQL DB backup before implementing this process. Shutdown the TAC Vista Server. If the Vista Server running as a Server, Stop the service and shutdown the TAC Vista Server. Open the “SQL Database Upgrade 5.1.7” (From Program Files [or] from Start Menu)   Check the Server and Database options.   Choose the correct type of Authentication. If the vista using SQL Server, choose the SQL Server Authentication, enter the correct Login details.   Click on “Test Connection” and “Test User access”. You should find Test Connection access and Test User access successful. If Vista and SQL DB backup has taken, check on the “Check Box”.   Click on “Upgrade”, then the following screen appear. Then Click on “YES” to upgrade.   After the upgrade is complete check the Vista Server has a connection to the upgraded SQL database. This is done from the Vista server setup. Use the test connection If the connection is successful you will see a message like this.   Now, the SQL database has been upgraded. Download this procedure in PDF Here .

Issue Archiving and database size with FIFO not working Product Line TAC INET Environment I/NET site Cause dbo.Events keeps growing and presumably is not in FIFO mode (First In First Out) Resolution Note: Autogrowth is not used with TAC I/NET Seven or TAC Andover Continuum The size of the InetDB can be set through Microsoft SQL Server Management Tool:   By selecting the InetDB database properties you can set the Autogrowth setting via the Files page.  Under the Autogrowth column select the browse button as shown:   The Change Autogrowth setting by either disabling the Autogrowth check box or you can set Autogrowth to a Maximum File Size as shown:     The Autogrowth value now shows this setting is restricted to setting define in step 2.   Disabling Autogrowth allows the events to be removed from the table when the total size of the SQL database reaches the limitation set in the properties of the db. The table dbo.Events has all the current events and it should be the biggest. The dbo.currenteventdetail table keeps up with the current max events and the current minimum events. Lets say it is around a million (1,000,000) events and so the first event in this table would be 01 and the last would be the 1000000. If items are removed from the other table, the dbo.Events, then this other table, the dbo.currenteventdetails is off. This means we run the risk of losing those events that are not correctly numbered. Manually removing items from one table can have an impact on other tables and how this data is kept and archived. About archiving and shrinking the db, this is a function of SQL. SQL goes into a FIFO mode, which means First In, First Out. This keeps the db from getting to large. The archived records are designated as archived in the db and even though they are still (secretly) in the db, they will be out as soon as the db is over the capacity amount and the amount designated in the db.currenteventdetail table is the guide for what is current. The thing that keeps the db from getting to large is the archive is setup correctly and old data is archived. It is still available via Reports, but considered not technically in the db. That is what shrinks the db and keeps it from getting over size.    Note: Autogrowth is not used with TAC I/NET Seven or TAC Andover Continuum

Issue Within the Network modem object, what settings are required/normal for both the alarm delay and dial parameters windows? Product Line TAC Vista Environment Xenta 901 Vista Modem Manual Cause Problem/tip using modem dial Resolution This depends on the desired functionality. One examples definitions for the TAC Xenta: Dial when priority 1 alarms have been tripped/reset/acked Dial when priority 2 alarms have been tripped/reset Dial remaining alarms only once per day when it is cheaper to dial It always depends on the site requirements. One recommendation is to use at least 5 minutes delay before dial up. Please read the TAC Xenta 901 Handbook.

Issue Configuring Daylight Savings Time. What is the proper way to do this? Product Line TAC INET Environment I/NET Cause There are two different ways to setup the Daylight Saving Time in I/NET. Daylight Saving Time DST is not observed in Queensland, the Northern Territory or Western Australia, South Africa, and other parts of the world. The document below shows how to set 0 in the DST settings. If using a revision of I/NET prior to 2.21 be reminded that the DCU time sync problem in the ReadmeSeven.txt is not just pertaining to the error generated by not having DST settings for the controller. 2.21 is referring to the version where this was fixed. Also note that when upgrading a site, go all the way to 2.31 at least because it solved problems which were in the previous revisions. Resolution Option #1: Using Windows time and NO controller time synch Set Windows Time for daylight savings changes. Remember to change the time zone for you location. In my example I am in the Central time zone. Set the Inet Host settings to do Time Sync. Function for all the controllers you wish to time sync with the PC. Enable the Daylight Savings settings using the "Setup" button. This is the correct settings for the controller configuration. Note if you set the daylight settings in this format you will get a 2 hour shift up or back. The daylight setting must be set to zero (0)   Option #2 Using Windows time and controller time synch Set Windows Time for daylight savings changes Set the Inet Host settings to NO Time Sync. Function This the correct setting for this controller configuration using the controller to shift the daylight saving time   The Daylight Savings times were set by the Congress of the USA in 2004 The beginning was to be the second week of March on a Sunday. This comes out in I/NET as being Month = 3 Week = 2 Day = 1 (Sunday is always day 1 Thus Saturday is day 7) The ending was to be the first week of November on a Sunday This comes out in I/NET as being Month = 11 Week = 1 Day = 1 (Sunday is always day 1 Thus Saturday is day 7)

Issue After using the STR-350/351 as an I/O module to a Xenta programmable controller and then using STR-350/351 LonMaker Plug-In the changes made in the Plug-in default back to previous settings Environment Vista LonMaker, NL-220 STR-350 Plugin Cause If the STR was added to the Menta application then the controller will continually update the STR with the settings programmed. Any changes made with the STR LonMaker Plug-In will then be overwritten. Resolution In order to use the STR 350/351 LonMaker Plug-In, the STR must not be set up in classic mode by adding it in the Menta application of the controller communicating with it. If the STR-350 has already been added to a Menta application it must be configured using the Menta application. Otherwise, the STR-350 should be removed from the Menta application before attempting to configure the STR-350 as a Lon node using the Plug-in.

Issue I/NET Anti-Passback (APB) rules. Product Line TAC INET Environment I/NET Cause Assistance with setting up Anti-Passback (APB). Resolution Note: Use of the Anti-passback option described below requires that a DPU have both an entry reader and an exit reader. An elevator DPU will support only an entry reader, and therefore, will not support anti-passback. Activate or deactivate the Anti-passback option. This option is not available if you have activated the Elevator option described in the previous step. Activate the Anti-passback option to prevent persons who have successfully gained access into an access-controlled area from passing their key/card back to another person desiring access. Refer to Implementing Anti-passback for more information. Note: The actual system response for both anti-passback and anti-tailgate (below) is controlled by the anti-passback scheme selected for the individual (see Individuals Parameter Editing). Activate or deactivate the Anti-tailgate option. This option is only available if you have activated the Anti-passback option described in the previous step. Activate the Anti-tailgate option to discourage users from following another person through an access-controlled door without reading their own keys/cards for access. Refer to Implementing Anti-tailgate for more information. If you activated the Anti-passback option in the previous step, the Entry Zone and Exit Zone parameters will become enabled. The valid range is 0–64. Enter an Entry Zone number. This is the number of the zone where the entry reader is located. Refer to Implementing Anti-passback for more information about entry and exit zones. Enter an Exit Zone number (0–63). This is the number of the zone where the exit reader is located. Leave this field blank if there is no exit reader. Refer to Implementing Anti-passback for more information about entry and exit zones. Note: If the Anti-tailgate option is enabled, any door between the secured area and the non-secured area must have the same zone number for both exit and entry. The non-secured area is any region not under access control, such as a lobby, public area, or the outdoors. Set the Anti-passback Reset Time (0 to 60 minutes). Any value higher than zero (default) will cause the anti-passback flag to be reset for each individual the specified number of minutes after the individual passes through the door. If an "APB Reset" action has been defined in the mode schedule of this door point, it will still be honored (i.e., the individual's anti-passback flag may be reset by the APB Reset action before the time specified in this field has expired). If you leave this parameter at the default value of zero, no timed reset of the anti-passback flag will occur. In this case, only an APB Reset action defined in the door's mode schedule will reset the anti-passback flag. Refer to Resetting the Anti-Passback Flag for more information. The purpose of the anti-passback function is to prevent persons who have successfully gained access into an access-controlled area from passing their key/card back to another person desiring access. Activate anti-passback for a particular door in the Door Extension editor. The system response depends on the anti-passback scheme selected in the Individual Parameters editor. The options are as follows: Hard (default) — access is denied, generates an alarm. Soft — access is granted, generates an alarm. Graced — access is granted, no alarm is generated. This effectively cancels anti-passback for the individual. Although the Anti-passback parameter (activated from the Door Extension editor) is used to enable anti-passback, implementing anti-passback also requires that you define access control zones (refer to Entry and Exit Zones, below). Note: Anti-passback requires that a DPU have both an entry reader and an exit reader. An elevator DPU will support only an entry reader, and therefore, will not support anti-passback. If you wish to have a more stringent control, you may also implement anti-tailgating.   Entry and Exit Zones Depending on the version of host software loaded on your workstation, I/NET supports either 32 or 64 zones (assigned from the Door Extension Editor). When anti-passback is enabled, the system will allow a user to be in only one zone at a time. When a user moves between zones (e.g., uses a key/card at an entry or exit reader), the system generates a zone exit message followed by a zone entry message, and broadcasts these messages to the other readers in the system. A user may enter a zone, but must use their key/card to exit the zone. If they do not (i.e., they leave a zone when another person uses their key/card), then I/NET will not allow them to re-enter any other zone using their key/card. Zones Example:   Zone Numbering Rules When populating the door editor, enter the zone number where the reader is physically located. Entry readers should be located on the exterior of a controlled zone. Exit readers should be located on the interior of a controlled zone. Exterior doors, in access control terms, are doors that lead from a non-controlled area into an access controlled area. These doors are not necessarily on the exterior of the building. The entry reader at an exterior door is physically located in an area that has no zone number (i.e., a non-controlled area). The zone number assigned to the entry reader of an exterior door should match the zone number assigned to the exit reader of that door. The example above shows a facility with three anti-passback zones that share doors. Using the example, the door leading from zone 1 to zone 3 has an entry reader physically located in zone 1. The zone number assigned to the entry reader is 1, even though this reader is used to gain access into zone 3. This door also has an exit reader that is physically located in zone 3. The zone number assigned to the exit reader is, therefore, 3. Each exterior door shown in the example has entry reader and exit reader zone numbers that match. This causes I/NET to generate only one zone entry or exit message after a valid read at an exterior door. This also makes it unnecessary to use a zone number for the exterior (non-controlled) area of the building.   The following two types of anti-passback are available: Soft anti-passback — The anti-passback flag is set when a key/card is successfully read, and a door sense switch is activated. This would occur when the door is opened. Hard anti-passback — The anti-passback flag is set when a key/card is successfully read at the entry reader. In this case, the anti-passback flag would be set even if the door were never opened. If anti-passback is enabled, hard or soft anti-passback is automatically selected by I/NET. The system looks at the Door Sense Switch parameter setting (this parameter is available from the Door Extension Editor). If a sense switch is defined (normally-open or normally-closed), the system uses soft anti-passback. If no sense switch is defined, the system uses hard anti-passback. Although the Anti-passback Type parameter (available from the Door Extension Editor) is used to enable anti-passback, implementing anti-passback requires that you define access control zones (refer to Entry and Exit Zones, below). Note: Anti-passback requires that a DPU have both an entry reader and an exit reader. An elevator DPU will support only an entry reader, and therefore, will not support anti-passback.   Additional Clarification: Anti-passback can be very complicated or simple depending on the site. Hopefully after looking at these documents, and reading this example, explains what the site setup could be. Let’s assume each door has an entrance and exit reader. This is required for anti-passback. Let’s also assume that all the readers are on the same Link (NPR). This is required for anti-passback. This example is a hallway with 32 rooms such as a hospital or school. Let’s set the hallway up as zone 1. Scenario 1: If you want the 32 rooms to have the same zone, set them all up as zone 2. This will allow the individuals to pass into any of the 32 rooms. Room 2 – Zone 2 Room 3 – Zone 2 Room 4 – Zone 2 and so on. Scenario 2: If you want to keep the individual(s) specific to their room and not all 32 rooms, you want to have different zones for each of the 32 rooms. Room 2 – Zone 2 Room 3 – Zone 3 Room 4 – Zone 4 and so on. There are other considerations, if the rooms have access to each other without scanning back into the hallway (zone 1). If there are exterior door from the hallway, it also would be zone 1.

Issue IT departments want to install just the client software without attaching to the webclient server and want to know if there is a way to accomplish this. Product Line Andover Continuum Environment webClient Windows XP Windows Vista Windows 7 Windows Server 2003 Windows Server 2008 Cause Webclient deploys activex controls using several .cab file from the C:\program files\redist folder on the webclient server. These files must be delivered to the browser PCs with admin privileges on the client PC in order for webclient and webpinpoint to work. Here is a list of the .cab files and ActiveX controls that get installed AccWebUtils.cab - AccDotNetBootstrap Control, Crypto Class (Used for  regular webclient use) WebclientPinpointSetup.cab - PPBrowserMgr Control (WebPinpoint) WebclientVideo.cab - TACVideoControl.VideoControl (Viewing Video layouts) ** The other piece that doesn't get installed are the permissions for the caspol commands that must be set for zones in order to run schedules. See webClient schedules getting error 'request for permission of type' system.security.permissions or .net control error on Webclient reports related to webclient schedules and running the caspol commands 1.94 SP1 requires that Microsoft VC++ 2005 Redistributable SP1 x86 to be installed for webpinpoint, it prompts to install when accessing a graphic the first time Resolution There is no client side webClient PC installation. The method for delivering the necessary activex controls and files are triggered by the browser PCs access to the webclient server PC and then the files are delivered to the client.  Some IT departments use Microsoft  SMS or Active directory to deploy software in a locked down environment. To deploy webclient to these types of browser PCs, they would have to logon with Admin privileges to perform the one time install of these files. The only other method if the IT group has InstallShield or WISE package creation software would be to capture the browser PC installation and use the produced .msi file for client delivery. This is informational only and has not been tested by Schneider Electric.

Issue How to set up a Operator Panel to only see the TAC Xenta controller it is plugged into Product line EcoStruxure Building Operation Environment TAC Xenta Operator Panel firmware 3.7 TAC Xenta Programmable controller 3.85 or higher Cause When the Operator Panel is plugged into a TAC Xenta programmable controller the whole network of TAC Xenta controllers are listed. Resolution This option and the requirements are described in this TPA To enable the option in the TAC Xenta: How to enable this in the TAC Xenta: Edit the application and create a Public PVI-block with the name XENTASYSREG and set this block’s initial value to 8. If you have multiple TAC Xenta OP panels in the network, each one connected to a specific TAC Xenta Controller, it will be required to create this special PVI block in every one of these TAC Xenta Controller’s application code.   To enable the option in the OP Panel: 1. Open the TAC Xenta OP local service menu, by pressing and holding the “escape” and “enter” buttons for a few seconds. 2. Enter the bottom command: “11 OP connects to”. 3. Enter this sub-command, and then type in, using “+” or “-“, the specific TAC Xenta controller’s subnet and node address you want this OP to be “locked” to. The TAC Xenta controller subnet and node addresses can easily be found in TAC Vista Workstation; select “properties” for the TAC Xenta controller and the subnet/node address will be displayed. Observe that when you select, in the OP panel’s new menu, the node number and press enter the TAC Xenta OP will restart and seek for this now selected TAC Xenta controller. Note that it is still possible to access this specific TAC Xenta controller from another TAC Xenta OP in the network if that TAC Xenta OP is of a version prior to 3.70 or this new “lock-function” is not enabled in that TAC Xenta OP. However doing this, you will only here also “see the local TAC Xenta controller”. In this case you will be able to exit this TAC Xenta controller again by pressing “escape”. While in the locked TAC Xenta OP you will not be able to exit from the TAC Xenta controller it is locked to.

Issue There is a need to know which versions of Digital Sentry was tested with version 1.94 Environment Continuum Windows XP Windows 7 Windows Server 2003 Windows Server 2008 Cause Certain versions of Digital Sentry may or may not be supported in some versions of Continuum. Resolution Digital Sentry versions 7.2.xx and 7.3.54 were tested with Continuum 1.94

Issue A new feature in EBO 3.2.X where the value is grayed out when the binding on the priority of a BACnet object matches the BACnet Default priority level Product Line EcoStruxure Building Operation Environment EcoStruxure Building Operation Cause Missing Release note documentation about the new feature added to EBO 3.2.X. Resolution In EBO versions prior to 3.2.X, when a bind in Priority matches the Default BACnet Write Priority, the values can be changed without forcing. From EBO 3.2.X, users need to force the value, let it change, and then un-force it. The following screenshots show this feature in more detail. The following image shows the Default BACnet write priority has been set to 16. Now, for example, if a program output is bound to Priority 16 of an analog value: The value property would be greyed out and has to be forced if changes are needed.   This is a new feature in EBO 3.2.X which is not mentioned in the Release Notes documentation.   Hint: A defect # 45570 has been documented in Release Notes 3.2.X about “Webstation - BACnet analog value's value property is not greyed out when there is a bind to the default priority.”. This issue has been fixed in EBO 4.0.X.   

Issue There is potential for confusion around the backward compatibility offered in EcoStruxure when the version of Enterprise Server differs from that of Automation Servers in the same system Product Line EcoStruxure Building Operation Environment Building Operation Enterprise Server Building Operation SmartX Servers Cause The 3.1.1 Release Notes refer to a new 'Multi-version system' with the possibility of a v3.1 Enterprise Server but with v3.0 Automation Servers able to function long term within the same system (albeit with some engineering limitations).    This implies that AS running earlier versions than v3.0 cannot coexist, attempts to add AS running v2.0 to ES running v3.0 have produced errors. However........ The System Upgrade Reference Guide refers to 'Runtime Compatibility' with Version 3.1 that states that Automation Servers running v1.8, 1.9, 2.0 and 3.0 can all coexist with an ES running 3.1 without issue Resolution Both documents are true, but there are two possible situations that need to be considered: Situation 1) A site has a v1.9 or v2.0 system which is required to be upgraded to v3.1. When upgrading, the ES is usually the first device to be upgraded, then depending on the number of AS onsite it may take a period of time to upgrade all the AS (especially if some of these servers are used in hospital theaters etc). For this reason EBO has an Upgrade Runtime Compatibility from v3.1 back to to v1.8, 1.9, 2.0 and 3.0, which means that an AS already in the system when the ES is upgraded to 3.1 will maintain connectivity and functionality while the upgrade takes place. Situation 2) A site has an external v1.9 or v2.0 AS whichis required to be added to an ES which is already running at v3.1. When trying to add in a new controller to a v3.1 ES, an error is produced stating that the version of the AS being added needs to be updated to before it can be added. Error Message when adding v2.0 AS to v3.0 ES Error message when adding 2.0 AS to 3.1 ES (better explanation) To summarize EBO does have Runtime Compatibility from v3.1 back to 1.8 as stated, but only for AS already in the system at the time of upgrade. Once upgraded to v3.1 the multi-version environment can be used to operate AS at v3.0 but adding AS running versions before 3.0 will generate a descriptive error.

Issue What is the recommended maximum number of Doc to Dif conversions? Environment I/NET Cause Configuration Question Resolution Not more than 20.

Issue How does a controller get an alarm into the database when using the Enhanced Alarm Logging feature of CyberStation? Product Line Andover Continuum Environment Cyberstation Cause Continuum Alarms are configured in the Netcontrollers and Infinet-controllers at each site. Only the CX Controller sends alarms to the Cyberstations once a point in the Controller surpasses its threshold and goes into an alarm state. The CX Controller then uses an internal algorithm to determine which CyberStation will log the alarm. Resolution The alarm is sent to the first (Non "0" Network ID) Cyberstation on its list of known devices. If the controller does not get a response from this workstation that the alarm was logged, it will try again three more times. If the workstation still does not respond to the controller, the controller will flag this workstation as offline in its internal controller database. It will then move to the next workstation in its list until it finds a workstation that is online and has logged the alarm successfully. If no workstations respond to the controller, the controller will buffer the alarm internally until it can find a workstation that is online. If the workstation is online, the alarm will be logged to the Continuum Database and then the database will notify the Workstation that the alarm was logged successfully. When the workstation gets this notification from the database that the alarm was logged, it will in turn send a notification to the CX controller that the alarm was logged successfully. Next, the controller will send the alarm to all recipient workstations for this alarm. When the controller is sending the alarm to the other recipient workstations it will follow the same logic and try to send it three times to each. If for any given recipient workstations the controller does not get a response that the alarm was received the controller will flag that workstation as offline internally and not try to send the alarm to that workstation again.

Issue When Forcing a value from SBO, it is just overwritten by the Lua script all the time. Product Line EcoStruxure Building Expert Environment MPM SE8000 Cause By default, the MPM executes the program once every second, so if written simply like: Output_1 = Off the output will be turned Off every second. Resolution Declare a few variables in the Lua script that will help you implement the logic you need, here is an example: var("Override_Status","ME.BV1") var("Override_Value","ME.BV2") if changed.Override_Status and Override_Status == 1 then ME.BO1 = Override_Value elseif changed.Override_Status and Override_Status == 0 then ME.BO1 = ME.BI1 end Basically, an override status points will act as a "Override button", and when it is active, The output will be equal to override value specified in SBO. Else, if it is disabled, the output will be set to what ever you currently have in your script. In the example above, the output will be equal to the input.