Building Automation Knowledge Base

Issue The I/A Series R2 (Niagara) build 529 programLib jar file is missing 5 objects that were available in previous build programLib-2.301.527c.v1.jar. The missing objects include: ConfigurableBinaryOutputNode.class FlexLimitEnableBits.class FlexString.class Bpa2Str.class Fs2Fp.class Environment I/A Series R2 (Niagara) build programLib-2.301.529.v1.jar Cause Objects listed were not included in programLib-2.301.529.v1.jar Resolution The missing objects were restored in the programLib-2.301.532d.jar. Use it instead of the programLib-2.301.529.v1.jar. In Windows Explorer, rename programLib-2.301.529.v1.jar. to programLib-2.301.529.v1.jar.old in the emb, nre/modules, and nt directories. Download programLib-2.301.532d.jar Copy into all three 2.301.529.v1 directories (emb, nre/modules, and nt ).

Issue Communication to LON controllers is lost.  After a re-start of the station, the following errors appear in the standard output window: ---------- Station Starting:   MON MAY 02 14:53:10 2011 ---------- Tridium Niagara Station, r2.301.529.v1 [test] MESSAGE: ErrorLogService installed [/test/services/ErrorLogService] Start service: ControlEngineService [3] ControlEngineService Start service: UiEngineService [7] UiEngineService Start service: NotificationService [6] NotificationService Start service: LogService [5] LogService Start service: AuditLogService [2] AuditLogService Start service: ErrorLogService [4] ErrorLogService Start service: LonWorksService [9] LonWorksService Error opening driver LON1 java.lang.Exception: Unable to open lonworks driver *************************************************************** ERROR: Cannot startService [Sys: LonWorksService [9] LonWorksService] java.lang.IllegalStateException: Unable to open lonworks driver at tridiumx.lonworks.services.LonLinkLayer.start (bytecode 143) at tridiumx.lonworks.services.LonWorksService.startService (bytecode 12) 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) tridiumx.lonworks.LonException E_LON_COMM_SERVICE_NOT_STARTED    at tridiumx.lonworks.services.LonCommService.doLonCommSendRequest (bytecode 19)    at tridiumx.lonworks.services.LonCommService.lonCommSendRequest (bytecode 3)    at tridiumx.lonworks.services.LonCommService.lonCommSendRequest (bytecode 68)    at tridiumx.lonworks.util.Neuron.readMemory (bytecode 29)    at tridiumx.lonworks.util.Neuron.readMemory (bytecode 9)    at tridiumx.lonworks.util.Neuron.isNMAuthSet (bytecode 32)    at tridiumx.lonworks.util.Neuron.isNMAuthSet (bytecode 16)    at tridiumx.lonworks.devices.LocalLonAppDevice.verifyDevice (bytecode 2)    at tridiumx.lonworks.services.LonWorksService.stationReady (bytecode 28)    at tridium.foundation.Sys.stationReady (bytecode 23)    at tridium.foundation.Station.startStation (bytecode 87)    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) MESSAGE: Station started successfully. (HTTP port=80) [test] These errors follow a short time later: Freeing transaction from transmit driver, tag is 4 The LonException code is java.lang.Exception: ldvWrite() failed - rc = 6, in transmit driver Freeing transaction from transmit driver, tag is 5 The LonException code is java.lang.Exception: ldvWrite() failed - rc = 6, in transmit driver  ... repeated Environment Niagara R2 UNC-520-2 Niagara R2 UNC-410-1 (including the -N international versions) Also applies to obsolete models:  UNC-500, UNC-510, UNC-600, UNC-610 Cause These errors indicate the Niagara operating system is not communicating to the (on-board) Echelon MIP chip.  To confirm, run the following test: Open the running station in Tree View Go to the Properties of the localLonDevice, specifically the Engineering tab Blank out the "neuronId" and click Apply Reboot the UNC When the station has started successfully, return to the neuronId field and observe the value in the box If the neuronId field is all zeros, then there is a hardware problem with the Echelon MIP chip. Resolution This issue is not field-repairable. Contact Product Support Services for a return authorization number.

Issue Does Web Pinpoint user ActiveX Controls? Environment WebClient Cause On some projects the customer IT department will require that you let them know when Active X controls are being used over the internet. Resolution WebClient Pinpoint uses no ActiveX controls.

Issue When Sigma is restarted the Alarm manager does not run. Environment Sigma release 4.04 Cause The Alarmslog.rec file is too large. Resolution The archiving process in Sigma release 4.04 occasionally failed and the AlarmsLog.rec file was allowed to continue increasing in size, this file is some cases might reach 2GB, which would cause the Alarm manager to fail. To correct this issue, carry out the following: 1 - Stop the Sigma Client and Server. 2 - Using Windows Explorer locate AlarmsLog.rec in the C:\Sigma\Data folder. 3 - Either rename or delete the AlarmsLog.rec file. 4 - Restart the Sigma Server and Client. Note:- a new AlarmsLog.rec file will be created when a new alarm arrives at the Server. 5 - An alternative to this procedure would be to upgrade to the latest release of Sigma.

Issue Get error message 0x80004002 when trying to access objects under an OPC server in the Vista OPC tool. It is possible to see the OPC server but get the error when accessing the object under it. Environment Vista 5.1.5 Vista OPC tool Cause For some reason some important DLLs for OPC were not registered on the client PC. Resolution Register the following DLLs: opccomn_ps.dll opc_aeps.dll opchda_ps.dll opcproxy.dll

Issue Declaration of Conformity Environment Continuum hardware Declaration of Conformity Cause Location of Declaration of Conformity Resolution Regulatory Compliance on The Exchange

Issue Under certain unknown scenario reloading a b3 device may result in CyberStation hanging when setting the attributes of the first object to be reloaded. A buffer overrun error may also appear. Environment CyberStation bCX4040 b3 Cause Invalid BACnet device configuration in database. Resolution In CyberStation go to the BACnet Devices folder and delete the BACnet device for the b3. Perform a Find New BACnet Devices. Send the BACnet device for the b3 to the database The reload operation should now complete successfully.

Issue When emailing reports there is no attachment. Environment Windows XP Continuum 1.7X, 1.8X. 1.90 Cause A Product defect. Resolution Contact PSS and request the Email Reports Patch. # 21527 1-978-975-9508

Issue Is the I2/B3 865/866/885 UL 916 Listed Environment  I2/B3 865/866/885 Cause  I2/B3 865/866/885 UL 916 Listed Resolution Yes the  I2/B3 865/866/885 are UL 916 Listed Download the complete list of UL916 listed products.

Issue Shortly after a successful backup to flash the exclamation point appears again on the controller's icon in the Continuum explorer indicating that a backup to flash is needed. Environment CyberStation bCX9640 bCX4040 CX9680 ACX5740 ACX5720 Cause PE program changing configuration attributes. A setpoint changes value. Resolution Any changes to a configuration attribute will cause the database in the controller to be marked as needing backup up to flash. Also, if an object is configured as a setpoint, changing its value causes the database to be marked as needing backup to flash. Find and modify any PE programs that change configuration attributes (i.e. description, format)  and/or setpoint values.

Issue How do I set the LonWorks send and receive heartbeats settings for localLonDevice in an I/A Series R2 UNC station? Environment I/A Series R2 UNC LonWorks Integration Cause There may be a need to change the settings for the LonWorks send and receive heartbeats settings in an I/A Series UNC station (for faster or slower updates).  Resolution To change the send heartbeat of the localLonDevice: Go to the UNC station's lonLonDevice properties Config tab. The maxSendTime and minSendTime is the send heartbeat settings for the localLonDevice (LLD). As per the Niagara LonWorks Integration Reference page 9-4 to 9-6 (which is installed together with the installation of I/A Series WorkPlace Pro software), maxSendTime and minSendTime are defined as follows. maxSendTime: Specifies the maximum amount of time (in seconds) that the LLD waits to write an output value—if the value has not changed in this amount of time, the LLD will send it anyway. Maximum send time ensures that network variable updates are received by destination nodes (whether they change or not) within the limits set by that node's receive heartbeat limit. minSendTime: Restricts the number of network variable updates placed on the wire. Regardless of the rate at which the network variable is updating, it will only be sent at this rate. This property prevents the network from being congested by values that are oscillating at an abnormal rate. To change the receive heartbeat of the localLonDevice: Go to the UNC station's lonLonDevice properties Config tab and expand the nvoStatusProps property. The Receive Heartbeat is used to ensure timely network variable updates are transmitted and received. If this property is set to zero, the local LON device does not expect periodic updates of its linked inputs - it simply waits until the value changes.

Issue Can not access the SQL database with a Windows domain user, but it works with a local user on the computer. Environment Vista 5.x.x Cause By default, the Windows users in the administrator group on the PC have enough authority in the Vista SQL database.   Resolution Add the Windows domain user to the administrator group on the PC and it will work.

Issue How should a Echelon Lon Talk Adapter (LTA) be configured if used in a Vista classic network? Why is the network and controllers offline in Vista Classic? Environment Vista 4.x.x Vista 5.x.x Echelon LTA (PCC-10, PCLTA-20) Cause The NI application of the LonTalk adapter needs to be configured as NSI not VNI (Virtual network interface) in the LonWorks Plug n' Play which configures the LTA. Resolution Change the NI application of the LonTalk adapter. Open the Windows Control Panel Select the LonWorks Plug N' Play. Change the NI Application For a PCC-10 LTA select NSIPCC For a LTA-20 LTA select NSIPCLTA Click Apply Start Vista Server.

Issue Changes made to Device Templates in the XBuilder Device Editor for interfaces with Modbus, BACnet, etc are not seen by the controller after download. Environment XBuilder 5.x.x Xenta Server 5xx/7xx/9xx Cause Device Template files are not recognized by the device until the unit has restarted. Resolution When downloading the project to the Xenta Server select to "Send all project files".  This will force a warm start of the device causing the changed Device Template to be recognized.

Issue Cyberstation workstation programs become disabled when user logs in to the workstation Environment Continuum Cause If a Plain English program is running on a workstation and a user logs on to that workstation, who does not have the rights to perform the operations within the program, then the program may become disabled. Resolution 1. Always try to keep the programs on a workstation to a minimum. Controllers should always be used for programs where possible. 2. Add a Line E to keep the program enabled. 3. Security rights for all users can be increased to keep the programs running. 4. If a program on a workstation is trying to do something that the user does not have permission to do, then the program will disable Therefore the user rights for doing what the program is doing need to be increased for that user

Issue A TGML script has stopped working since upgrading to Vista 5.1.5. The string.split method is not able to identify the "^" character in Vista 5.1.5 TGML scripts. Environment TAC Graphics Editor TGML 1.1.5 (Vista 5.1.5) Cause Unknown. Resolution Use string.split("\\^") instead. This may also apply to other characters but this has not been tested.

Issue The following files are left in the root directory of the drive that Vista is installed on: eula.1028.txt eula.1031.txt eula.1033.txt eula.1036.txt eula.1040.txt eula.1041.txt eula.1042.txt eula.1049.txt eula.2052.txt eula.3082.txt globdata.ini install.exe install.ini install.res.1028.dll install.res.1031.dll install.res.1033.dll install.res.1036.dll install.res.1040.dll install.res.1041.dll install.res.1042.dll install.res.1049.dll install.res.2052.dll install.res.3082.dll vcredist.bmp VC_RED.cab VC_RED.MSI Environment Vista 5.1.5 Cause A bug in Microsoft's Install Shield which is a software tool for creating installers or software packages. Resolution Delete the files shown under "Issue".

Issue Get "Error: Device type specified in MTA file is not what TAC Vista expected, Info: Download Application and Parameters"  when downloading to a Xenta controller from TAC Vista. Environment TAC Vista TAC Xenta 30x, 28x, 401 Cause The type of controller that you specify in the device specification in the Menta application have the be to exact type you are downloading to. So either there is a mismatch or there is another controller on the network with the address you are using. Resolution Right click and Edit the controller in TAC Vista Workstation. Log in to view the Menta application Check in Options > Device Specification that it is the right type. If not, change to the right type.

Issue Controller randomly goes offline and add entries in its error log indicating LAN_ERR_BUFFER_TOO_SMALL_ERROR and/or LAN_ERR_ALLOCATION_ERROR. Environment CX9680 ACX5740/20 Cause Typically this is caused by a problem with the link partner (hub or switch) or some kind of CAT5 issue. Resolution If you have other ACX controller on this switch that is working fine try swapping the ports (or move the controller to a different port) and see if the problem follows the port or the controller. If the switch is a smart switch that gives an error log, get the log from the switch and analyze it or send in for analysis. There is also a possibility that the NIC card in the controller is bad but that assumption can only be made after everything else has been eliminated.

Issue Do I need a LAN System Configuration for CFR implementation? Environment Cyberstation 1.7X, 1.8X, 1.9X Cause Do I need a LAN System Configuration for CFR implementation? Resolution The Standalone CyberStation configuration does not support the CFR Compliance Pack. For more information download the Continuum CFR Compliance documents below. Continuum CFR Compliance Pack - Life Sciences Solutions FDA Code of Federal Regulations 21 CFR Part 11