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

1684 Posts | First Used: 2018-09-06

Building Automation Knowledge Base

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.

Issue How can it be determined which LonWorks Program IDs are supported by the Niagara R2 system? Product Line TAC IA Series Environment Niagara R2 LonWorks Cause Users need to identify supported LonWorks Program IDs for integration and compatibility checks within Niagara R2. Resolution Create a Test Station Install a test station on the localhost that includes: LonWorks Service LonWorks Network container LocalLonDevice Access Lon Utilities Manager Open the test station in WorkPlace Pro. Right-click on the LonWorks Service and select Lon Utilities Manager. Run Program ID Report Select LocalLonDevice. Choose Command of Reports and Sub-command of programids. Execute the command to generate a listing of all Program IDs for shadow objects in the local tridiumx library (lonDevices container). Save and Search Save the report as a text file. Import into Excel for easy searching and filtering. Update When Needed Re-run the report whenever a new Lon JAR file is added or an existing Lon JAR file is updated.

Issue Clarification on linking rules within the Niagara R2 platform and restrictions when linking objects between stations. Product Line TAC IA Series Environment Niagara R2 platform Cause Users need guidance on correct linking practices to ensure proper functionality and avoid unsupported link types. Resolution General Linking Rules Properties must share the same data species for a valid link. A link connects one object's output to another object's input. The Link Editor enforces these rules during selection. Exceptions for Gx Objects Gx objects (e.g., GxText) have only inputs and can link to internal configuration properties or most outputs. These links are UI links, not part of control logic, and are used for interface display. Multiplicity Rules One-to-many: Multiple inputs can link to a single output. Many-to-one: Only allowed for priorityArray or triggerType inputs (or certain Lon properties). External Link Restrictions (Between Stations) Links between prioritizedOutputs and priorityArray inputs are not permitted. Links involving triggerType data species are disallowed. GxText objects cannot link to internal properties of another object externally (only inputs/outputs are available).

Issue Duplicate LON device node numbers detected in a Niagara R2 UNC station, preventing successful commissioning of controllers. Product Line TAC IA Series Environment Niagara R2 UNC station LonWorks Service Workplace Pro Cause When a LON device is relocated from one site to another, it may retain its previously configured subnet and node number. If these values match an existing device in the new installation, a duplicate address conflict occurs during commissioning. Resolution Follow these steps to resolve duplicate node numbers: Open Lon Device Manager from the right-click menu of the LonWorks Service. Click Find to list all LON controllers under the UNC. An error message will indicate duplicate subnet and node numbers. Right-click one of the devices with the duplicate address. If no menu appears, try another device with the same subnet and node number. Select Properties → General tab → Engineering tab. In Node State, choose Unknown. Change the NodeID to a unique value not currently in use. Click Apply to save changes. Return to the Device List screen and reselect the modified device. Click Commission and verify the Neuron ID in the pop-up window. Click Apply and wait for commissioning to complete. Repeat steps 3–10 for any additional devices with duplicate addresses.

Issue Confusion exists around which MicroNet controllers are supported in EcoStruxure Building Operation (EBO), especially during upgrades to EBO 7. The term “MicroNet” covers multiple product families with different protocols and support timelines. Product Line EcoStruxure Building Operation, TAC IA Series, Satchwell MicroNet Environment EcoStruxure Building Operation (EBO) MicroNet 2000 (NW8000) I/A MicroNet (MNL and MNB) Satchwell MicroNet Cause The term “MicroNet” can refer to multiple unique product ranges. In EBO documentation, MicroNet typically refers to Satchwell MicroNet, the European range of controllers using NCP, ARCnet, or LON protocol, which are not supported from EBO v4.0 onward. Other MicroNet families (MicroNet 2000 and I/A MicroNet) have different support histories. Resolution Refer to the table below for family types, lifecycle dates, and EBO support history: Family Protocol Introduced Withdrawn EBO Support History MicroNet 2000 (Barber Colman) MNet under ASD Late 1980s 2011 Supported up to EBO v3.2 Not supported in EBO 4.x–6.x Reintroduced in v7.0 I/A MicroNet – MNL Series LonWorks ~1998 2023 Supported in all SBO/EBO versions I/A MicroNet – MNB Series BACnet ~2003 2023 Supported in all SBO/EBO versions Satchwell MicroNet NCP / ARCnet / LON ~1998 2013 Supported up to EBO v3.2 Not supported from EBO v4.0 onward Additional Notes: MicroNet 2000 support was reintroduced in EBO 7 after being dropped in EBO 4–6. I/A MicroNet (MNL and MNB) support has never been removed from EBO. Satchwell MicroNet is unsupported from EBO v4 onward.

Building Automation Knowledge Base

Improve your search experience:

Related Forums

Intelligent Devices Forum

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]”

Determine Supported LonWorks Program IDs in Niagara R2 System

Linking Rules and External Link Restrictions in Niagara R2

Correcting Duplicate LON Device Node Numbers in Niagara R2 UNC Station

MicroNet Families: Lifecycle and EBO Support History

Ask our Experts

Email Us

Building Automation Knowledge Base

Related Forums

Ask our Experts

Email Us

Welcome!