Category: Tridium

Posted on

Using Trend IQLvav Controllers in Niagara

Trend Lon controllers typically installed in “Trend” mode which self-install on a Lonworks system and use standard Lan / outstation numbers as any of the other Trend modules. Devices are typically software addressed with an LCI and IQLtool built into SET. This works well but requires a Trend 3Xtend or the newer Xtend module to route Trend Lon devices on to Ethernet or current loop networks.

Trend’s default addressing scheme on Lon translates as follows:

  • Domain Table = 1
  • Domain Length = 1 byte & ID 255 or FF hex
  • Subnet = 255 – Trend Lan number (1,4-119 are valid Lan numbers)
  • Node = Trend outstation number (1,4-119 are valid outstation numbers)
  • Message Code = 64
  • Domain Wide = domain wide
  • Router Buffer Size = 146 bytes

If the IQL has the above settings, it will still communicate with the Xtend and the standard tools. This is the case, even if its Lon managed.

Consequences of switching to Lon managed

The IQLvav datasheet has all the points listed that convert directly to SNVTs. The main points that will no long be available are:

  • Airflow setpoints including K factor
  • Velocity pressure input and the ability to zero it
  • Damper, hot water positions and electric heat outputs
  • Alarm input
  • Damper override settings

The airflow setpoint is also a temp SNVT which cannot be directly converted within the point setup in Niagara. Connect a multiple block and multiply this reading by 2.119 to convert to cfm.

Pulling the IQLvav into Niagara

The easiest way to bring these in first figure out how the controllers are addressed and setting the Jace Lon domain length and ID to match the existing controllers. In most cases it will be the defaults from above. To verify this, right click on the Lon network and choose Lon Utilities view, then pick identify and hit the service pin on one of the modules.

Service PIN output of IQLvav

In this example the IQLvavs subnet is 230 which is Trend Lan 25 (255 – 25 = 230) and Outstation 30. We can see the domain length is 1, domain ID is 255 which is what we need to set the Jace for in order to discover the rest of the devices. Right click on the Lon network, open its property sheet and expand the Lon Netmgmt. Set the domain length and ID to match what was discovered with the service pin.

Niagara Lon network setup matching Trends default settings

After saving this, you should be able to open the Lon network and discover the IQLvavs.

Niagara Lon discovery of IQLvavs

At this point you can drag in the discovered devices. In order to get all the point names, you need either the devices XIF file or already converted an XIF into the LMNL format that Niagara uses. XIF files can be converted under Tools – Lon XML Tool. Links to both formats below.

When you drag the device down into the database, assign the attached LMNL file in the add window.

Adding an LMNL file to a newly discovered device

You can now import points, readdress and commission the devices as any other Lon device. Keep in mind if you change the domain length or ID from the default, they will no longer communicate with the Extend, LCI, SET, etc. IQLtool will not be able to address IQLs that have been Lon managed unless they are switched back to their default mode.

Returning a Lon managed IQLvav back to its default Trend mode

If you have changed from Trend’s default addressing and need to adjust the settings that are no longer available, you will need to restore them in order to connect with an LCI & SET. Change the domain length back to 1 and the domain ID back to FF if these have been changed. Upload the device by right clicking on the device Actions – Upload. Then select the nc Manager view. In that window change the nciNetConfig to cfgNul. Then download the change by right clicking on the device Actions – Download.

Niagara nc Manager view

At this point the IQL will reset and will communicate with the standard Trend tools. Note that the address will default to Lan 1 Outstation 1.

Additional notes

Never change nviSecurityCode under any circumstance. This is a copy protection scheme that is used with nvoGenerator. If the security code is changed from its factory value the controller will cease to process it program. It will still communicate, but nothing will function. These controllers are no longer supported, so don’t expect factory support to recover from this.

Posted on

Tridium Releases Niagara Security Updates

Tridium released updates for the Niagara AX & N4 platforms this week that patch security vulnerabilities, including critical JVM vulnerabilities. Without mention which versions of AX/N4 are effected, one can only assume all prior versions. When asked for more details, Tridium said Windows based hosts are at the highest risk and they are not aware of active exploits in the wild currently. That being the case, at a minimum all Windows based supervisors and soft Jaces should be patched as soon as possible.

This brings AX to version 3.8.401 and N4 to version 4.4.92.2.1. Vykon branded platforms have this available now, third party channels will lag behind to vary degrees. Unfortunately without any further details, there is no mitigations other than patching. If your channel is behind the current release version, waiting or switching brands is the only option. If this is the case, please help move the industry forward and make your concerns known to the vendor. Customers shouldn’t have to wait months for critical security updates.

Official Announcement

7/12/18 Update

Another update may be forthcoming shortly.

8/19/18 Update

Official ICS-CERT announcement.  Disabled accounts seem to be central to this bug which may allow for remote code execution.  The CVE links seem dead as of today.

8/30/18 Update

Scanning on the open internet for exposed Tridium system increases. 

Coincidence, I think not.  If you must expose your system to the internet, its past time to update.

 

 

Posted on

Mass Export of Niagara Histories to CSV Files

Yet another way to export Niagara histories, this time with a program object. This object will convert every history within a station to a individual CSV file. In AX, these are located in the historyExports folder under the station home directory. In N4, these will be located in /shared/historyExports/ under the station home. Keep in mind, running this on a Jace may cause the station to run out of disk space. Depending on the number and length of the histories this process can take a few minutes.

When the object is executed, it locates all the histories within the station its ran on. One by one these are converted to CSV and saved as individual files. File names will be the history name with special characters escaped. If their are histories from multiple stations, individual folders are created per station under the export folder. Each CSV file will contain the timestamp and value of the full history time frame. Values are just the numeric portion, no units. This makes it easy to use within excel if you need to preform math functions on them. The status slot of the object will display the current history being exported as it runs. Once complete it will contain a total number of histories exported.

Giving credit where do, this code originally came from the Niagara Central Community. The post there was for AX only, hard to find and didn’t clearly cover all the steps needed to implement a working object. Hopefully this will clear up the finer details. Tested under AX3.8 & N4.3.

N4 Program Object Code
AX Program Object Code

Changing the references to getProgram to getComponent are the only differences in code between AX & N4. Some of the package names also vary slightly.

Posted on

Using export tags within the Niagara platform.

Setting up export tags within the Niagara platform.   Complete folder structure, points and histories can be imported automatically saving labor and mistakes over manually importing into the supervisor.  This also allows reuse of graphics within the Jace since the structure and naming is duplicated within the supervisor.