Building Automation Knowledge Base

Notifications

Community

Notifications

Categories
Forums
Knowledge Center
Blogs
Ideas
Events & Webinars

Share Your Feedback – Help Us Improve Search on Community!
Please take a few minutes to participate in our Search Feedback Survey. Your insights will help us deliver the results you need faster and more accurately.
Click here to take the survey

Building Automation Knowledge Base

Schneider Electric Building Automation Knowledge Base is a self-service resource to answer all your questions about EcoStruxure Building suite, Andover Continuum, Satchwell, TAC…

Search in

Invite a Co-worker

Send a co-worker an invite to the portal.Just enter their email address and we'll connect them to register. After joining, they will belong to the same company.

Send Invite Cancel

Related Forums

Intelligent Devices Forum

Previous Next

Invite a Colleague

Found this content useful? Share it with a Colleague!

Invite a Colleague

Label: "tac ia series"

View in: "Building Automation Knowledge Base" | Community

1688 Posts | First Used: 2018-09-06

Building Automation Knowledge Base

Issue The Dynamic DEMUX object in the R2 LonWorks jar (Conversions folder) appears to incorrectly set output bits for certain SNVT_State values, causing confusion when interpreting state information. Product Line TAC IA Series Environment Niagara R2(all versions) Cause The discrepancy occurs because some third-party manufacturers define SNVT_State bits starting from bit15 on the left, counting down left to right. In contrast, the Dynamic DEMUX object assigns bits from bit0 to bit15, with bit0 on the left and counting left to right. Resolution Understand the bit assignment logic used by the Dynamic DEMUX object: For example, a SNVT_State value of 1000 hex equals 1000000000000000 in binary. The DEMUX object interprets this as bit0 ON. If third-party documentation indicates bit15 ON for the same value, this is due to their reversed bit numbering convention. Once this difference is understood, interpret DEMUX output bits accordingly.

Issue Users want to know if a Niagara R2 UNC-520 can send a soft or hard reboot command to MNB controllers without using additional tools. Product Line TAC IA Series Environment Niagara R2 MNB controllers Cause Niagara R2 does not support sending reboot commands directly to MNB controllers. This limitation exists because reboot functionality is not exposed through the Niagara R2 framework for these devices. Resolution A reboot command cannot be sent from a Niagara R2 station to an MNB controller. To perform a soft or hard reboot, use the WorkPlace Commissioning Tool. There is no alternative method within Niagara R2 for this operation.

Issue Users cannot log into JACE-603 or JACE-645 hardware using the I/A Series R2 Admin Tool. Product Line TAC IA Series Environment JACE-603 JACE-645 Cause The JACE-603 and JACE-645 controllers are based on the QNX platform and do not support host-level configuration via the R2 Admin Tool. These devices require platform configuration through Niagara G3 tools when licensed accordingly. Resolution Use I/A Series G3 Workbench 3.6.47 or later for all host (platform) configuration of JACE-603 and JACE-645. For integration with I/A Series R2, refer to the Retrofit Board Niagara R2 Install and Startup Guide included with I/A Series G3 (document: docRetrofitBoardR2) version 3.6.47 or later. Supported revisions: R2: 2.301.535 or higher G3: 3.6.47 or higher

Issue Clarification on whether the oBIX service in I/A Series R2 requires the web services license feature to operate. Product Line TAC IA Series Environment I/A Series R2 oBIX Cause There is confusion regarding licensing requirements for enabling oBIX functionality in I/A Series R2 stations. Resolution The web services license feature (webUi) is not required to run the oBIX service in an I/A Series R2 station. However, the R2 license must include the obix feature for the service to function. Example feature line in the R2 license: features=coreRuntime;bacnet;lonworks;obix If the license does not include the obix feature, the service will not operate.

Issue An I/A Series R2 station fails to send BACnet alarms to a third-party system. The error log shows: tridiumx.bacnet.BACnetException: E_BACNET_UNRESOLVED_DEVICE_ADDRESS . Product Line TAC IA Series Environment I/A Series R2 BACnet Cause The station does not contain a BACnet device object for the target device. Without this object, the system cannot resolve the device address required for alarm routing. Resolution Ensure the station includes the BACnet device object for the target device. This object provides essential details such as IP address and device instance. Verify the target device is online and capable of receiving BACnet alarms. Use BACnetUtility and the learnNetwork command to create BACnet device objects for all target devices. Refer to the I/A Series R2 BACnet Integration Reference Guide (section: Configuring for BACnet Alarm Generation) for detailed steps. Additional Notes: Only Niagara objects exposed as BACnet objects (AIs, AOs, BIs, BOs, MSIs, MSOs) can generate BACnet alarms. Alarms are not regenerated if the BACnet device is offline during transmission. Enterprise Server cannot generate alarms for subordinate stations; each station must be configured individually.

Issue When attempting to modify the IP address of a Niagara R2 Enterprise Server using the Admin Tool, the new IP address values entered in the Network Settings tab are not saved. Product Line TAC IA Series Environment Niagara R2 Cause The Admin Tool’s Network Settings tab for a server station is read-only. Updating the IP address in Windows is sufficient; changes in Admin Tool are not required and will not persist. Resolution Configure the new IP address directly in the Windows network settings. Do not attempt to update the IP address in the Admin Tool Network tab, as it does not store changes for server stations. Treat the Network tab in Admin Tool as informational only for Enterprise Server configurations.

Issue A LON-USB adapter is configured as LON2 on a Windows laptop. Attempts to change its address to LON1 have failed. The Niagara R2 station running the LonWorks Service defaults to LON1. Can the station use LON2 instead? Product Line TAC IA Series Environment Niagara R2 station Windows laptop with LON-USB adapter Cause The LonWorks Service in Niagara R2 defaults to LON1 for the interface. The inability to modify the adapter address prevents direct use of LON2 without configuration changes. Resolution Open the Admin Tool in Niagara R2. Navigate to the Installation tab and locate the drivers.properties file. Modify the line: lon.deviceName=LON1 to: lon.deviceName=LONx where x is the desired port number (e.g., LON2). Save the changes and restart the station for the new configuration to take effect.

Issue What port is used for the Niagara R2 LON and Serial tunnel clients? Product Line TAC IA Series Environment Niagara R2 Cause Network configuration changes require port forwarding for tunneling. The correct port must be identified to allow communication through routers and firewalls. Resolution The LON and Serial tunnel clients use the same port as the UNC station. Default port: 80 If the station port is modified, the tunnel clients will use the updated port number.

Issue A FieldServer device was successfully commissioned in a Niagara R2 station using LON. However, the Lon Link Manager shows all related bindings with a status of service_type_error , and none of them will bind. Product Line TAC IA Series Environment Niagara R2 station with LON integration using FieldServer device Cause Most FieldServer devices using LON require a different service type than the default standard binding type. Using the incorrect service type prevents successful binding. Resolution Change the binding type from standard to critical in the Lon Link Manager, then attempt to bind the devices again.

Issue Can a JACE-NXT controller that was originally installed with Niagara R2 be cleared and re-installed with Niagara G3 for a site upgrade? Product Line TAC IA Series Environment Niagara R2 Niagara G3 JACE-NXT Cause The site is upgrading from Niagara R2 to Niagara G3, requiring confirmation of compatibility and installation steps for JACE-NXT hardware. Resolution Yes, it is possible to reinstall Niagara G3 on a JACE-NXT previously running Niagara R2: Connect via Remote Desktop to access the internal Windows desktop of the JACE-NXT. Install Niagara G3 as you would on any Windows-based system. Check storage type: If the JACE-NXT has a hard drive, there is sufficient space for G3 installation. If it has a flash drive, space is limited. You may need to completely remove Niagara R2 before copying and installing G3 files. Purchase and apply a Niagara G3 license for the unit. Note: Tridium does not provide an upgrade service for this process. It is a manual, do-it-yourself task.

Issue In a Niagara R2 station with two ASD services configured, serial tunneling only works for one service. Attempts to enable tunneling on both services fail. Product Line TAC IA Series Environment Niagara R2 version 522 or higher ASD integration with two ASD services Cause Niagara R2 does not support simultaneous tunneling for multiple ASD services. When tunneling is enabled on both, only the first ASD service establishes a tunnel connection. Resolution Enable tunneling on one ASD service at a time. If tunneling was previously enabled on both services, disable tunneling on the second service. Perform a station restart to apply changes.

Issue Changing the time zone in G3 Platform Administration does not update the time zone in the I/A Series R2 station running on a JACE-645. Product Line TAC IA Series Environment JACE-645 running I/A Series R2 G3 Platform Administration used for configuration Cause The time zone setting in G3 Platform Administration does not automatically update the time.properties file for the R2 station on the JACE. Resolution Manually update the time.properties file on the JACE: In G3 Platform, open File Transfer Client and navigate to /niagara/niagaraR2/sys . Transfer the time.properties file to your PC. Open the file in a text editor (e.g., Notepad), edit the time zone, and save changes. Transfer the updated file back to the JACE using File Transfer Client. Reboot the JACE and confirm the time zone change in the R2 station. 5. Open the station with R2 and confirm the time zone has been altered as desired.

Issue When starting an I/A Series R2 station on a JACE-603 or JACE-645 platform, the system displays ENGINE WATCHDOG TIMEOUT STACK DUMP and App Failed. Rebooting the station does not resolve the issue. Product Line TAC IA Series Environment I/A Series R2 I/A Series G3 JACE-603 JACE-645 Cause The failure occurs due to an improper implementation of JRE files required by the R2 mail service when the platform is commissioned with incompatible G3 distribution files. Resolution Perform a clean installation and commission the platform using I/A Series G3 version 3.6.47 distribution files. This ensures proper JRE compatibility and resolves the watchdog timeout issue.

Issue A Niagara R2 UNC station fails to start and displays the following error in the Standard Output window: FATAL: Cannot boot station from sns java.lang.NoClassDefFoundError: tridium/foundation/prism/Subscription Product Line TAC IA Series Environment R2 UNC Cause This error typically indicates corruption of the operating system or missing Java class definitions required for station boot. Resolution To recover the UNC: Reinstall the operating system (OS) on the UNC. Reinstall the Niagara R2 runtime environment (NRE) and required modules. Restore or redeploy the station after the OS and NRE are successfully installed.

Issue The JACE-645-R2 controller does not learn BACnet devices on its MSTP trunk and displays the following error in the Application Director: devctl rx frame failed: No error java.lang.RuntimeException: mstp rcv failed at tridium.nre.qnx.mstp.QnxMstpDriver.rcvFrameJNI(Native Method) at tridium.nre.qnx.mstp.QnxMstpDriver.access$0(QnxMstpDriver.java) at tridium.nre.qnx.mstp.QnxMstpDriver$MstpTrunkListener.run(QnxMstpDriver.java:287) at java.lang.Thread.run(Unknown Source) Product Line TAC IA Series Environment JACE-645-R2 retrofit board (TRD-RB-645) G3 version 3.8.37 Cause The issue is caused by a problem with the platform drivers in G3 (version 3.8.37) that interface with R2, resulting in MSTP communication failure. Resolution Perform a clean installation using: G3 version: 3.6.47 Commissioning tool: 3.6.406 This resolves the MSTP driver compatibility issue and restores BACnet device learning functionality.

Issue How to determine which MNL controllers (profile and version number) are integrated with a Niagara R2 or Niagara G3 station. Product Line TAC IA Series Environment Niagara R2 or G3 station with LonWorks integration Cause Users need a quick reference to confirm controller profiles and version numbers for compatibility and troubleshooting during integration. Resolution Use the LonWorks Device Manager in Niagara to list connected MNL controllers and cross-reference them with the table below: Controller Model Profile Version Notes MNLRF103 SIEBE 80:0:16:50:14:4:4:1 – MNLRF2 SIEBE 80:0:16:50:14:4:4:2 Version 2 MNLRF3 SIEBE 80:0:16:50:14:4:4:3 Version 3 MNLRH103 SIEBE 80:0:16:50:33:4:4:1 – MNLRH2 SIEBE 80:0:16:50:33:4:4:2 Version 2 MNLRH3 SIEBE 80:0:16:50:33:4:4:3 Version 3 MNLRR103 SIEBE 80:0:16:50:1e:4:4:1 – MNLRR2 SIEBE 80:0:16:50:1e:4:4:2 Version 2 MNLRR3 SIEBE 80:0:16:50:1e:4:4:3 Version 3 MNLRS1 SIEBE 80:0:16:50:1e:4:4:10 Satellite 1 MNLRS2 SIEBE 80:0:16:50:1e:4:4:11 Satellite 2 MNLRS3 SIEBE 80:0:16:50:1e:4:4:12 Satellite 3 MNLRS4 SIEBE 80:0:16:50:1e:4:4:13 Satellite 4 MNLRV2 SIEBE 80:0:16:50:a:4:4:9 Version 2 MNLRV3 SIEBE 80:0:16:50:a:4:4:a Version 3 MNOTPVA3 SIEBE 80:0:16:50:a:4:4:8 – SiebePEC SIEBE 80:0:16:50:1e:4:4:0 – Tip: Ensure the LonSiebe JAR file is installed in Niagara for proper profile recognition.

Issue Can BACnet alarms generated in Niagara R2 be sent to and acknowledged from a Niagara G3 (AX) Server console? Product Line TAC IA Series Environment Niagara R2 UNC Niagara G3 ENS Cause Users need the ability to view and acknowledge BACnet alarms originating from Niagara R2 within a Niagara G3 console for integrated alarm management. Resolution This integration is possible by configuring the BACnetRecipient object in Niagara R2. Follow these steps: Refer to the “Configuring for BACnet Alarm Generation” section in the R2 BACnet Integration Reference Guide. Add the G3 station as a BACnet device under the R2 BACnetService. Add the R2 UNCs as BACnet devices under the G3 NiagaraNetwork. Tip: The most common oversight is failing to add the G3 station as a BACnet device in R2.

Issue When accessing I/A Series R2 or G3 station graphics via a web browser, graphics fail to load or repeated Java security warnings appear. Common symptoms include: “Application Blocked by Security Settings” “Your security settings have blocked an application from running with an insecure or expired JRE.” Popups warning of security vulnerabilities for each Java applet. In Firefox: “This plugin has security vulnerabilities. Click here to activate the Java(TM) Platform SE Plugin.” Product Line TAC IA Series Environment I/A Series R2 I/A Series G3 Cause Oracle introduced stricter Java security controls starting with Java 7 Update 11 and further tightened them in Update 51 and later. Unsigned or self-signed applets are blocked by default. Known vulnerabilities in older Java versions trigger warnings. Browser plugins (IE, Firefox) enforce additional security prompts. Resolution Several approaches exist depending on site security policy: Option 1: Use Java Exception Site List (Recommended for Java 7u51+) Open Control Panel → Java → Security. Ensure Security Level is High (or Medium if required). Click Edit Site List… → Add. Add URLs for all I/A Series servers and controllers: http://<EnterpriseServer-host-or-IP> http://<UNC-or-JACE-host-or-IP> Confirm changes and restart browser. Option 2: Adjust Java Security Level (Legacy Workaround) For Java 7 Update 17 or earlier: Open Java Control Panel → Security tab. Set Security Level to Medium or Low (not recommended for high-security environments). Restart browser. Option 3: Downgrade Java (Last Resort) Testing shows Java 7u9 does not trigger prompts in IE9. Downgrade only if site policy allows and system is isolated. Option 4: Browser-Specific Workarounds Internet Explorer: Click Run on each security prompt. Firefox: If warning “This connection is untrusted”, click I Understand the Risks. To suppress plugin warnings (not recommended): Enter about:config in address bar. Set extensions.blocklist.enabled to false. Option 5: Clear Java Cache If graphics fail to load after bypassing warnings: Open Java Control Panel → General tab → Temporary Internet Files → Settings. Uncheck Keep temporary files on my computer. Click OK and restart browser.

Issue Niagara R2 Enterprise Server stations may experience slow startup or performance issues due to excessive historical alarms stored in the database. Users need methods to remove alarm history or the alarm file to restore normal operation. Product Line TAC IA Series Environment Niagara R2 Enterprise Server Cause Accumulation of alarms and logged data in the station’s database increases boot time and impacts performance. The alarm archive file and associated historical data can grow significantly over time. Resolution There are two main approaches to clear alarms and logged data: Method 1: Delete the APP Folder (Complete Removal) This method removes all archived data, including alarms, logs, and events. Steps: Stop the Niagara Service: Open Control Panel → Administrative Tools → Services. Locate Niagara, right-click, and select Stop. Delete the APP Folder: Navigate to: C:\Niagara\stations\[station name]\app Delete the app folder. Restart the Niagara Service: Return to Services, right-click Niagara, and select Start. Result: The station will recreate the APP folder and Cloudscape structure on restart. All archived data, including alarms, will be cleared. Method 2: Use SQL Queries via appdb/queryForm Servlet (Selective Removal) This method allows targeted deletion of alarm history without removing all logged data. Steps: Open a browser and navigate to: http://[ipaddress]/appdb/queryForm Enter and execute the SQL query: delete from event.eventhistory Repeat for other tables if needed (refer to SQL_Tutorial\QueryExamples_10_6_04.pdf for examples). Note: This process may take time depending on database size.

Issue The following error appears in the Niagara R2 UNC Standard Output Window: Duplicate Server Sessions – kill [Station Name] Product Line TAC IA Series Environment Niagara R2 Cause This error typically occurs when another station running on the Enterprise Server has the same name as the UNC station. Running multiple stations with duplicate names creates conflicts in session handling. Resolution Verify Station Names Ensure that each station running on the Enterprise Server has a unique name. Stop Duplicate Station Use the Admin Tool to stop the station on the Enterprise Server that shares the same name as the UNC station. Best Practice Avoid running multiple stations on the same Enterprise Server unless absolutely necessary. Under normal circumstances, only one station should be active to prevent conflicts.

Building Automation Knowledge Base

Improve your search experience:

Related Forums

Intelligent Devices Forum

Dynamic DEMUX Object in R2 LonWorks Jar Displays Incorrect Bit Mapping for SNVT_State

Can Niagara R2 Send a Soft or Hard Reboot Command to MNB Controllers?

Unable to Log into JACE-603/645 Using I/A Series R2 Admin Tool

Does oBIX Service in I/A Series R2 Require Web Services License?

I/A Series R2 BACnet Alarm Fails with E_BACNET_UNRESOLVED_DEVICE_ADDRESS

Niagara R2 Enterprise Server IP Address Change Not Retained in Admin Tool

Niagara R2 LON-USB Adapter Configuration for LON2 Interface

Niagara R2 LON and Serial Tunnel Client Port Configuration

FieldServer LON Device Binding Fails in Niagara R2 – Service Type Error

Reinstalling Niagara G3 on JACE-NXT Previously Running Niagara R2

Niagara R2 ASD Integration – Serial Tunneling Works with Only One Service

JACE-645 R2 Time Zone Change Not Reflected in Station

ENGINE WATCHDOG TIMEOUT and App Failed on JACE-603/645 with I/A Series R2

R2 UNC Station Fails to Boot – Error: FATAL: Cannot boot station from sns java.lang.NoClassDefFoundError

JACE-645-R2 Fails to Learn BACnet Devices on MSTP Trunk – Error in Application Director

Identify MNL Controller Profiles and Versions Integrated with Niagara R2 or G3

Niagara R2 BACnet Alarms: Sending and Acknowledging from G3 Server Console

I/A Series R2/G3 Web Graphics Blocked or Security Warnings After Java Updates

Niagara R2 Enterprise Server – Clearing Alarm History and Alarm File to Improve Station Performance

Niagara R2 Error: “Duplicate Server Sessions – kill [Station Name]”

Ask our Experts

Email Us

Building Automation Knowledge Base

Related Forums

Ask our Experts

Email Us

Welcome!