SCHNEIDER ELECTRIC

R2 Migration Guide

Best Practices
Guide
 SCHNEIDER ELECTRIC

Best Practices Guide

 Schneider Electric
Boston One Campus
800 Federal Street
Andover, MA 01810
USA
Phone 1-978-975-9765

10/3/2017Julio Cortes
Table of Contents
R2 Migration Introduction ......................................................... 1
Purpose of this Guide...................................................................... 1
Intended Audience .......................................................................... 1
UNC Database and Network Analysis ...................................... 1
UNC Resources .............................................................................. 1
UNC CPU Idle status Procedure ..................................................... 1
UNC Low CPU Idle Adjustment Procedure ..................................... 3
Resource Count Status procedure .................................................. 3
UNC resource Count Adjustment Procedure .................................. 5
UNC Error Log Service / Log Table ................................................ 5
Interpretation and Correction of Errors ............................................ 5
Protocols Supported ................................................................. 8
BACnet............................................................................................ 8
BACnet Network Analysis ............................................................... 8
BACnet Network Analysis Procedure .............................................. 8
Interpretation and Correction of Errors ............................................ 9
LON Network Analysis .................................................................. 12
LON Network Analysis Procedure ................................................. 12
Interpretation of Device Status Display ......................................... 13
Definition of Heart Beats ............................................................... 16
Suggested Values ......................................................................... 17
Tips and Time Savers ............................................................ 19
MNB Device Preparation:.............................................................. 19
AS BACnet Interface ..................................................................... 21
IP/MSTP Network Settings............................................................ 24
IP/MSTP Network Settings............................................................ 25
COV versus Writes........................................................................ 27
Alarms and MNBs ......................................................................... 27
Trends and MNBs ......................................................................... 27
Script / Function Block Programs and I/A...................................... 28
MNB/MNL Native .......................................................................... 28
 MNL Device Preparation ............................................................... 29
Third Party LON Devices .............................................................. 29
AS LON Interface .......................................................................... 30
Bandwidth Throttling ..................................................................... 32
Alarms and MNLs ......................................................................... 33
Trends and MNLs ......................................................................... 33
Program Objects ........................................................................... 35
Niagara Objects ............................................................................ 36
Graphics........................................................................................ 37
Migration Tool ............................................................................... 40
Automation Server Database and Network Analysis .............. 41
Tasks ............................................................................................ 43
Trace Files .................................................................................... 45
Diagnostic Tools..................................................................... 48
Expert Tool.................................................................................... 48
WireShark ..................................................................................... 49
BACnet MSTP Cap ....................................................................... 50
WireShark BACnet Layers: ........................................................... 56
WireShark Filter Expressions: ....................................................... 56
BACnet Statistics .......................................................................... 57
How to Extract an XIF with NodeUtil ............................................. 59
Loytec LPA Analyzer ..................................................................... 63
Appendix ................................................................................ 75
ASD Driver Comparison ................................................................ 75
Collaborators ................................................................................. 76
S C H N E I D E R - E L E C T R I C

R2 Migration Introduction
Purpose of this Guide
The intention of this guide is to assist with the necessary steps and troubleshooting to complete the R2
migration process from an existing R2 Universal Network Controller (UNC) database to SmartStruxure
Automation Server.

Intended Audience
Schneider Electric Branches and authorized partners

UNC Database and Network Analysis

UNC Resources
Prior to migrating the UNC database it will be important to identify how well the existing database is
performing with the current programming and networks connected directly to the Universal Network
Controller (UNC). This can be done by checking the UNC CPU idle, Resource Count, and Error Log.
Failure to correct issues with the current system will mean the issues will most likely continue to exist under
SmartStruxure.

UNC CPU Idle Status Procedure

You can also refer to Lessons Learned Article #11017.

1. Open Internet Explorer browser

2. Enter the following:
Example: http://192.168.1.1:3011/system/spy in the address section of the web browser. .
3. Login using the admin tool user name and password
4. Once the page is available scroll to the bottom of the page, read and record the current Idle. The
idle represents the current CPU utilization.
5. It is always a good practice to reset the counters to make sure the idle reading is accurate. Click
on the Reset Counters link
6. Wait a minimum of 45 seconds for the counters to be updated before clicking the link to return to
the spy statistics screen.
7. If the idle is below 20%, the UNC will be slow or sluggish. Another symptom of low idle is
devices will be marked online or offline.

1
2
UNC Low CPU Idle Adjustment Procedure
The goal of this procedure is to increase the CPU Idle % to or above 30%.

1. Increase the Update Time of the UI Engine Service from the default of 500 ms to a value in
the range of 2500 to 5000 ms. This value controls the update frequency of point values on
the WorkplacePro and Graphic screens, both locally and via web browser access.
2. Before proceeding to the next step check the CPU Idle to see if the changes have increased
the CPU Idle. If the CPU Idle is still under or in the 20s percent range proceed to the next
step.
3. Increase Control Engine Service execution frequency times. If existing objects were left at the
default (normal) changing the default execution time of two seconds to 4 seconds will provide
a significant improvement.
4. Before proceeding to the next step check the CPU Idle to see if the changes have increased
the CPU Idle. If the CPU Idle is still under or in the 20s percent range proceed to the next
step.
5. Review the number of custom program objects in any case where the station contains more
than the recommended 80 maximum number of program objects, an effort should be made
to reduce the number of program objects. The execution time can be increased as much as
possible.
6. If the CPU Idle has not increased after performing all these changes please contact Product
Support.

Resource Count Status procedure

1. Type the address of the station in the address bar.

http://192.168.1.1/prism/resources
2. Login using the user name and password for the station running in the UNC
3. When the page opens check the Total Objects count. The object count should be less than
600,000.
4. This page will also show the amount of resources per Children
5. Each Child will show the amount of resources and percentage.
6. By clicking on each child, you will be able to define which objects are taking the highest
percentage compared to other objects inside that child.

3
4
UNC resource Count Adjustment Procedure
The goal of this procedure is to ensure the UNC is fewer than 600,000 resources or decrease the total
objects in the UNC database.

1. Click on each child and determine which objects have the highest percentage.
2. If possible, reduce the object count by deleting objects inside devices that are not being used
by the database to lower the object count.
3. UNCs should only have 80 program objects in their database
UNC Error Log Service / Log Table
The error Log table will give you additional information to help you diagnose the existing problems in the
Niagara network or UNC database. It is always best to do this in the analysis stage to prevent issues in the
Automation Server.

Interpretation and Correction of Errors

1. Time Synch aborting not all servers responded:

• Problem: The Time Synch Service is not properly configured

• Action: Time Synch Servers or Clients have changed and or IP is incorrect. LL#13718

2. Lost sync time system clock resetting control engine:

• Problem: The control engine service is resetting every eight days to adjust the local
time. This means the local time is drifting and can have a negative impact on Alarms,
Schedules, and Trends.

• Action: Time Synch Servers or Clients are not configured properly.

3. Subscription Error

• Problem: The UNC or Enterprise Server may have network issues and may be timing
out when trying to connect. If this is a network issue it may become a problem under
SmartStruxure

• Action: Check all links or connections with http://IPAddress/prism/externalLinks

5
Example of Session: DxExchange Connection error under the Sessions link.

6
If you were not able to check the error log on site, you can open the database xml and search for errors. It
is always best to open the Error Log when you are on site with a live system. Some of the errors may no
longer exist in the actual job site.

7
Protocols Supported
The R2 Transition tool will focus on the implementation of BACnet IP/MSTP, LON, and ASD.

BACnet
UNCs can support BACnet IP, Ethernet and MSTP. SmartStruxure does not support BACnet Ethernet.
A BACnet/IP to BACnet Ethernet router or the UNC will have to be left in place to continue the support
of BACnet Ethernet devices. If an MNB-1000 is available under the MSTP trunk it can be promoted to
support the IP and Ethernet networks.

BACnet Network Analysis

The Standard Output Window provides real time diagnostics of what is currently happening with all running
drivers. Reviewing the BACnet trunk/s activity through the Output window is recommended prior to
starting the conversion process. MSTP and BACnet /IP captures will also help analyze the current
bandwidth or errors that may exist on the network.

BACnet Network Analysis Procedure

The goal of this procedure is to ensure any BACnet issues are corrected prior to the transition process.

1. Open Admin Tool and login to the UNC (prior to opening the Standard Output Window we
will increase the amount of rows to increase the amount information displayed inside the
window)
2. In the Main Menu click Admin Tool
3. Select options under the drop down menu

4. Set rows to 2000

5. Click the icon for the Standard Output Window or right Click the name of the station in the
Admin Tool area to open the Standard Output Window

8
 6. The Standard Output Window will show in real time any activity between the UNC and
BACnet devices. In the example above you can see the following errors:
• Transaction Time Out
• Read Multiple Error
• Write Property Fail

Interpretation and Correction of Errors

4. Transaction Time Out Error(Problem):

9
 • Problem: The device may be physically down and is unable to respond or the device
did not respond to a system status ping and is now reported as being down. The System
Status property is executed as a confirmed request and the device may not be
responding in the time specified in the APDU Timeout.

• Action: if the device has lost power or the communication cable has been damaged.
Replace the wire or troubleshoot power. If the device is not down it may be necessary
to increase the APDU timeout of the UNC. Refer to answer below.

• Problem: is the result of exceeding the amount of time specified under the APDU
Time Out property for an expected reply.

• Action: the APDU timeout should be set to the same value on the entire BACnet
network. MNB devices default to a value of 6,000 and UNCs default to 3,000 change
the value to 10,000 on the entire network. Prior to making a change check the
Advanced properties of the troubled MNB in Commissioning Tool and check the
APDU Timeout Count. MNB devices record the number of retransmissions that have
not received an acknowledgement. If the Timeout Count still shows retransmissions
after the increase time it may point to a bandwidth issue. A capture may be required to
proceed with troubleshooting. Please check the MSTP capture or WireShark capture
procedure under diagnostic tools.

5. Read Property Multiple Error (Problem):

• Problem: the service is not supported by the BACnet device/s or may have exceeded
the APDU Timeout.

• Action: SmartStruxure should automatically default to Read Property service if the

problem persists check the PICS statement of the particular device. If the service is
supported it may require an increase of the APDU Timeout of the device.

6. Write property Fail (Problem):

• Problem: the object does not support the Write to property service.

• Action: Check the Protocol Implementation Conformance Statement (PICS) of the

particular device. If the service is supported it may require an increase of the APDU
Timeout of the device.

• Problem: the object supports the Write to property service but Write Property Fail
error is still present in the Standard Output Window.

• Action: The Write Property Service is a Confirmed Service and requires an

Acknowledgement after receiving the Write to property request. If the device is under
a large network and the default APDU Timeouts are unchanged. It will be necessary
to change the APDU Timeout to a higher value. Start with 10,000 across the entire
BACnet network. If MNB devices reside under the BACnet network check the APDU

10
 counter to help you confirmed the APDU Timeout has been changed to an acceptable
value.

7. The General/Engineering tab under the BACnet Service provides more debugging options
under the BACnet Service. Turning these options on or off will allow you to display detailed
information in the Standard Output window. Reference the R2 BACnet integration PDF.
MSTPcap or WireShark provide the same and sometimes more detailed BACnet information.
If it becomes necessary to further analyze any issues a half hour to an hour capture should help
you get started.

If problems persist, please call Product Support for further assistance

11
LON Network Analysis
The Standard Output Window provides real time diagnostics of what is currently happening with all running
drivers, it is important to review the network activity prior to starting the conversion process. LON network
captures will also help analyze the current bandwidth or errors that may exist on the network.

LON Network Analysis Procedure

The goal of this procedure is to ensure any LON issues are corrected prior to the transition process.

When analyzing the LON network first check the network by running the Transmit Errors No Clear under
the Lon Utilities Manager to see which devices are having the most issues on the network. The second step
is to run a Device Status Display to get detailed information.

The example below shows the result of a report named Transmit Errors No Clear. The report can provide
information on all of the devices that are part of the LON network.

12
The example below shows the status of the local LON Device (UNC). The Status Display report will
provide you with information to see how well the UNC is able to communicate with the rest of the LON
network.

The Screen shot below shows Transaction Timeouts at 622 and the retries at 1866. Which shows the
LONWorks service is set to three retries.

Interpretation of Device Status Display

Transmit Errors: Number of CRC errors detected during packet reception. These
are often due to collisions and /or noise.
Transaction Timeouts: The number of times that the node failed to receive expected
acknowledgements of responses after retrying the configured number of times. These may be due to
destination nodes being inaccessible on the network, transmission failures because of noise on the
channel, or if any destination node has insufficient buffers or receive transaction records.
Receive Transaction Full: Number of times that an incoming packet was discarded
because there was no room in the transaction database. This may be due to
excessively long receive timers or the receive buffers are too few.
Lost Messages: Number of times that an incoming packet was discarded because
there was no application buffer available. This may be due to an application program
being too slow to process incoming packets, insufficient application buffers, or to
excessive network traffic.
Missed Messages: Number of times that an incoming packet was discarded
because there was no network buffer available. This may be due to excessive network
traffic, insufficient network buffers, or to the network buffer size not being large
enough to accept all packets on the channel.

13
Reset Cause: Indicates why/how the node was last reset: power-on, external reset,
watchdog reset, software reset, or cleared.
Node State: Indicates the current state/mode of the node: applicationless and
unconfigured, unconfigured (but with an application), configured and hard off-line,
configured and soft off-line, configured and bypass off-line, or configured and
on-line.
Version Number: Reflects (or allows the calculation of) the original Neuron chip
firmware version number.
Error Log: The reason for the last error detected by the firmware on the node.
Neuron Chip model: Neuron 3150 or 3120.
Messages received by node: The number of good messages received by the node.
Not all messages are addressed to the node, but it does receive every message on the
wire. The maximum number of message counts is 65,000—once the count reaches
this value, it does not update. If you clear the display, you will see fresh data.
Messages addressed to node: The number of messages received by, addressed to,
and processed by this node.
Messages sent to MAC layer: The number of messages transmitted by this node.
These can include network variable updates, explicit messages, acknowledgements,
retries, reminders, service pin messages, and more.

Retries: The number of retry attempts that were needed to send a message
successfully (before an acknowledgement was received for a reliable message). If the
bandwidth of the network is low; the node should not have to re-send messages. But,
once the bandwidth starts creeping up and there are collisions, the node might have
to re-send messages.
Backlog overflows: The number of times the backlog reached its maximum value
of 63.
Late acks of responses: The number of acknowledgements or responses that
arrived at this node after the transmit transaction had expired.
Collisions detected: The number of CRC errors caused by collisions.
EEPROM lock: If this field is set, the checksum EEPROM on the node is
protected against memory writes.

14
Example of a network with high CRC errors
Table of lon device transmission errors.
=======================================================================================
Device Transmit Timeout ReceiveFull LostMsg MissedMsg LastError
---------------------------------------------------------------------------------------
localLonDevice 65535 8134 0 65535 210 no_error
VFD_93A 65535 0 0 0 608 no_error
VFD_93B 65535 0 0 0 697 no_error
VFD_99 18526 0 0 0 24 no_error
MNL_143_1_AHU99 4598 0 0 0 2 no_error
MNL_143_2_AHU99 4625 0 0 0 3 no_error
MNL_143_3_AHU99 4654 0 0 0 2 no_error
VAV99_1 2946 0 0 2 0 no_error
VAV99_2 2896 0 0 0 0 no_error
VAV99_3 3080 0 0 0 0 no_error
VAV99_4 3464 0 0 2 0 no_error
VAV99_5 3796 0 0 7 0 no_error
VAV99_6 3651 0 0 0 0 no_error
VAV99_7 3630 0 0 1 0 no_error
VAV99_8 3862 0 0 0 0 no_error
VAV99_9 3989 0 0 1 0 no_error
VAV99_10 4193 0 0 0 0 no_error
VAV99_11 4267 0 0 1 0 no_error
VAV99_12 4406 0 0 0 0 no_error
VAV99_13 4442 0 0 0 0 no_error
VAV99_14 4254 0 0 0 0 no_error
VAV99_15 3202 0 0 0 0 no_error
VAV99_16 2869 0 0 0 0 no_error
VAV99_17 3234 0 0 0 0 no_error
VAV99_18 2624 0 0 0 0 no_error
VAV99_19 2648 0 0 0 1 no_error
VAV99_20 2611 0 0 0 1 no_error
VAV99_21 2563 0 0 0 1 no_error
VAV99_22 2739 0 0 0 1 no_error
VAV99_23 2581 0 0 0 1 no_error
VAV99_7A 3790 0 0 0 0 no_error
=======================================================================================
Transmit - number of CRC errors detected during packet reception.
Timeout - number of times node failed to receive expected msg response.
ReceiveFull - number of incoming messages discarded due to no room in transaction db.
LostMsg - number of incoming messages discarded due to no app buffers.
MissedMsg - number of incoming messages discarded due to no net buffers.

Transmit errors are also an indication of high Bandwidth issues on the network. It is important to make
sure all devices under the UNC have the Send /Receive heartbeats, and nciMinOutTm set.

15
Before making, any adjustments to the NCIs make sure to upload all LON devices from Device
Manage. A Fetch command will not upload the NCI values.

Definition of Heart Beats

Send Heartbeat:

The Send Heartbeat, in conjunction with the Receive Heartbeat, defines the mechanism used to
ensure data integrity between two communicating devices (nodes). Accordingly, the Send Heartbeat
mechanism is applied to the node’s network variable outputs. The Send Heartbeat setting(s)
determines the maximum time interval (in seconds) that is allowed before a non-changing “bound”
NVO is sent on the active network. The Send Heartbeat function ensures that a value is
automatically sent to update a receiving node or group of nodes on a periodic basis, even when that
value remains unchanged for a length of time.

Receive Heartbeat:

The Receive Heartbeat, in conjunction with the Send Heartbeat, defines the mechanism used to
ensure data integrity between two communicating devices (nodes). Accordingly, the Receive
Heartbeat mechanism is applied to the node’s network variable inputs. The Receive Heartbeat
setting(s) determines the maximum time interval (in seconds) that is allowed before a non-updated
NVI is defined as “Out of Service.” This causes the appropriate programmed fallback to occur.

Minimum Output time:

The Minimum Output Time defines the minimum time interval (in seconds) between the sending of
each propagated NVO on the active network. The controller applies this interval to all “bound”
NVO’s. This parameter can also be described as the final “filter” applied to all NVO updates sent
from the controller.

16
Suggested Values
Send Heartbeat:

NVO 90 NVI
Send Receive
Heartbeat Heartbeat
=90 sec 180 =300 sec

270

In the example above the Sending Device Heartbeat is 90 seconds and the receiving device Heartbeat is 300
seconds this guarantees at least three updates within 5 minutes.
MNL 800s have four Heartbeats this allows you to set different NVOs to update at different times.

NVO A=9 NVI

Send Receive
Heartbeat B=100 Heartbeat
A=90 = 300
B =100 C=11
C= 110
D=120 D=12

In the example above, the sending device has its Heartbeats set to 10 seconds apart this guarantees at least
two updates within 5 minutes.

Receive Heartbeat:
The Receive Heartbeat should exceed the Sending Heartbeat in the example below the NVO should update
at least three times before the NVI will use the default values

NVO NVI
Send Receive
Heartbeat A=9 Heartbeat
=90 sec =300 sec

MNL 800s have four Receive Heartbeats. This allows setting different NVO Heartbeats to the matching
NVI Heartbeats.

NVO A=9 NVI

Send Receive
Heartbeat B=100 Heartbeat
A=90 = 300
B =100 C=110
C= 110
D=120
D=120

17
Minimum Output Time:

This is probably the number one culprit when dealing with high bandwidth issues like missed, lost
messages, and timeouts. The default value is 5 seconds in MNL controllers except the MNL 800 the
default minimum Output Time is 1 second. In the example below the sending Device has four NVOs
to send out to the receiving device it will send each value every 5 seconds in between with a total span
of 20 seconds. Setting the Minimum Output Time to a value of zero will have negative impact on the
network.

Sending Device 5 sec Receiving

NVOs device
MinOutTm 10 sec NVIs
=5
15 sec

20 sec

VAVs or non-critical devices should be set to a Minimum Output time of 5 to 10 seconds to allow
devices that require faster updates like MNL 800s that are sharing data to control a single Air Handling
Unit. In the example below, we left the Minimum Output Time to in the MNL 800 to one second
but used the Minimum Propagation Time to control the NVO from continuously updating and
creating unnecessary traffic. Controlling the individual points in the MNL 800 will provide you
flexibility when trying to decide critical from non-critical point updates.

Non – MNL Controllers should be checked to make sure they do not become disruptive devices on
the network. VFDs are usually the number one suspects on a multi -vendor network.

18
Tips and Time Savers
The purpose of this section is to focus on changes made to a database during the R2 migration process to
get the network up and running as quickly and efficiently as possible.

MNB Device Preparation:

Upgrade all MNB VAV, MNB-300, and MNB-70 devices to firmware 1.434 or higher. This will ensure all
communication improvements will be available. For Example, if the device is currently running 1.3 or older
firmware it may not support COV Subscriptions this means the UNC is polling data from all MNB devices.
This usually results in slow updates from graphics or overall performance of the UNC. The MNB-1000
should be at revision 1.515 or higher.

The pictures below shows MNB devices running under the UNC prior to the R2 conversion at an older
firmware that did not support COV subscriptions forcing the UNC to poll all the objects. The most
noticeable is address 5 it was overwhelmed with the amount of polling causing it to postponed messages.

19
The statistics below show a high amount of Read Property Multiples and writes. Prior to making any
programming changes or firmware upgrades.

20
AS BACnet Interface
Prior to importing your XML file make sure to set the time and date of the Automation Server. After
completing the XML import to the Automation Server, check the following properties/settings:

1. The Instance ID of the BACnet Interface in the Automation Server will have the same instance
ID of the UNC. If the UNC will remain in place to support BACnet Ethernet., The instance ID
of the UNC will have to be changed to prevent duplicate IDs on the BACnet network. If the
UNC will continue to support other protocols turn off the BACnet IP service.

21
2. The BACnet interface Advanced tab has a section called Protocol Settings. In this section, you
can change the APDU Timeout and number of APDU retries. If you have already taken care of
any APDU timeout issues these values should remain the same across the entire BACnet network.

3. Foreign device: If the UNC is set to support the Foreign Device option please check the BACnet
interface Foreign Device settings in the AS.

22
Advance Polling Configuration should be set to a starting value of three thousand milliseconds but it may
need further adjustments based on the amount of polling and performance information from the UNC. If
left at zero points that do not support COV Subscriptions will be polled at a rate of 500 milliseconds. This
will have a negative impact on the network.

If the UNC idle is below 20%, it is recommended to slow down the poll rates by adjusting the Control
Engine Service and other UNC services. Check all of the UNCs on site to make sure the Control Engine
Service has not been changed from its default values. The execution frequency of the Normal parameter
defaults to two seconds, if it is different from the default value this should be a warning of issues you may
encounter in the Automation Server. Most objects by default will execute at the Normal rate of two
seconds.
Screenshot of default values

23
IP/MSTP Network Settings

4. The IP and MSTP Networks will automatically turn on. If either network is not terminated or
ready to switch over turn off the online property to false.

5. The IP network will default to the incorrect IP address and Broadcast address. Change both of
these addresses and any other settings prior to turning the IP and MSTP networks on.

24
IP/MSTP Network Settings
1. The MSTP Network will default to Enhanced Mode = True. Enhanced mode should only be
used with B3 devices. Disable Enhanced Mode by setting it to false.

25
2. MSTP Configuration Settings:

• Max Info frames specifies the maximum number of information frames the node may
send before it must pass the token. The recommended value is 20

• Max Master specifies the highest possible address for master nodes and shall be less than
or equal to 127. The recommended value is two above the last device address. In the
example below the network consists of 15 devices. The Maximum Max Master setting
will be 17.

26
COV versus Writes
Writes sent from the AS will require the configuration of the transfer window for guaranteed transfers
after a specific amount of time. This can become time consuming since we do not have a way to mass-
edit this parameter. The Automation Server supports the COV server and COV client function, consider
using the Link Builder to create subscriptions between the AS and MNB devices to manage the BACnet
network traffic. This will give you redundancy and prevent unnecessary traffic. The redundancy is based
on the MNB being able to re-subscribe to the AS and immediately update a value rather than waiting for
the next write. If the MNB is unable to re-subscribe the local logic can take over. The AS is now able to
show how many active COV clients are subscribed under the MNB objects.

Alarms and MNBs

If you choose not to use the BACnet points with intrinsic alarms created by the transition and would
prefer to use the SmartStruxure Alarms. You can create alarms directly on the MNB points in revision 1.5
and higher. Points that support COV subscriptions will not have a negative impact on the network. If
the points are background objects they do not support COV subscriptions. What this means any time you
assign an alarm it will poll the monitored variable every 500 milliseconds. To prevent the default behavior
the polling parameter can be set to 3 seconds under the advance tab of the BACnet Interface.

Trends and MNBs

Interval trend logs can monitor any point. Change of Value trend logs should only monitor points that
support Change of value Subscriptions. MNB background objects will depend on the minimum polling
parameter. If the program writes directly to a point make sure, the point is an AVSPP or BVSPP to prevent
writing to EEPROM. Remember to limit the amount of writes to keep the bandwidth low.

27
Script / Function Block Programs and I/A
You can create binds directly on the MNB points in revision 1.5 and higher. Points that support COV
subscriptions will not have a negative impact on the network. If the points are background objects they do
not support COV subscriptions. What this means any time you assign a program it will poll the input
variable every 500 milliseconds. To prevent the default behavior the polling parameter can be set to 3
seconds under the advance tab of the BACnet Interface.

MNLs will require the Script or Function Block program to be bound to a mirrored value. Connecting the
program directly to the SNVTs will create 500 ms poll updates. When writing to a point try to limit the
amount of writing through the Transfer Value Settings window.

MNB/MNL Native
When working with native MNB/MNL devices or any device, it is good practice to keep all folders under
the device. All bindings will be relative bindings and it allows for the creation of multiple devices with a
copy and paste special procedure without having to redo any bindings. The copy feature can be done with
one or multiple highlighted devices.

28
MNL Device Preparation
Upload all MNL devices to make sure all flow balance and NCI values will be stored in the SNS file prior
to the conversion. Convert the SNS to XML. The XML file should be at revision 532 or higher. If necessary
upgrade the file with WorkPlace Pro, you do not have to upgrade the UNC just the station. When entering
the names in the Conversion Requirement Form (ODS) the names must match the WorkPlace Tech file
name or the Conversion will fail. It is important to create only one project for each UNC XML, do not
create subprojects. They will fail during the conversion process. If you choose to extract the Project zip
and change the order the folders it could result in a failure. For a list of quick steps go to page 30 of the
R2 Transitions Guide.

TAC I/A Transition to StruxureWare Building Operation Solution Guide for BACnet and LonWorks PDF.

Third Party LON Devices

When submitting an XML database from a UNC at the Transition portal. It is important the XIF and
DRF kit files are also available for the conversion process. If the files are not submitted, the conversion
will fail delaying the output of a new XML file for the AS. The XIF and resource files may be available at
the manufacture’s website or Lonmark.org.
If you are not able to obtain the necessary files from either source, the XIF file can be extracted from the
3rd party devices with NodeUtil. Remember the XIF file will not have the necessary information for user
defined USCPTS or UNVTS. Please refer to the Diagnostic Tools section of this document for
instructions to extract an XIF file with NodeUtil.

29
AS LON Interface
Prior to importing your XML file make sure to set the time and date of the Automation Server. After
completing the XML import to the Automation Server, check the following properties/settings:

If it is necessary to change the domain ID in the Automation server to match the UNC, it can be changed
under the LONWorks Network Interface Properties. The Domain ID does not have to match for the
commissioning to occur since we already have the correct Neuron ID in each device converted in the
database.

Anytime the Domain ID is changed, you must re-commission all devices under the AS.

If you have any Configured Routers under the UNC, they will have to be set repeater mode to operate
under the AS. The AS currently does not support the configuration of routers. The example below
shows an LPR-10 router. Set the router to act as a repeater before backing up the database for the
migration. The repeater will maintain subnet = 1 node = 1 and subnet = 2 node = 1, this is okay as long
as the AS does not use the same subnet numbers and node numbers.

30
RepeaterConfig is a simple user interface for setting Echelon’s family of router products (LonPoint® LPR
Router Modules, RTR-10 Router Core Module, i.LON® 600 LONWorks/IP Server and i.LON 1000
Internet Server) into the repeater mode. RepeaterConfig requires OpenLDV. The downloads are available
from:

http://echelon.com/registration

Once you login Select routers under the dropdown menu to download RepeaterConfig. The picture below
is an example of the LPR-10 configured to Repeater Mode under an Automation Server.

SmartStruxure supports IP to F-10 routers at the Enterprise Server Level for further information
reference the Technical Reference Guide.

31
Bandwidth Throttling

Revision 1.8 and higher have the Bandwidth throttling option and will help reduce FT10 traffic. The
recommended limit should set to 28 %. The UNC is considered to reach saturation at 1200 bindings, having
that many bindings would make the UNC extremely slow. The AS saturation is based on percentage and
allowing the AS to reach 50% bandwidth will result in slow updates.

32
Alarms and MNLs
If you choose not to use the BACnet points with intrinsic alarms created by the transition and would
prefer to use the SmartStruxure Alarms. Create alarms on the mirrored variable of the Local Node. If you
assign an alarm directly on a SNVT, it will poll the monitored variable every 500 milliseconds.

Trends and MNLs

Interval trend logs can monitor SNVTS. Change of Value trend logs should only monitor mirrored variables
under the Local Node

33
Schedules
1. R2 supports Master and Slave Schedules SmartStruxure supports Lead and Shadow schedules. If
the Automation Server will have shadow schedules, make sure to create a Lead Schedule in the
Enterprise Server.

2. BACnet Schedules support analog objects if you have a Standard schedule bound to a program
object that takes a digital value and turns it into an analog value. Replace it with a BACnet
Analog schedule. BACnet Schedule types:

• Analog Schedule = AV, AO

• Digital Schedule = DV, DO (Not recommended)

• Enumerated = DV, DO

• Multistate = MSV, MSO

• Integer = AV

• Boolean = Enable trend log

3. BACnet Schedules can default to NULL. The ability to default to null will allow the programmer
to use different priorities, this option allows local control when necessary.

34
Program Objects
Script programs will replace TRIPL program objects. The Script program will maintain the bindings created
in the UNC, but the program itself will be commented out and will have to be rectified in order for the
Script programs to run.

Program Objects can be CPU intensive and depending on the frequency they write to an object can have
a negative impact on any network. The same can happen with an Automation Server and Script
programs. Remember the TRIPL object rule only 80 TRIPL objects should reside in the UNC database.

All TRIPL objects by default will execute under the control engine at a rate of 2 seconds. If the UNC is
close to 80 TRIPL Objects, the CPU is probably running at a very high percentage. You can check which
program objects are consuming a higher percentage with the prism resources process under the UNC
network analysis section.
Consider setting all new Script or Function Block programs to execute at different Task levels based on
how critical the program is in the AS logic. This will help prevent high CPU utilization.

35
Niagara Objects

Niagara objects, like a Binary Input (BI) or Analog Input (AI), support a default value. SmartStruxure
BACnet points will retain the last known value through a power cycle. If the relinquish default is a most in
the logic, consider replacing the BACnet Input with a BV or AV. BACnet Binary Values and Analog Values
support the relinquish default value.

Niagara Objects also support intrinsic alarming; we can duplicate this option with BACnet points in the
Automation Server. Native SmartStruxure values do not support the relinquish default and intrinsic
alarming. The picture below shows all the matching alarm settings after the transition.

36
Graphics
Graphics will convert but only the links and Value boxes in the GX page.

The TGML example

37
Generating a report from the Niagara GX page will help with the properties of the links.

Print the report to PDF to make the searching easier.

38
If the GX text used an image, they can be added to the links through the TGML editor.

39
Migration Tool

Migration tool common mistakes

1. R2 station xml submitted below release 532.

2. Even though the documentation states you can use one project and multiple subfolders ... this
should be avoided. Each conversion should be run as a separate project.

3. The uploaded (completed) conversion form is zipped under a common directory. The folder
structure within the returned (uploaded) conversion form zip needs to be maintained from the
original (all folders at the root of the zip).

4. The completed conversion form is missing the .csv format version of the completed and saved .ods
format file.

5. All blank cells within the .ods must be completed. Do not save as a .csv and enter in data that will
not be recognized by the conversion tool (e.g. this device not used, etc.).

6. The conversion form is missing the hardware model for the standard MNL controllers. These are
selected as drop-down items in the original .ods file. This error return a report zip file where the
resource report indicates the model numbers do not match the uploaded application (.vsd) files.

7. The application file names are not recognized during the conversion (missing from the WorkPlace
Tech folder in the conversion zip file, spelling, dashes versus underscores, spaces not allowed, illegal
characters).

8. Resource report indicates MNL-800 application failed to import ... Compile error. Import
Failure. Typical issues (nv name lengths greater than 16 characters, nv or IO object names - illegal
characters, nv index values auto-indexed or -1). Copy application to standalone WorkPlace Tech
and add to project - run object indexer and correct issues (truncate nv names). Can review R2
database to determine index values.

9. Missing xif and Device Resource Files (DRF) for third-party LON devices.

10. Conversion does not recognize or convert any LON shadow objects. This is typically the result of
the R2 database containing the LON shadow object under LON containers.

40
Automation Server Database and Network Analysis
Automation Server BACnet Conversion Results

The screen shot below shows the result after upgrading the firmware of the MNBs and making the necessary
changes to the script programs. The postponed messages are now zero and the tokens column has increased
from 13,781 to 27,926.

If you compare the statistics after the conversion to the statistics prior to the conversion, under the Tips
and Time savers/MNB device Preparation you will see less Read Property Multiples and COV
subscription and COV Notifications are now present. This means we are polling less and increasing are
bandwidth. The writes have also gone down from 3903 to 349. As you can see in the statistics, we still
had some errors that required further analysis.

41
The Automation Server just like the UNC has the ability to provide you with statistics to troubleshoot the
database and network/s under the AS. We can continue the analysis of the BACnet MSTP network under
the AS with the BACnet Diagnostics feature. The BACnet Diagnostics folder is under the
System/Modules/BACnet devices/Diagnostics. If the CPU percentage is, high you may want to adjust
the Minimum polling interval for the specific network to lower the CPU percentage. In the pictures below
you can see how MNBs are COV based and the polling will have a very low effect on the CPU.

For more information, consult the Technical Reference Guide/ BACnet Deep Technical Reference
Chapter page 5637.

42
Tasks
The default Task for Script and Function Block programs is Task 3. If you look at the image below task 3
will execute at the rate of 1 second.

If all the Script objects remain at the default of 1 second, and you have a high amount of Script or
Function Block programs the AS will most likely have a very high CPU utilization percentage. Like the
example below.

43
The Automation Server in the example above had over 300 Script programs the CPU was over 80%
utilization. The image below shows a search for Script and Function Block programs.

Mass edit from Search highlight all the objects click the properties icon and change the task to 5

After we changed the task 3 to task 5 the CPU utilization was lowered around 40%

44
Trace Files
The Automation Server just like the UNC has debugging options for each protocol. The image below
shows the path and the different protocols that support the trace feature.

45
To collect the trace log data from the AS right click the Trace Settings folder /Trace Settings/Get trace
Log. Notepad will popup save the file and open it with Notepad ++. Notepad ++ will be easier to read
and search.

After collecting the Trace Log, make sure to go back to the properties of the protocol and return the level
to information. Leaving the trace option enable will have a negative impact on the system memory and
CPU.

46
Example: the image below shows the points polled and COV subscriptions when opening a graphic page.
Also, notice a poll time of 500 milliseconds. Remember to adjust the minimum poll time.

47
Diagnostic Tools
Expert Tool
If you would like to view the data in a flow chart, SmartStruxure Expert Tool will create flow diagrams of
the current script programs in the AS and display bindings with live data. You can download the latest
release from the Download Center.

https://buildingsdownloads.schneider-
electric.com/search#documentDetails/1114030/Expert%20Tool%20v1.5

48
WireShark
Is a free protocol analyzer and is available to download @ http://www.wireshark.org.

WireShark Capture Options:

1. Select Interface

2. Capture in promiscuous mode

3. Select file path

4. Use multiple files

5. Check pcap-ng format

6. Determine the size of the files

7. Disable automatic scrolling

8. Do not enable network name resolution

9. Capture for a ½ hour to an hour

49
Wireshark New Comport Option

1. Wireshark version 2.2.9 is consider an old stable release and will work BACnet Tools
version 0.8.5.

50
2. Under program files Wireshark find the folder named extcap. It may be necessary to add the
folder if you cannot find it.

3. Copy and paste the mstpcap.exe under the extcap

51
4. Open Wireshark and check for new BACnet MSTP comports.

52
5. Select the desired comport and select the baud rate required for the adapter. If using the Roam
I/A with the RS-232 connection please select 115200. If using the Roam I/A Bluetooth select
76800. All other adapters select the specific baud rate.
6. Click okay

53
7. Double click Start to initiate the MSTP capture.

8. You should now see Wireshark live packets and the MSTP cap program run simultaneously

54
8. To save the capture press the stop button. This will stop the live updates.
9. click on file under the menu options
10. Select Save and select the location to store your capture.

11. To download the latest copy of mstpcap. Please download BACnet-Tools-0.8.5 with the link
below.

• https://sourceforge.net/projects/bacnet/files/bacnet-tools/

For more BACnet information use the link below

• http://steve.kargs.net/

55
WireShark BACnet Layers:
• BACnet Virtual Link Layer (BVLC) provides the link between the BACnet Network Layer and
Data Link layers.
• Network Layer (Network Protocol Data Unit) provides the means by which messages can be
relayed from one BACnet network to another, regardless of the BACnet data link technology in
use on that network
• Application Layer (Application Protocol Data Unit) handles the interface with the user’s
application program

WireShark Filter Expressions:

● BACapp

● BACnet

● BACnet MSTP

For examples on how to use the filters above, consult Lessons Learned article 11250.
http://buildingskb.schneider-electric.com/view.php?AID=11250

56
BACnet Statistics

WireShark provides BACnet Statistics that will help you understand which services have the highest impact
on your network. It is important to capture for a minimum of a half hour or more to make sure you have
a good amount of packets to troubleshoot a reoccurring issue.

1. Open the WireShark file click Statistics

2. Scroll down to BACnet and select Packet Sorted By Service

3. Click Create Stat

57
The Statistics page will show which services have the highest impact on the network
BACnet common issues
1. COV Notifications
● COV Increment
● Confirmed requires an acknowledgement vs. Unconfirmed does not require an
acknowledgement less traffic.
2. Continuous polling
● Read property or Read Property Multiple.
3. Write Service
• Writing to often to EEPROM damaging memory
4. Broadcasts
• Who-is? I-AM

58
How to Extract an XIF with NodeUtil
This procedure will help with the extraction of an XIF file. An XIF file is used to create a Niagara R2
shadow object, a Niagara G3 LMNL file, or a StruxureWare Device Template. NodeUtil is available at
http://www.echelon.com/.
1. NodeUtil requires an available USB or PCMCIA LON adapter. Connect the adapter directly to the
LON network or third party device.
2. Open NodeUtil and press the service pin of the third party device. If properly connected, a
response will include the program ID of the device.

3. Enter the Go to device menu command by pressing the letter G.

4. Enter the Node ID number corresponding to the third party device program ID. In this example,
ID 0 corresponds to the LON adapter, and ID 1 corresponds to the third party device.

59
5. Create the Device interface XIF file by pressing the letter X.

60
6. Type the name or model for the third party device.

In this example, we used a VT7600 Viconics model

61
7. When the XIF file is completed, NodeUtil will display “Created successfully.”

8. The XIF file will be created in the same folder that NodeUtil resides.

62
Loytec LPA Analyzer

The Loytec Protocol Analyzer (LPA) is a tool for analyzing LON networks by using a Loytec NIC709 or
NI852 network interface, which connects your personal computer to the network. After setting up the
network interface, incoming packets are logged and displayed on-line during the logging process.

The examples below were created using the NIC-852 interface.

63
The steps below assume the user has gone through the necessary steps to configure the NIC-852

1. Click NI icon

2. Click the remote LPA Assignment button

64
3. Click the Add device button

4. Type the IP address of the AS

5. Click Add device and Restart Search

65
6. Click Auto Assign

7. Once the AS/s are assigned an LIP number Click OK.

8. Highlight the desired LIP interface to capture from and click OK

66
The top right corner should now show the LIP number plus the IP address of the AS.

9. Click file new and click the Start Log from Network or press F5

You should now see (Active Log Running) at the top of the LPA window

67
10. Pause the current capture and click view / Display Options

11. Set the radio button for Data Format to decimal

12. Set the radio button for Address Format to decimal

68
Setting the display options to decimal will make it a little bit easier to read the data captured by LPA.
The Domain Subnet and Node ID will be easier to understand. The picture below is an example of
how to read the data in bytes using the SNVT time stamp. Please zoom in to read the breakdown of
the packet.

Let us take a closer look at the statistics window

69
13. Click on the statistics icon

a. Take a look at the bandwidth Utilization Average it is at 78.578%

b. This is extremely high, the suggested bandwidth is anywhere below 20%

14. Click the Node tab

70
The Node tab provides statistics for each device and the amount of packets captured per device. The
Packet column helps to identify devices that have a high amount of traffic.

15. Click on the Packet column to sort from high to low packet counts

71
Now we can see the devices that have the highest amount of traffic. Let us start with device 35 since
we know that device 1 is the LocalNode.

16. Click on line 2

72
 a. On the far right check Enable Display Filter

b. Click on the button labeled Create Display Filter

Now we should show see on our main screen packets from device 1 and 35

73
If you notice network variables 22 and 01 are fetched (polled) very frequently. The next step would is
to identify under device 35 if variables 1 and 22 are connected directly to alarms or COV trends.
Alarms and COV trends should always be bound to the LocalNode mirrored variables.

74
Appendix
ASD Driver Comparison

ASD Driver R2 G3 SmartStruxure Comments

EMS Control Yes Yes Yes

Block Output Control Yes Yes No This option gives the ability to override AO and DOs

Block Output Logs Yes Yes No Access to ASD controller Point history

Sample time adjustment Yes Yes No

for Logs

Schedule Control Yes Yes No Specific to Zone II controllers but this is one of the most
utilized controllers

Fall back Control Yes Yes Yes

Tunneling Yes Yes No Remote Programming

Multi Port Tunneling Yes Yes No Multi Port remote programming

PSI Object Yes Yes No This allows an external XPSI connection without disrupting the
ASD bus

Quick View Yes Yes No Graphic page for ASD devices built on the fly

Holiday Yes Yes No Stand Alone Control

Group Control Yes Yes Yes

Micronet Integrator Object Yes Yes Yes This object gives you the ability to share data in the U-bus

Loop and Utility Overrides No Yes No G3 feature added big enhancement from R2 to G3

Block Manager Yes Yes No

MNetCi Yes Yes No Tool to access U-Bus Mnet Controllers from a single location

75
Collaborators
Thank you for sharing and making Schneider- Electric better every day.

➢ Sam Rongere - Schneider Electric

➢ Steve Titus – Wade Company

➢ Wayne Peters - Schneider Electric

➢ John Sullivan - Schneider Electric

➢ William Workman - Schneider Electric

➢ Stephen Chandler - Schneider Electric

➢ Houston White - Schneider Electric

➢ Bradley Hughes - Schneider Electric

➢ David Purser - Schneider Electric

76