Generated on 26-Nov-07

See http://www.niagara-central.com for the latest release notes.

#########################################################################
1  Unknown
#########################################################################

=========================================================================
1.1  Fixed
=========================================================================

*** 1.1:6763  QNX-based JVM (J9) Float.toString() bug ***
  Record Type:  Bug
  Resolved In:  3.2.5
This bug no longer affects AX 3.2.  It was fixed in the new release of j9 2.3
included in AX 3.2 builds.

The J9 2.2 VM (used in all QNX-based JACEs) shipped with NiagaraAX 3.0/3.1 contains 
a bug in the floating point to string conversion code.

Converting certain floating point values to a string will fail with the
following (or similar) exception:

java.lang.ArrayIndexOutOfBoundsException: Array index out of range: 25 at
com.ibm.oti.util.NumberConverter.freeFormatExponential(Unknown Source) at
com.ibm.oti.util.NumberConverter.convertF(Unknown Source) at
com.ibm.oti.util.NumberConverter.convert(Unknown Source) at
java.lang.Float.toString(Unknown Source)

As a workaround, the floating point value can be upcast to a double before the
conversion. e.g.

float f = 1.7014118346046924e+38F;
double d = f; // upcast f to double

// Double conversion works
System.out.println("d=" + d);

// Float conversion doesn't
System.out.println("f=" + f);


*** 1.1:7906  Non UTF-8 characters kept readmeLicenses.txt from being viewed. ***
  Record Type:  Bug
  Resolved In:  3.0.100; 3.1.5
The third-party licenses file (readmeLicenses.txt) could not be viewed in 
build 3.0.99 because of non UTF-8 characters. These characters were removed 
in build 3.0.100 and 3.1.5.

*** 1.1:8157  Add license check for additional RAM on JACE-2 ***
  Record Type:  Enhancement
  Resolved In:  3.1.12
JACE-2 based products that have 128 MB of RAM (part NPM-128) require an 
additional Tridium license feature to take advantage of the additional memory.

If the maxHeap feature is *not* present, the maximum Java heap permitted is 16
MB (default is 14 MB), regardless of RAM installed on the system.

*** 1.1:8183  Deleting of a lexicon has a extra 'a' in confirmation box ***
  Record Type:  Bug
  Resolved In:  3.0.101; 3.1.13
The delete lexicon confirmation dialog box formerly read: 
"You are about to delete a the xx lexicon. Are you sure you wish to proceed?"
The extra "a" was removed beginning in 3.0.101 and 3.1.13.

*** 1.1:8364  Convert Third Party Licenses page to HTML ***
  Record Type:  Enhancement
  Resolved In:  3.0.101; 3.1.16
(Developer's Release Note)
The "Third Party Licenses" target page, as linked to from the Niagara Workbench
Help "About" spashscreen, was changed from a text file to an HTML file 
(formerly: !lib/readmeLicenses.txt  now: !lib/readmeLicenses.html). This will 
permit linking to licenses.  See also related issue 8362.

*** 1.1:9066  Commissioning Wizard crashes when module unchecked ***
  Record Type:  Bug
  Resolved In:  3.2.5
In AX releases 3.0 and 3.1, it is possible to cause a deadlock in Workbench
by doing the following in the modules step in the Commissioning Wizard:
a) press the "upgrade out-of-date" button
b) quickly deselect some of the check boxes in the grid for modules checked by
step a)

This bug has been fixed in AX 3.2.   It can be avoided in earlier releases
by waiting a few seconds after pressing the "upgrade out-of-date" button
*before* deselecting any check boxes.

*** 1.1:9378  Add all device lnml files to the palette for each lon device module. ***
  Record Type:  Enhancement
  Resolved In:  3.2.6; 3.1.30; 3.0.106
Each Lon device jar now contains a palette with entries for all device lnml
(Lon XML) files that are in the module. The devices can be dragged out of the 
palette and dropped into the station.

*** 1.1:9573  Merge existing units.xml when upgrading ***
  Record Type:  Enhancement
  Resolved In:  3.3.1
In Niagara AX releases prior to 3.3, installing an nre-config distribution
using the Distribution File Installer, the Commissioning Wizard, or with
a provisioning job would unconditionally replace the unit reference file 
!lib/units.xml.   This is an inconvenience for customers who add their
own unit definitions to the file.

In Niagara AX 3.3, when an nre-config distribution is installed, any existing
contents of the !lib/units.xml file will be merged into the new contents
as follows:

- If a unit is defined in both the new and existing versions of the file,
 the new version is used in the merged output, and is associated with the 
 quantity that it's associated with in the new file.  
 
- If a quantity exists in the existing version of the file, but not in
  the new version, and there are no units for that quantity in the merged
  version of the file, the quantity is also omitted from the merged version. 
  
- If a unit exists in the existing version of the file, but not in the
  new version, the merged version will include it and associate it with the
  quantity specified in the existing version.

*** 1.1:9823  Changing Host Authentication causes AuthenticationException on Station Save ***
  Record Type:  Bug
  Resolved In:  3.3.11
If the Platform Administration view is used to change the authentication method
or port of the platform daemon on a host running AX 3.2 or earlier, any
attempts by running stations to send messages to the daemon afterward will
fail.

This will cause any platform actions that wait for stations to save or shut
down gracefully to wait indefinitely, and will cause the System Platform
Service's "restart station" action to fail with AuthenticationExceptions.  
AuthenticationException messages will also display on the console whenever the
station saves, though the problem does not prevent saves from succeeding.
  This problem has been fixed in AX 3.3, builds 3.3.11 and higher.

Customers using earlier AX versions should work around this problem by stopping
any running stations before changing the platform daemon's authentication
settings or port.

*** 1.1:10043  Add facet to show separators ***
  Record Type:  Enhancement
  Resolved In:  3.3.1
A new facet has been added called SHOW_SEPARATORS which can be used
with any BFloat, BDouble, BInteger or BLong which inserts a separator
character every third digit, i.e.:

   1,000,000.0

BFloatFE and BIntegerFE have also been fixed to allow separators to be
inputed in the text fields and saved correctly.

To enable seperators add the boolean facet "showSeperators" using
the Config Facets Editor.

*** 1.1:10179  Greater than 1000 file descriptors causes ConnectException: No buffer space is available ***
  Record Type:  Bug
  Resolved In:  3.3.16
In Ax 3.2, the maximum file descriptor count for JACE-4,5, and -6 was
increased from 1000 to 2000. However, due to a limitation in the J9
network stack that limited file descriptors to 1000 the increase had 
little value.

In Ax 3.3, the J9 network stack file descriptor limit has been removed.
This allows customers to use up to 1600 histories where the previous
limit was 800.

Note that the limit on a JACE-2 remains 800 histories.

Each module, history and socket connection consumes a file descriptor. See
Issue 8942 for details on a new "too many open files" warning.

*** 1.1:10624  Incorrect scale for micrometer ***
  Record Type:  Bug
  Resolved In:  3.3.5; 3.2.17; 3.1.31; 3.0.107
The scale for the unit "micrometer" in the "length" quantity of units.xml 
was incorrect.

It was previously defined as

  <unit n="micrometer" s="um" scale=".00001" />

but now it has been correctly updated to be defined as 

  <unit n="micrometer" s="um" scale=".000001" />

Anyone who had included the micrometer unit in a station will encounter "duplicate unit" and "invalid facets" exceptions that prohibit the station from starting when trying to use that station with the corrected file.  The bog file can be corrected by searching for "micrometer" and replacing the scale *1.0E-5 with *1.0E-6.


#########################################################################
2  alarm
#########################################################################

=========================================================================
2.1  Fixed
=========================================================================

*** 2.1:695  New Alarm Escalation feature added ***
  Record Type:  Enhancement
  Resolved In:  3.2.5; 3.2.9
An Alarm Escalation feature has been added to the AlarmClass beginning with AX
build 3.2.5 and above. 

Alarm escalation is configured at the notification class level, not at the 
alarm extension level (escalation is configured in the AlarmClass object).

The new AlarmClass has three new outputs that can be connected to any of the
standard recipients. There is a user configurable timer between the original
'Alarm' output and each successive output. As timers expire, the alarm is 
routed to the next linked recipient until all configured levels have been 
addressed. 

As each level's timer expires (the timer counts from the time the alarm was 
generated, not from the time the alarm last changed escalation levels), the 
'escalated' property in the 'Alarm data' is elevated to the next level (level 3 
is the highest). Acknowledgement of the alarm at any level aborts the alarm 
escalation. Acknowledging from any ConsoleRecipient, linked to any level, 
will acknowledge all levels and all associated ConsoleRecipients containing 
the same alarm.

One or all of the escalation levels may be enabled.



*** 2.1:5311  AlarmPortalTool would throw exceptions ***
  Record Type:  Function
  Resolved In:  3.0.53
The AlarmPortalTool would throw exceptions when stopped from the Workbench Service
Manager view, or when running in the background.  These exceptions did not affect the
functioning of the Alarm Portal. This issue was fixed in build 3.0.94.

*** 2.1:5563  EnumCommandFailureAlarmExt did not generate toNormal alarms ***
  Record Type:  Function
  Resolved In:  3.0.55
The EnumCommandFailureAlarmExt was not generating toNormal alarms upon a return to
normal from an alarm condition.  This was fixed in build 3.0.94.

*** 2.1:6141  Ack time of alarm extension did not update in some cases ***
  Record Type:  Bug
  Resolved In:  3.0.68; 3.1.16
In some cases, such as when an alarm was acknowledged after transition from
offnormal to normal, the ack timestamp was not updated in the alarm extension.
This was fixed to show the proper ack timestamp in all cases.

*** 2.1:6805  Enter key not saving for numerous fields in alarm extension ***
  Record Type:  Bug
  Resolved In:  3.1.4
There are multiple fields in which the Enter key does not act
as a save.  None of the checkboxes work but specifically these
in any alarm extension:

 Source Name
 To Fault Text
 To OffNormal Text
 To Normal Text
 High Limit Text  (both fault/offnormal algs.)
 Low Limit Text (both fault/offnormal algs.)
 
This was corrected in 3.1.4.


*** 2.1:6950  Workbench freezes while acking large numbers of alarms ***
  Record Type:  Bug
  Resolved In:  3.2.6
It was found that initiating an "Acknowledgment" on more than 200 alarms 
at one time in a Workbench ConsoleRecipient could cause Workbench to freeze and 
disconnect from the station. Often, the problem occurred if you attempted to 
open other station folders while the acks were still pending. Acknowledging 
groups of 200 alarms or less did not appear to cause the disconnect problem.
As a workaround, do not acknowledge more than 200 alarms at one time.

*** 2.1:6963  X button did not close Notes window. ***
  Record Type:  Bug
  Resolved In:  3.0.91
When using the Alarm Portal or Alarm Console, the "X" button in the "Notes" 
window did not close that window.  This was corrected in 3.0.91.

*** 2.1:6969  Acking problem over dialup when alarms are already in database ***
  Record Type:  Bug
  Resolved In:  3.0.89
Sending and acknowledging more than two alarms at a time failed over a dialup 
connection.  A workaround by entering a "niagara.fox.engageLinger" value in 
the host's system.properties allowed proper operation.

Starting in build 3.0.89, this problem with alarming over a dialup connection
was fixed.  However, you must disable any workaround entry in system.properties
by adding a "#" symbol in front of that line.

For example, your system.properties should now have a line similar to:

#niagara.fox.engageLinger=180000

NOTE: To edit a remote system.properties file, open a platform connection and
use the File Transfer Client to make a local copy.  Edit the local copy, and
then use the File Transfer Client to put the edited copy back.

*** 2.1:7016  Alarm console ord wrong if initial user info wrong ***
  Record Type:  Bug
  Resolved In:  3.0.91
In previous releases of the Alarm Portal, if you added an alarm console, 
entered an incorrect user and password, then hit Next, you got the expected 
message "cannot connect to ip". The alarm console ord showed up as 'slot:/'. 
To fix, you could use the Back button and correct the username and password.
When you hit Next, the alarm console ord showed up correctly. However, when you
hit Finish, the alarm console ord entered into the Alarm Portal was always 
'slot:/'.  To fix, you had to re-edit the entry, hit Next, and then the correct
alarm console ord showed up again. When you hit Finish, the entry would now 
have the correct ord.

Starting in build 3.0.91, when you add a new alarm console, enter the incorrect
username and password, and go Back and fix it, the alarm console ord gets
correctly added. There is no need to go Back and re-edit it again.

*** 2.1:7021  Blank Alarm Popup when entering Portal ***
  Record Type:  Bug
  Resolved In:  3.0.91
In prior versions of the AlarmPortal, the Alarm Portal popup window would not
display the current alarm when it was first opened. It would display the
correct alarm when a new alarm came into the console.

Starting in build 3.0.91, the Alarm Portal popup will display the most recent
alarm when it is first opened.

*** 2.1:7087  Line printer recipient not recognizing printer ***
  Record Type:  Bug
  Resolved In:  3.0.93
In some cases, it was found that adding a LinePrinterRecipient would cause a
null point exception.  In this scenario, from the LinePrinterRecipient's
property sheet, the Printer property would show only "0", with the drop-down
selection list not working (no printers known to Windows host were avaiable).
This issue was fixed starting in build 3.0.93.

*** 2.1:7225  Alarms routed to LinePrinterRecipient did not print ***
  Record Type:  Bug
  Resolved In:  3.0.91
Due to a bug in some native code, the Line Printer Recipient was unable to 
print alarms.  This bug was resolved in build 3.0.91, and the
LinePrinterRecipient should now print alarms as expected.

*** 2.1:7296  Blank alarm popup after enabling Alarm Popup ***
  Record Type:  Bug
  Resolved In:  3.1.17
If you started the Alarm Portal without Alarm Popup enabled, and then subsequently
enable Alarm Popup, the first popup on the most recent alarm could appear blank 
(no data such as timestamp, source, message text, etc). However, once a new 
alarm came in, the popup window continued to update correctly.

Beginning in 3.1.17, the Alarm Popup now shows the most recent alarm when it
opens (based on the alarm's timestamp).

*** 2.1:7316  BooleanChangeOfState alarming on null value ***
  Record Type:  Bug
  Resolved In:  3.0.92
In prior releases, the BooleanChangeOfState alarm extension went into alarm 
when the value of the parent point was null. Even though a null value appears
as "-" in Workbench, the underlying value is false, and a check of the status 
flags was not performed.

Starting in 3.0.92, a BooleanChangeOfState alarm extension now checks the 
status flags, such that a point with a null value no longer alarms.

*** 2.1:7321  Multiple popup windows opened if Alarm Portal revisited ***
  Record Type:  Bug
  Resolved In:  3.1.6
In the Workbench options for the Alarm Portal, if the "Alarm Popup Uncloseable"
option was checked, and an alarm popup was open, when you navigated away from 
the Alarm Portal and then back again, two alarm popups opened. This has been 
fixed, where only one popup will now open.

*** 2.1:7356  Status flag changed to ok going from fault to alarm ***
  Record Type:  Bug
  Resolved In:  3.0.93
An alarm extension enabled for fault limits would incorrectly report an ok status
when returning from a fault range condition to an offnormal (alarm) range condition.
This specific transition was not checked for correctly in the offnormal algorithm.  
This was fixed starting in build 3.0.93.

*** 2.1:7357  Repeated fault alarms while point in low fault condition ***
  Record Type:  Bug
  Resolved In:  3.0.93
If an OutOfRangeAlarmExt was enabled for low fault limit, after entering
a low fault condition a new unack alarm was generated upon each value change.
This was due to a problem with the fault algorithm, which was assuming a high
limit fault.  This issue was fixed starting in build 3.0.93.

*** 2.1:7454  A toNormal was not issued if the fallback value was NULL ***
  Record Type:  Bug
  Resolved In:  3.0.95
If the fallback value for a numeric point with an OutOfRangeAlarmExt was NULL,
and the point went into alarm as a result of being overridden, a toNormal 
notification was not issued after setting the point back to auto.  This would 
result in the point showing that the alarm had cleared, but the Alarm Console 
would show that the point was still in alarm.

This was fixed in 3.0.95.  If the point is set to auto (with the fallback value
being NULL), a toNormal notification will be issued and the Alarm Console will 
show the alarm state of the point as being normal.

*** 2.1:7558  Alarms missed on toggle of toOffNormal enable ***
  Record Type:  Bug
  Resolved In:  3.1.4; 3.0.100
New offnormal alarms were not generated when toggling toOffnormal enable in an
alarm extension, and the parent point was in an off normal condition.  This 
has been corrected.  Now when toggling the toOffnormal flag back to enabled, 
an alarm is now generated (if the point is in alarm condition).


*** 2.1:7630  AlarmConsole TimeZoneDisplay option did not save properly ***
  Record Type:  Bug
  Resolved In:  3.0.98; 3.1.1
In previous versions, the TimeZoneDisplay option of the AlarmConsole did not 
save correctly (a change of value was lost upon a refresh of the AlarmConsole).
This was fixed in build 3.0.98; changes to TimeZoneDisplay now save properly.

*** 2.1:7654  Negative deadband entry was allowed and caused false alarms ***
  Record Type:  Bug
  Resolved In:  3.1.4
Formerly, the Deadband property of the Offnormal Algorithm in an OutOfRangeAlarmExt
allowed entry of a negative number, which should not have been allowed.  Furthermore,
doing this could cause the parent point to toggle rapidly in and out of alarm, and
in some cases consume enough resources to cause a watchdog timeout.

This was fixed in 3.1.9, where entry of a negative value deadband is not allowed.
As a workaround in any 3.0.x build, be careful not to enter a negative deadband.

*** 2.1:7657  Uncheck lowLimitEnable and point stays in alarm ***
  Record Type:  Bug
  Resolved In:  3.1.4; 3.0.100
For any point currently in an alarm from the OutOfRangeAlarmExt, subsequent
changes in its Limit Enable selections (lowLimitEnable, highLimitEnable) were
not evaluated upon a value change.  Therefore it was possible that a point 
could remain in a low or high alarm state after that limit was disabled, and 
the value did not change (say a wire was disconnected on an input).

This was fixed; now changes in the Offnormal Algorithm limit enable flags
are evaluated when the point is in an alarm state.

*** 2.1:7728  Fault and Alarm flags do not clear on AlarmExts with alarms and faults both enabled ***
  Record Type:  Bug
  Resolved In:  3.1.4; 3.0.100
Components with an alarm extension containing a "non-empty" Fault Algorithm 
and enabled for both alarms (toOffnormal) and faults (toFault) do not correctly
clear the alarm or fault status flag when returning to normal, from either an 
alarm or fault value.

Affected <types> of alarm extensions include:
 OutOfRangeAlarmExt (NumericPoint, NumericWritable)
 EnumChangeOfStateAlarmExt (EnumPoint, EnumWritable)
 EnumCommandFailureAlarmExt (EnumWritable)
 StatusAlarmExt (any point type)
 
The bug is in the Fault Algorithm. Alarms only (toOffnormal) will work correctly
if you disable Faults (toFaults).  Do this in the property sheet of the 
<type>AlarmExt by doing the following:

 1) Clear (uncheck) both Alarm Enabled settings (toOffnormal and toFault).
 2) Save.
 3) Recheck the Alarm Enabled, toOffnormal setting.
 4) Save again.
 
There is no workaround to allow for proper Fault operation with these alarm 
extensions prior to this fix.

*** 2.1:7744  Deadband wrong in OutOfRangeAlarmExt after UNITS changed in Workbench ***
  Record Type:  Bug
  Resolved In:  3.1.4
The alarm extension deadband (OutOfRangeAlarmExt, Offnormal Algorithm and Fault
Algorithm, Deadband) was being converted improperly when used with temperatures. 

For example, say that Workbench was currently set to a unit of Metric and the 
Deadband value in the alarm extension was set to 0.00 DegC, for no Deadband. 
When the Workbench units were changed to ENGLISH, the Deadband value got 
converted to 32 DegF. Then, if the Deadband was set back to 0.00 DegF (for no 
deadband), when the units were switched to Metric, the deadband value was set 
to -17.78 DegC. The number should have actually remained at 0.00, for no
deadband.

This problem arose when using temperatures because when we convert between 
temperature units we have to apply an offset (0F != 0C != 0K).

To resolve this problem, the Deadband property of the OutOfRangeAlarmExt 
Offnormal and Fault Algorithms no longer uses the point's facets.  The displayed
Deadband value then will not change when switching units in the Workbench options.
To avoid confusion during configuration, it is suggested that the Workbench 
option for unit conversion be set to default during configuration.

*** 2.1:7887  Prepend/append station name to alarms received from other station ***
  Record Type:  Enhancement
  Resolved In:  3.1.6
The Alarms device extension under a NiagaraStation (NiagaraAlarmDeviceExt)
now has a "Source Name" slot that you can use to prepend/append the station 
name of the sending station to the alarm source name, or select another format
option.  There are two fields in the Source Name slot:

- (operation), selectable as either:
 Prepend (default) meaning add to beginning
 Append (add to ending)
 Replace  
 Use Existing

- (text),using baja format with the default string of:
 %parent.parent.displayName%:

EXAMPLE
Using defaults, if a an alarm is received from remote NiagaraStation "EastWing"
for an alarm record with its (local) alarm source displayName of "Room101", the
resulting alarm source in the receiving station would be:

 "EastWing:Room101" (if Source Name is Prepend, %parent.parent.displayName&: )
 or
 "Room101:Eastwing" (if Source Name is Append, :%parent.parent.displayName& ) 

*** 2.1:7888  Need a way to display the source ord in the Alarm Console ***
  Record Type:  Enhancement
  Resolved In:  3.1.6
Apart from opening the Alarm Record dialog (details) for a specific alarm, 
another way to view the source ord for each alarm in the Alarm Console may be 
needed.

To show the source ord for each alarm in the Alarm Console, use the Table Options
menu (upper right corner of view), click "Add Alarm Data Column" and enter: 
 sourceOrd
This adds the column "Source Ord".  Note that the "Source" column still displays
the alarm sourceName in the Alarm Console.

BACKGROUND: As in many other table-based views, you can use the Table Options 
menu to select/deselect which columns to display.  The Alarm Console extends 
this functionality with additional menu items "Add Alarm Data Column" and 
"Remove Alarm Data Column."  The latter is different from deselecting for 
display--it removes the choice from the Table Options menu.

*** 2.1:7889  Alarm hyperlinks did not work for relative ords across stations ***
  Record Type:  Bug
  Resolved In:  3.1.6
If you setup an alarm extension with a relative ord in the hyperlink, and route
the generated alarms to a remote station, the hyperlink did not work in the 
remote station's Alarm Console.

Now, when alarms are sent between stations using the NiagaraNetwork, the ord of
the sending station is added to the hyperlink ord upon the receiving the alarm 
in the remote station. This allows the hyperlink button in the Alarm Console to
properly hyperlink to the station that sent the alarm.

*** 2.1:7996  need alarm history view without db tools ***
  Record Type:  Enhancement
  Resolved In:  3.2.3
The AlarmDbView was added to the AlarmService providing a view similar to that of the AlarmDbMaintenanceView but without the remove records commands.


*** 2.1:8013  Console Recipient not unregistering AlarmChannel ***
  Record Type:  Bug
  Resolved In:  3.0.100; 3.1.7
The ConsoleRecipient was not receiving the callback to unregister the 
AlarmChannel for it's Alarm Console. This was been reported to cause a small 
memory leak and a performance loss.

This is now fixed--the Alarm Console makes the appropriate callback to the 
ConsoleRecipient when the Alarm Console is stopped.  Please note that the 
Alarm Portal has always made the appropriate callback, and this only affected 
the Alarm Console.


*** 2.1:8032  Return to normal during time delay causes toNormal alarm  ***
  Record Type:  Bug
  Resolved In:  3.0.101; 3.1.7
With the OutOfRangeAlarmExt, if a point went above the offnormal high limit 
(or below the offnormal low limit) and returned to the normal range during its 
specified TimeDelay period, a "toNormal" Alarm was being (incorrectly) 
generated upon transition back to normal--even though the TimeDelay had not 
expired.  This has been fixed.

Note that TimeDelay applies to transitions to/from offnormal, but not to/from
fault.

*** 2.1:8057  Alarm Record dialog (details) did not show correct timezone for normalTime and lastUpdate ***
  Record Type:  Bug
  Resolved In:  3.1.9
The Alarm Record dialog (details) as seen in the Alarm Console and Alarm Portal
did not show correct time zone for normalTime, ackTime, and lastUpdate based on 
the user's Alarm Console or Alarm Portal options (sourceTime vs. consoleTime). 
It always displayed the times using the Console time zone.

The alarm details dialog now respects the time zone (source or console) set in 
the options (Tools > Options > Alarm Console, Alarm Portal) for the default 
time fields (timestamp, ackTime, normalTime, and lastUpdate).

*** 2.1:8068  AlarmService should fire topics for Security App support ***
  Record Type:  Enhancement
  Resolved In:  3.1.9
The AlarmService now fires an 'alarm' topic upon receiving an alarm (for routing
to a recipient).  This change does not affect normal alarm routing, and was
added only for support of the Security Appliance application.


*** 2.1:8069  AlarmDbMaintenance time zone support extended ***
  Record Type:  Enhancement
  Resolved In:  3.1.9
Time zone support has been added to AlarmDatabaseMaintenance. Before, the 
tables displayed the time zone based on the Alarm Console options, and the 
Alarm Record (details) dialogs always displayed the console time zone.

A timeZoneDisplay property was added to BAlarmDbMaintenance. This allows
Px pages to set the time zone to be displayed.  Also, a toolbar button was 
added (earth globe icon) in the Alarm Db Maintenance view that allows 
switching of time zones (source or console). Both the tables and the details
dialog show the times in this selected time zone setting.

*** 2.1:8106  Notes button stuck at disabled in recurring alarm dialog of Alarm Console ***
  Record Type:  Bug
  Resolved In:  3.1.12
If you double-clicked a row in the Alarm Console with multiple alarm records, 
and in the resultant popup window (Recurring Alarm dialog) selected more than
one alarm, the Notes button should become disabled. Then if only one alarm was 
selected, the Notes button should be enabled again--however, it was stuck
disabled.  Reopening the window was necessary to access the Notes button. 

This was fixed--the Notes button no longer gets stuck disabled in the Recurring
Alarm dialog.


*** 2.1:8184  Alarm Instructions Manager has invalid buttons enabled ***
  Record Type:  Bug
  Resolved In:  3.1.12
If nothing was selected in the Alarm Instructions Manager view of the 
AlarmService, clicking on the 'Edit' and 'Move Down' buttons would produce
null pointer exceptions, while 'Delete' and 'Move Up' did nothing.

This has been fixed.  Appropriate (valid) buttons are now enabled and disabled
depending on the current selection.

*** 2.1:8257  Unable to ack alarms after hyperlinking away from Alarm Portal ***
  Record Type:  Bug
  Resolved In:  3.1.15
If in the Alarm Portal and viewing the details of an alarm,
clicking hyperlink followed by acknowledge in the details
window results in a thrown exception.  This problem does not
occur when hyperlinking from the Alarm Console.

This was fixed starting in 3.1.15. Now, when hyperlinking from
the Alarm Portal, it behaves in the same way as the Alarm Console
does, in that it will close the recurring alarm dialog and/or the
alarm details dialog.

*** 2.1:8274  Notes dialog from Alarm Console should have default text entry focus ***
  Record Type:  Enhancement
  Resolved In:  3.1.15
Previously, when in the Alarm Console or Alarm Portal and you clicked
on the Notes button, the Notes popup dialog had focus on the upper
text box, rather than the lower text input box.  Before entering a
note, you had to first click in the lower input box. In 3.1.15, this
was changed such that the Notes dialog appears with focus already set
to the input area, so you can immediately begin typing note text.

*** 2.1:8359  Edit of Source Name in NiagaraAlarmDeviceExt failed with error ***
  Record Type:  Bug
  Resolved In:  3.1.16
When in the property sheet of a NiagaraAlarmDeviceExt (Alarms container 
under a NiagaraStation device) and you edited the Source Name property
from the default "Prepend" to another value, say "Append", upon a save
a popup error (and exception) occured, and the save failed.  A bug in
Save of this field editor was found and fixed.

*** 2.1:8454  Memory leak in QNX-based JACE when points are alarming ***
  Record Type:  Bug
  Resolved In:  3.0.102; 3.1.24; 3.2.1
A memory leak in alarming was found on QNX-based JACEs (JACE-2, -4, -5 series). 
This was due to Alarm Index Entries were not properly being cleaned up.  Now, 
index entries are explicitly nulled out when they are deleted, to assist in
garbage collection.

*** 2.1:8505  Alarm Record (details) dialog mishandles formatting of spaces in "source" field ***
  Record Type:  Bug
  Resolved In:  3.1.19
The Alarm Record (details) dialog did not format the source (ord) correctly if 
there were space(s) in the source ord of the alarm. It added a line break and a 
"->" at each space.  This was fixed--the formatting of the source ord now shows 
spaces as spaces.

*** 2.1:8506  Station Name prepended twice on Remote Recipients ***
  Record Type:  Bug
  Resolved In:  3.1.19
If the Alarms extension (NiagaraAlarmDeviceExt) of a NiagaraStation is setup 
to modify the source name of incoming alarms (by default, prepending the station 
name), the station name could be prepended twice.  This happened when an 
alarm was generated and then acked before the point returned to normal. The 
Alarm Ack would show the source name formatting applied to it twice.

Now, the Alarms extension checks for incoming alarms that are offnormal and 
acked, and does not apply the source name formatting to those alarms.

*** 2.1:8624  Alerts do not change alarm counts in Alarm Db Maintenance correctly. ***
  Record Type:  Bug
  Resolved In:  3.1.23
It was noticed that some alert conditions, for example related to Ndio, cleared 
from the Alarm Console, but did not return to normal on the Alarm Db Maintenance 
view, thus causing a wrong value in the inAlarmCount value.

This has been corrected by setting alerts to a "normal" state when they are 
acknowledged. 

This fix accomplishes two things. First, the alarm counts on the Alarm Class 
property sheet are updated properly. And secondly, it eliminates confusion when 
looking at the Alarm Db Maintenance View as acknowledged alert will now have the 
white/clear alarm icon next to them, indicating that they have been cleared, 
besides not just appearing in the Alarm Console.

*** 2.1:8634  Supervisor based alarm routing ***
  Record Type:  Enhancement
  Resolved In:  3.2.5
The new macro mechanism for Supervisor Alarm Class Routing works similarly to the way the sourceName macro works.
You have four options on what to do with the alarmClass of an incoming alarm for the niagaraDriver.
You can use the existing alarmClass of the alarm or replace it with a different one. These options work as they did before.
The new options are append and prepend. There allow you to add test to the beginning or the end of the alarm's existing alarm class.

For example, if you select Prepend and give it the text "VA-" and alarms come
in with alarm classes of "Security" and "HVAC", the alarm classes will be
changed to "VA-Security" and "VA-HVAC"

Unlike the sourceName macro, the alarmClass macro does not support BFormat
since the alarms need to be assigned alarm classes that are actually in the
station database and are not created dynamically.


*** 2.1:8662  Forced Clear alarm action available in Px page Alarm Console ***
  Record Type:  Enhancement
  Resolved In:  3.1.23
A  right-click "Force Clear" option was added to alarms that appear in the
Alarm Console on a Px page. This makes it consistent with available operations
that appear in Workbench and the Hx Alarm Console.  Note in any case, a user 
requires admin-level Invoke rights on the ConsoleRecipient to see this option.

*** 2.1:8746  Excessive ConsoleChannel:Worker threads caused JACE to reboot ***
  Record Type:  Bug
  Resolved In:  3.1.24; 3.2.1; 3.0.105
It was found that excessive AlarmConsoleChannel:Worker threads were created 
when routing alarms from a JACE to another station.  A thread was being
created for every FoxSession, and not being destroyed when the session 
ended.  Over a period of time, the thread count in the JACE station became
very large, and could result in a reboot of that host.

This was fixed.  Now, the thread only starts upon connection to an Alarm 
Console, and ends when the connection to the Alarm Console is ended.

*** 2.1:8815  Alarm extension's normalTime did not match timestamp in toNormal alarm record ***
  Record Type:  Bug
  Resolved In:  3.1.24; 3.2.1
When an alarm extension generated an alarm, and then went back to normal, 
the timestamp in the alarm record for the to-normal transition was slightly 
different than the time that was put into the toOffnormalTimes normalTime 
property.  This issue also applied to the toFaultTimes properties.

This has been corrected, such that the toOffnormalTimes and toFaultTimes 
properties of an alarm extension use the actual time from the alarm (timestamp,
normalTime and ackTime).

*** 2.1:8855  Notifications "toNormal" not generated in certain instances. ***
  Record Type:  Bug
  Resolved In:  3.1.24; 3.2.1
In certain instances, a transition from alarm into fault can cause subsequent 
offnormal alarms from that object to not show a return-to-normal.

This was discovered using a BooleanPoint with an BooleanChangeOfStateAlarmExt
extension, as well as a StatusAlarmExt configured on it.  It was found that
if the point went into fault (from StatusAlarmExt) and then returned to normal,
and the point subsequently went into offnormal, it would no longer generate the 
"toNormal" alarm notifications.

There was a bug in AlarmSupport where the existence of a previous fault alarm
would cause offnormal alarms to not return-to-normal. This has been resolved 
in Build 3.1.24, where the presence of a previously-generated fault alarm no
longer causes this behavior.

*** 2.1:8867  Lexicon Alarm module parameters did not translate or were not available ***
  Record Type:  Bug
  Resolved In:  3.2.1; 3.1.25
The Alarm Console, column header 'Msg Text' does not have a key, so a 
translation was unavailable.

For translation, all that is needed now is the alarmData key in the lexicon.
So for alarmData.msgText, the lexicon entry would look like:

alarmData.msgText=Message Text


*** 2.1:10017  File Descriptor Increase in Recoverable Recipient on JACE 2 ***
  Record Type:  Enhancement
  Resolved In:  3.1.31; 3.2.16; 3.3.1; 3.0.107
Since java.io.File.listFiles() can leak a File Descriptor, clearing the alarm queue on BRecoverableRecipient was changed to check that the queue size is not empty for persistant queues before attempting to clear the queue.

This is only a problem on embedded JACEs running r3.0 or r3.1 and using non-Tridium custom components that implement javax.baja.alarm.BRecoverableRecipient and are using persistant storage for the recipient's queue.

=========================================================================
2.2  Open
=========================================================================

*** 2.2:6606  Stack trace when sending ack notifications over dialup ***
  Record Type:  Bug
  Resolved In:  
When using dialup and acks are sent from a Supervisor to a JACE, once the first
ack is received by the JACE, the JACE immediately tries to send the ack 
notifications back to the Supervisor.  This results in a stack trace. 
Technically, all is correct. The modem *is* in use when it tries to connect. 
However, it seems that the stack trace may generate unnecessary questions. 
Alarm ack notifications will be delivered back to the Supervisor once it closes
its dialup connection.

*** 2.2:6770  Alarm Class Mapper throwing exceptions ***
  Record Type:  Bug
  Resolved In:  
When using the AlarmClass Mapper in the Alarm Portal, selecting an inappropriate
OrdChooser will cause an exception. Please note the following 
 o  The correct OrdChooser for "icons" and "sounds" is the FileOrdChooser.
 o  For the "hyperlink" field, there is currently no OrdChooser that will work. 
    However, you can still manually enter an ord.


#########################################################################
3  alarmRdb
#########################################################################

=========================================================================
3.1  Fixed
=========================================================================

*** 3.1:8628  Need ability to export alarm histories to SQL ***
  Record Type:  Enhancement
  Resolved In:  3.2.7
The alarmRdb module has been added for using a Rdbms as the alarm database.

The module contains an AlarmService for each type of Rdms that is supported
(eg. SqlServerAlarmService, OracleAlarmService, Db2AlarmService).

The alarmRdb module requires the use of the rdb module for getting connections
to the Rdms. First the user should configure the connection to the Rbms using
the rdb driver. Then the user should add the appropriate RdbAlarmService. The
RdbAlarmService contains a property to select the Rdbms to use for the alarm
database.

This list contains only the appropriate types of Rdms for the AlarmService (eg.
SqlServerAlarmService can only use a SqlServerDatabase).

Once an Rdms is selected through the AlarmService's property sheet, the
AlarmService will be availiable for use.

#########################################################################
4  backup
#########################################################################

=========================================================================
4.1  Fixed
=========================================================================

*** 4.1:6891  Restore of backup dist does not restore OS time zone ***
  Record Type:  Enhancement
  Resolved In:  3.1.1
If a device is restored using a backup distribution file produced by 
version 3.0 software, its station time zone will be restored but its operating 
system time zone will not.

If the OS time zone is different from the station time zone, most station
and workbench time functions will continue to work and display correctly, 
though time stamps in some log output will not.  A warning message
will be displayed in a station's console output if the time zones are out
of sync:

WARNING [hh:mm:ss dd-mmm-yy tz] OS Time zone 'STD' is not the same as the station time zone 'Europe/London'

In build 3.1.1, backup files will capture the OS time zone and the distribution
installer will restore them.

As a workaround, if necessary after restoring a 3.0 backup dist file, you can
set the OS time zone using the platform's Platform Administration view, or use
the station's PlatformServices container view.   

Note that the QNX and Windows operating systems are not capable of fully 
supporting some locations' daylight savings rules, and in those locations
eliminating the warning will not be possible.


*** 4.1:6995  Backup dists did not capture the NRE version ***
  Record Type:  Bug
  Resolved In:  3.0.88
Backups did not properly restore the nre-core-*.dist file because the backup 
omitted the nre-core dependency.  This was fixed starting in build 3.0.88.

To work around this problem for backups made prior to build 3.0.88, after
restoring a backup, use the Distribution Installer or Software Manager to 
install the correct nre-core-*.dist file.  Note this step will be unnecessary
if the backup was made with build 3.0.88 or later.

*** 4.1:7160  Unable to restore backup dist files created by HX user ***
  Record Type:  Bug
  Resolved In:  3.0.93
Distribution (.dist) files sent by the station's BackupService to a web browser
user with "Default Hx Profile" were corrupt, and could not be used later to 
restore systems.

This problem exists in versions 3.0.92 and earlier, and is fixed in 3.0.93.
To get backup dist files from stations having version 3.0.92 or earlier,
administrators should log on from Workbench, or from a web browser logged in as
a user with a Wb Web Profile (not an Hx Profile).

*** 4.1:7413  Backup dist for QNX-basd JACE did not save port.properties ***
  Record Type:  Bug
  Resolved In:  3.1.5
Historically, when performing a backup of any QNX-based JACE (403, 545, etc), 
its serial port configuration (set using the SerialPortPlatformService of a 
station) was skipped, meaning not contained in the backup dist. This was due to
the location of the file "port.properties". 

Beginning in 3.1.5, the port.properties is now stored in the /niagara/lib
directory where it will be properly backed up. JACEs being upgraded will move
the file from its original location (/etc) to /niagara/lib.

*** 4.1:7569  Installing a backup dist does not remove existing station ***
  Record Type:  Bug
  Resolved In:  3.1.1
When a JACE running a station is restored by installing a backup dist file 
produced by version 3.0 software, the station that was present prior to the 
restore may still exist (two installed stations). In 3.1.1 this was fixed,
backup dist files will correctly remove existing stations when installed. 

After installing a version 3.0 backup dist file, administrators should verify
that only one station exists on the host (Station Director or Station Copier 
platform view). The Station Copier can be used to delete any station that 
should not be present.

*** 4.1:7685  Allow history and alarm data to be included in offline backups ***
  Record Type:  Enhancement
  Resolved In:  3.1.2
When a backup is made from the Platform Administration view when connected to 
a JACE with its station stopped (an "offline" backup), the backup should be 
able to include files that are unsafe to backup while the station is running
(an "online" backup).  Examples include alarms and histories.

In release 3.1, a station's BackupService provides this ability using two 
additional properties: "offlineExcludeFiles" and "offlineExcludeDirectories".
These properties are used instead of "excludeFiles" and "excludeDirectories" 
to filter the backup files when an offline backup is performed.  By default, 
the new properties do not contain exclusions for alarm or history files.


*** 4.1:8522  Dist files produced by online backup did not contain JVM reference ***
  Record Type:  Bug
  Resolved In:  3.1.19
This affects only 3.1 builds before 3.1.19.   When backup is made against a running station (an online 
backup) the dist file that is created contains no reference to a Java Virtual Machine version, so if the 
dist file is installed to an empty device (e.g. a new JACE), the station will fail on startup because the JVM will be 
missing.

To work around this problem in 3.1 builds earlier than 3.1.19, administrators can make offline backups
(stop the station and use the backup button on the Platform Administration view).

Alternately, after installing a backup dist that's missing the JVM reference, you can use the Distribution 
Installer (again) to install the JVM dist.  Find the JVM dists in your Workbench's software database 
by directing the installer here:

!sw/2.2.20050407/ibm-j9-qnx-ppc.dist    - contains a suitable VM for QNX Jaces, and 
!sw/1.5.0/sun-jre-win-x86.dist          - contains a Win32 VM.

*** 4.1:9388  Installing backup dists does not delete existing lexicon directories ***
  Record Type:  Bug
  Resolved In:  3.2.6
Distribution files created by AX 3.0 and 3.1 versions of the backup service
do not include instructions to "clean" existing files from a host's !lexicon
directory when it's installed.

AX 3.2 versions of the backup service, beginning with build 3.2.6, correctly
include instructions to delete files from !lexicon that aren't contained in
the backup distribution file when it's installed.

#########################################################################
5  baja
#########################################################################

=========================================================================
5.1  Fixed
=========================================================================

*** 5.1:3621  Incomplete config.bog backup files when JACE file system is near full. ***
  Record Type:  Bug
  Resolved In:  3.0.42; 3.0.91
If a JACE was operating with a nearly full file system, it was
possible that a station Save job would fail to make a complete
config.bog file, yet still show success. Starting in build 3.0.91,
this was fixed such that station Save failures are correctly
reported.

In the event of corrupting the config.bog, the first thing that
should be done is to free up space on the hard drive. Now to fix
the config.bog in order to start the station, first navigate to
the {station} directory.  If previous station saves occurred there
will be one "config.bog" and multiple config.bog backups which
look something like "config_backup_050805_0917.bog".  The 
"config.bog" should be noticeably smaller than the backups since
space ran out before the complete save. Finally, delete the incomplete
"config.bog" and rename the most recent, complete backup to "config.bog"
to replace it.  

*** 5.1:6953  Workbench did not load if region was set to some locales.  ***
  Record Type:  Bug
  Resolved In:  3.1.4
Niagara programs did not start in some locales, producing instead an
UnsupportedEncodingException error.  This seemed to happen more frequently with
Asian locales. Testing with regional options on Windows XP revealed the problem
existed for the following languages:

Arabic - ar Cp1256
Hebrew - iw Cp1255
Japanese - ja MS932
Korean - ko MS949
Thai - th MS874
Vietnamese - vi Cp1258
Chinese (Hong Kong & Taiwan) zh MS950
Chinese (Songapore & PRC) zh GBK

Setting file.encoding=utf8 in nre.properties allowed each of the tested locales
to work.  Beginning in 3.1.4, this change to nre.properties became the default,
and this problem should not occur.

If running a build prior to 3.1.4, the recommended workaround is to edit the 
lib\nre.properties file as follows:

java.options=-Xmx120M -Dfile.encoding=utf8



*** 5.1:7017  Slot using RelTime with Min/Max facets displayed incorrectly ***
  Record Type:  Bug
  Resolved In:  3.1.3
Properties of type baja:RelTime ignored any configured facets for Minimum 
values and always showed in milliseconds.  This was fixed starting in 3.1.3,
where negative RelTimes now correctly display using slot facets.

*** 5.1:7045  Potential long delay when opening fox or platform connection (socket) ***
  Record Type:  Bug
  Resolved In:  3.0.89
There is a bug (#5092063) in HotSpot 1.5 where sockets attempt a reverse DNS
lookup when they're constructed with a raw IP address string. Tridium opened
support issue 829982 with Sun to attempt to get a fix rolled into an 1.5 update
(this is an ongoing issue).

Although Niagara goes to great lengths to cache Internet addresses, this bug manifests
itself with potential delays opening a socket to a numeric IP address for the
first time (Fox or Platform are the big examples). Experience on Tridium's
internal LAN shows that unnamed hosts introduce a 5 second delay during the reverse
DNS lookup. This bug can also result in unintended side effects when using
numeric IP addresses in an attempt to avoid DNS dependencies (such as a recover 
from a power failure).

The workaround uses special code that by-passes the reverse DNS
lookup in the HotSpot java.net library by explicitly disabling proxy server
checks. This workaround can be toggled with the following entry in the
system.properties file:

# This is a boolean property which lets us work around bug 5092063
# in HotSpot 1.5, where socket opens attempt to do reverse DNS lookups
# on numeric IP addresses.  If this property is true (default), then we 
# force BIpHost.openSocket() to never use a proxy, thereby by-passing 
# the reverse DNS lookup.  This check has no effect in J2ME.
#ipHost.noProxy=true 

This workaround was implemented starting in build 3.0.89.


*** 5.1:7140  Category Manager doesn't handle memory exception well ***
  Record Type:  Bug
  Resolved In:  3.0.91
Using large or spare non-contiguous indices for categories can lead to
excessive memory usage. 

Starting in build 3.0.91, the Category.index property is bound between
0 and 100.

*** 5.1:7141  Categories (in station's CategoryService) need fault cause ***
  Record Type:  Enhancement
  Resolved In:  3.1.3
Categories created with a duplicate index number go into fault, but there was
no "fault cause" indication (despite this being the only reason for a fault).
Starting in build 3.1.3, a Category has a "Fault Cause" property, visible in
its property sheet as well as the Category Manager view of the CategoryService.

*** 5.1:7151  User with admin Read permission can change other users' properties ***
  Record Type:  Bug
  Resolved In:  3.0.91
There was a security flaw such that a user with operator write permission
and admin read permission on the UserService could change other user's
passwords.  

Starting in build 3.0.91, users with opWrite+adminRead have readonly access to
all accounts, but only write access to their own account.

*** 5.1:7181  Security hole could allow station users access to files in Niagara home directory ***
  Record Type:  Function
  Resolved In:  3.0.91
There was a security flaw that allowed a station's non-superusers to access 
directories outside of station home using a relative backup such as 
"file:^../..".  This was fixed starting in build 3.0.91.

The fix makes absolute "file:" ords with a ".." backup path illegal syntax 
so that they can be used as valid ords.

Ords like this are now disallowed:
  file:^..
  file:^../..
  file:^../foo.txt
  file:!
  file:!../..
  file:!../foo.txt 
  file:!
  file:^foo/../../bar
  file:/..



*** 5.1:7395  Audit history did not use facets for formatting new and old value ***
  Record Type:  Bug
  Resolved In:  3.1.3
A station's AuditHistory did not apply facets when recording old value and new
value operations for numeric points--instead, a precision of 1 (decimal) was
always used. This was fixed starting in build 3.1.3.  Now, the AuditHistory
applies the source facets when formatting record fields for:
 - property changed old value
 - property changed new value
 - action invocation argument

*** 5.1:7505  Enhance BAbsTime to accept xs:dateTime format ***
  Record Type:  Enhancement
  Resolved In:  3.0.95
Although BAbsTime has always followed a strict ISO 8601 format, the
XML Schema spec defines a slightly different format which we did not
support including:
  - ability to leave fractional seconds out completely
  - ability to have fractional seconds with greater precision than 1ms
  - ability to use Z to indicate UTC

The BAbsTime.decodeToString() method has been modified to be more flexible,
such that it can now decode the full range of xs:dateTime formats.  Note
the encodeToString() remains the same and will never be changed to preserve
backward compability, but likely a new method will be added in 3.1 to
output using string xs:dateTime format (where timezone is always indicated
fully as +/-hh:mm or Z).

These changes will make it easier for developers to use BAbsTime in their
web services and XML Schema compliant documents.  This issue was fixed in
3.0.95.

*** 5.1:7507  Add ability to force GC in spy pages ***
  Record Type:  Enhancement
  Resolved In:  3.0.95
A new "spy:/util/gc" page has been added which allows a user to force a call
to run the Java VM garbage collector.  The spy page reports heap memory
usage before and after the call to GC.

*** 5.1:7608  PlatformService in QNX-based JACE issues time zone Warning ***
  Record Type:  Bug
  Resolved In:  3.1.1
A station running on a QNX-based JACE configured for a certain time zone may
issue a platform service warning at startup, for example:

WARNING [19:32:36 01-Nov-05 GMT][platform] OS Time zone 'STD (+0/+1)' is not
 the same as the station time zone 'Europe/London (+0/+1)'

This occurs when checking the OS time zone against the Niagara time zone. 
If the time zones are not equivalent, and can be seen in standard output 
and in the station's LogHistory.  

Release 3.0 software does not properly recognize the daylight savings rule 
equivalence for certain time zones, listed below. For these time zones, all 
times will display and work correctly, so the warnings can be safely ignored.

In release 3.1.1, warnings for the following time zones will no longer display:

AET
Africa/Ceuta
America/Havana
America/Scoresbysund
America/Winnipeg
Arctic/Longyearbyen
Asia/Almaty
Asia/Amman
Asia/Anadyr
Asia/Aqtau
Asia/Aqtobe
Asia/Baghdad
Asia/Irkutsk
Asia/Istanbul
Asia/Kamchatka
Asia/Krasnoyarsk
Asia/Magadan
Asia/Nicosia
Asia/Novosibirsk
Asia/Omsk
Asia/Oral
Asia/Qyzylorda
Asia/Sakhalin
Asia/Vladivostok
Asia/Yakutsk
Asia/Yekaterinburg
Asia/Yerevan
Atlantic/Azores
Atlantic/Canary
Atlantic/Faeroe
Atlantic/Jan_Mayen
Atlantic/Madeira
Australia/ACT
Australia/Adelaide
Australia/Broken_Hill
Australia/Canberra
Australia/Hobart
Australia/Melbourne
Australia/NSW
Australia/South
Australia/Sydney
Australia/Tasmania
Australia/Victoria
Australia/Yancowinna
CET
Canada/Central
Cuba
ECT
EET
Eire
Europe/Amsterdam
Europe/Andorra
Europe/Athens
Europe/Belfast
Europe/Belgrade
Europe/Berlin
Europe/Bratislava
Europe/Brussels
Europe/Bucharest
Europe/Budapest
Europe/Chisinau
Europe/Copenhagen
Europe/Dublin
Europe/Gibraltar
Europe/Helsinki
Europe/Istanbul
Europe/Kaliningrad
Europe/Kiev
Europe/Lisbon
Europe/Ljubljana
Europe/London
Europe/Luxembourg
Europe/Madrid
Europe/Malta
Europe/Minsk
Europe/Monaco
Europe/Moscow
Europe/Nicosia
Europe/Oslo
Europe/Paris
Europe/Prague
Europe/Riga
Europe/Rome
Europe/Samara
Europe/San_Marino
Europe/Sarajevo
Europe/Simferopol
Europe/Skopje
Europe/Sofia
Europe/Stockholm
Europe/Tallinn
Europe/Tirane
Europe/Tiraspol
Europe/Uzhgorod
Europe/Vaduz
Europe/Vatican
Europe/Vienna
Europe/Vilnius
Europe/Warsaw
Europe/Zagreb
Europe/Zaporozhye
Europe/Zurich
GB
GB-Eire
MET
NET
Poland
Portugal
Turkey
W-SU
WET


*** 5.1:7672  Memory used much larger after station restart ***
  Record Type:  Bug
  Resolved In:  3.0.99; 3.1.2
It was found that following a restart, a station would use much larger amounts
of RAM than when initially created.  For example, a station with 10 LON nodes
would report used memory of 4994kb, but after restart would report used memory
of 11150kb (in both cases, measured after garbage collection).

Further, it was found that duplicating components (rather than creating new) 
would also result in significantly larger RAM usage.  For example, a station
with 10 LON nodes created largely by duplication would report used memory of
9118kb. Following a station restart, it would report 15998kb RAM used.

In 3.0.99, a change was made in the station's baja bog processor (BogDecoder) 
to fix this, by "interning" given combinations of BSimples by Type and String.
This creates only one BSimple instance for each of the various combinations,
resulting in less RAM used when processing the station's bog file.

*** 5.1:7736  Support added for JACE-NXS to have specific HostId prefix and model ***
  Record Type:  Enhancement
  Resolved In:  3.1.10
The new Win32-based JACE platform, the JACE-NXS, now reports its Host ID using
an "NXS" prefix, for example: NXS-B7F3-1125-5AD3-8895.  In addition, its "model"
designation, as seen in platform views and in the Station Manager view of the 
NiagaraNetwork, displays as "JNXS".

*** 5.1:7742  StationResourceManager engine.scan.usage could display 0% ***
  Record Type:  Bug
  Resolved In:  3.1.3
Prior to build 3.1.3 and in all 3.0.x builds, the Resource Manager view on
a station would sometimes show 0% for the "engine.scan.usage" value, at least
for stations running on a Win32-based platform. In build 3.1.3 the 
StationResourceManager has been modified to correctly calculate and display the
engine.scan.usage percentage for all platforms.

*** 5.1:7743  Control logic with circular links causes high CPU usage even when values do not change. ***
  Record Type:  Bug
  Resolved In:  3.1.6
It was found that "circular feedback" links could cause very high CPU usage
even though values were not changing.  An example could be two NumericWritables,
with the output of each point linked to an input of the other point.  A small
collection of these would push CPU usage to 80%, yet values would be static.

Starting in build 3.1.6, two changes were made to address this:

 ControlPoint was changed so its output property is not set unless its working
 value has actually changed.  This eliminates link propagations when values are
 not changing.

 Better diagnostics were added to the Spy pages for a station, namely under
 sysManagers -> engineManagers, the top 100 engine manager consumers are listed.

*** 5.1:7897  SoftJACE HostId change ***
  Record Type:  Function
  Resolved In:  3.1.6
Starting in build 3.1.6, NiagaraAX on a Windows PC requires one of two 
different hostId configurations, depending on platform: 

a) A PC for an AxSupervisor or Engineering Workstation uses a standard hostId,
   prefixed with "Win-".
 
b) A SoftJACE PC uses a special hostId, which requires a property setting
   in its nre.properties file to be set to:
 
   softjace=true
 
   In this configuration, the SoftJACE's hostId is prefixed with "WinSJ-". 
   
Installation of either platform type should perform the necessary configuration. 

*** 5.1:8029  Application specific views through registry ***
  Record Type:  Enhancement
  Resolved In:  3.1.7
(Developer's Release Note)
In many cases appliance developers need to register appliance specific views on common components
such as the UserService or alarm:ConsoleRecipient.  By default registering appliance specific views
automatically show up globally in everyone's Workbench or Hx UI.  Starting in build 3.1.7, a new 
registry feature allows appliance developers to declare their agents as only applicable to a specific
application defined by a WbProfile or HxProfile.  Refer to the Agents section within the Registry 
chapter of docDeveloper for more information.

*** 5.1:8156  External composite links remain after internal components are deleted ***
  Record Type:  Enhancement
  Resolved In:  3.2.12
Previously when removing components which were used as either the source
or target of of a composite, the composite slots would remain orphaned.
In 3.2 deleting components will automatically check if those components are
used as either the source or target of a composite (via the composite 
property flag) and if so automatically remove the composite slots and any
links to or from those composite slots.  This cleanup works recursively
when using composite slots exposed as composite slots.  This feature 
also supports a full implementation of undo and redo.

*** 5.1:8281  COMPOSITE slot flag added for future use ***
  Record Type:  Enhancement
  Resolved In:  3.1.15
(Developer's Release Note)
A new slot flag called "Composite" was added (symbol "p").  It is needed for 
future use.  The Composite flag should be set on any slot (property, action, or
topic) and link that is created as part of the composite feature of Niagara.  
It will be used in the future to determine how to properly cleanup slots and 
links that were originally created as part of the composite functionality.

Developers should use this flag on slots/links when they are originally
created as a composite slot/link.  The Composite Editor has already been
updated to add this flag to any slots and links that are created using it.

*** 5.1:8285  Niagara not backward compatible with new frozen BComponent slots ***
  Record Type:  Bug
  Resolved In:  3.2.5
If you connect to a station that is running a different version of Niagara AX
than your Workbench, you may experience trouble accessing certain components
in the station database.  If the component in the Workbench version contains
additional child slots that are frozen, and of type BComponent or a subclass
of BComponent, you will be unable to access the child slots of that component
in the JACE station.  In addition, you will see an exception message in the 
Workbench console, if it is open.

Unfortunately, as of Build 3.1.14, there is no way to recover from this
situation without bringing the module that defines the component to the same
version in the JACE (running the station), as is in your Workbench.  However, 
this is all that needs to be done to allow access to the components.  Once you
have brought the module in the JACE to the same version as the module in your
Workbench, no further modifications to the station database or the components 
in question are necessary.
Previous to 3.2 if a frozen slot was added to a type where the value of
the property was a subclass of BComponent, then Workbench would not 
correctly handle backward compatibility.  The error in the console typically
looked like this:

  ERROR: SyncOp.commit: Load: <containing component name here>
    java.lang.IllegalStateException: generateHandle in proxy space
    
From Niagara AX 3.2 onwards Workbench backward compatibility for this
scenerio should function correctly.  The new frozen slot which exists
in the Workbench version but not in the station version is ignored and
will have the hidden flag automatically set so that it is not visible
to users.


*** 5.1:8292  Station auto-save called excessively ***
  Record Type:  Bug
  Resolved In:  3.1.15; 3.0.101
It was found that the "station auto-save" feature could get called 
excessively, because the calculated time delta was based upon the 
last successful save, not the last save attempt.  If an attempt fails
because of an unrecoverable error (such as disk full), there is no
reason to immediately attempt another save.

Starting in builds 3.0.101 and 3.1.15, the auto-save code was fixed to
only attempt a single save within the auto-save period.  Note that you
can adjust a JACE's auto-save configuration by opening a station running
on the JACE, and going to Config > Services > PlatformServices property
sheet.

*** 5.1:8591  JACE-2 station start problem, Baja failed to load with Null Pointer in TimeFormat ***
  Record Type:  Bug
  Resolved In:  3.0.102
It was possible that a JACE-2 unit running build 3.0.99. may fail to boot with
the following exception:

ERROR [19:34:35 08-Aug-06 GST][sys] Cannot boot java.lang.NullPointerException
   at com.tridium.util.TimeFormat.<init>(Unknown Source) 

*** 5.1:8627  Deleting a dynamic slot that is the source of a link will leave an orphan link on target component. ***
  Record Type:  Bug
  Resolved In:  3.2.5
Previous versions of Niagara did not guarantee that links to and from a
dynamic slot were cleaned up properly when that slot was deleted.  If the
slot was deleted on the LinkSheet, then some cleanup was done.  However if
the slot was deleted programmatically via other means, then no cleanup was
performed.  In 3.2 the core component engine will always delete all links 
to and from a dynamic slot when that dynamic slot is deleted.

*** 5.1:8823  Loading system.properties generates an ArrayIndexOutOfBoundsException ***
  Record Type:  Bug
  Resolved In:  3.0.102; 3.1.24; 3.2.1
If the system.properties file on a QNX-based JACE does not have a CR/LF after 
the last entry or comment in the file, the following message will appear in 
standard output:

 ERROR: Cannot load /ffs0/niagara/lib/system.properties:
 java.lang.ArrayIndexOutOfBoundsException

This error message can safely be ignored. 

It can be eliminated by editing system.properties and adding a CR/LF after the
last property.


*** 5.1:8852  Added max.heap value to Resource Manager view of station on QNX-based JACE ***
  Record Type:  Enhancement
  Resolved In:  3.1.24; 3.2.1
On QNX-based JACEs, the heap.total reported by the station's Resource Manager 
view does not always reflect the true maximum size of the heap.  

For these units, a heap.max value was added that reflects the maximum possible
heap size.  Note that heap size can be limited by the available installed RAM
and/or licensing.

*** 5.1:8932  Update timezones.xml and baja module to support new 2007 time zone rules ***
  Record Type:  Enhancement
  Resolved In:  3.0.104; 3.0.99; 3.1.29; 3.2.3
Summary
-------
The United States has planned a change to its DST observance beginning in 2007.
The Energy Policy Act of 2005 mandates that DST will start on the second Sunday
in March and end on the first Sunday in November. In 2007, the start and stop
dates will be March 11 and November 4, respectively. These dates are different
from previous DST start and stop dates. In 2006, the dates were the first
Sunday in April (April 2, 2006) and the last Sunday in October (October 29,
2006)

Changes
-------
The following changes have been made to NiagaraAX to support the change:

- In release 3.0 builds 3.0.104 and later and release 3.1 builds 3.1.29 and
later, the time zone reference file (lib/timezones.xml) contains the 2007 DST
rules for U.S. time zones.
- In the devkit module with the same build versions, the ImportJRETimezones
utility has been modified to generate time zone rules that are easier to
syncronize with OS time zones.
- In the baja module with these build versions, a bug has been fixed which
caused stations to crash when loading the 2007 time zone rules.  Also, since
the IBM J9 VM (in all QNX-based JACEs) does not yet include the 2007 rules, 
the baja module has been changed so that it no longer favors the VM's time zone 
definition over the Niagara definition when serializing AbsTime values.

Because having time zone rules that are defined inconsistently between Niagara
and the VM can cause AbsTime values to be incorrect, it is *not* recommended
that customers simply change their timezones.xml files (or edit to have new
2007 rules) without also upgrading the baja module.

Limitations
-----------
Currently, the NiagaraAX time zone API maps each time zone to a single set of
rules. If the rules change over time, translations to and from local times may
become incorrect. For example, the correct local time in New York for Midnight
November 1, 2006 UTC is 7:00 pm, but if the 2007 DST rule is used, it will be
incorrectly expressed as 8:00 pm.

The time zone API will be changed in a future release to address that issue.

Also, although the time zone definitions in the NiagaraAX time zone API and 
the Sun Microsystems JRE are up to date, updated definitions for the IBM J9 VM, 
used on all QNX-based platforms (e.g. JACE-2, -4, -5 series) are not yet available.   
For this reason, use of java.util.TimeZone in any Niagara applications is strongly
discouraged - Niagara's BTimeZone class should be used instead.

Finally, it should be noted that because log services are started before
Niagara time zones are available, the timestamps in a station's console log 
messages are formatted using an instance of java.util.Timezone defined
by the VM.   For the reasons described above, this can result in the
timestamps in the console being off by an hour during affected periods.  
Although it's misleading to an administrator reading the console output
when this happens, it does not affect the functioning of the station.

*** 5.1:8945  Improve internal engine timer performance ***
  Record Type:  Enhancement
  Resolved In:  3.2.1
The original execution engine managed all timers as a single linked list, requiring a complete scan 
of the list based on the deadline of the next timer expiration.  The 3.2 engine now automatically
manages timers in three separate buckets - a short, medium, and long queue.  This requires only 
scanning the linked list of similar timers on expiration.  Internally, future config of the min/max
scan bounds for each timer bucket is possible.  The change also includes more aggresive caching of 
Clock.ticks and Clock.millis to avoid excessive monitor locking.  

The timer buckets are:

  short:  0-2sec     (100ms - 1sec  bounds)
  medium: 2sec-1min  (1sec  - 10sec bounds)
  long:   1min+      (1sec  - 30sec bounds)

*** 5.1:8960  Test Framework ***
  Record Type:  Enhancement
  Resolved In:  3.2.1
The baja module contains a new test framework under javax.baja.test.  
Refer to the new Test chapter in docDeveloper for more information.

*** 5.1:9026  Composite source knobs did not display when programming offline ***
  Record Type:  Bug
  Resolved In:  3.2.2
When composite slots were created offline, the source knob for
the links were not displayed.  Closing and reopening the bog file
did display all the links correctly.

This has been fixed--all composite links should now display immediately.

*** 5.1:9232  SyncOp out of sync ***
  Record Type:  Bug
  Resolved In:  3.2.10
Previously, under rare circumstances it was possible for the client (Workbench) and server (station) 
to get out of sync.  For example, if a BComponent in the station was changed using a set operation 
while that component is being loaded on the workbench side (and the workbench side was making subsequent
calls back to the server), the cached client side handles could get out of sync with the server side handles.  
An exception was thrown similar to the ones below, but the out of sync condition was not repaired.  

The problem turned out to be related to the fact that SyncOps could be processed out of order on the
client side.  This behavior was changed so that SyncOps are processed in order, thus fixing the 
potential for sync problems between the client and server.

The following example exception was from an instance of the problem encountered in Lonworks 
Device Manager.  After the initial java.lang.IllegalStateException various exceptions are thrown.  
The workbench requires a restart to correctly display the view.


From the Workbench console: 

ERROR: SyncOp.commit: Load: /Drivers/LonNetwork/Uv
java.lang.IllegalStateException: from.h != to.h -> 7da8 != 7d66
        at javax.baja.sync.LoadOp.syncComponent(LoadOp.java:70)
        at javax.baja.sync.LoadOp.syncValue(LoadOp.java:186)
        at javax.baja.sync.LoadOp.syncComponent(LoadOp.java:139)
        at javax.baja.sync.LoadOp.commit(LoadOp.java:57)
        at javax.baja.sync.SyncBuffer.commit(SyncBuffer.java:179)
        at com.tridium.fox.sys.broker.BBrokerChannel.syncFromMaster(BBrokerChannel.java:1018)
        at com.tridium.fox.sys.broker.BBrokerChannel.subscribe(BBrokerChannel.java:597)
        at com.tridium.fox.sys.broker.BFoxComponentSpace$FoxSubscribeCallbacks.subscribe(BFoxComponentSpace.java:395)
        at javax.baja.sys.Subscriber.subscribe(Subscriber.java:115)
        at javax.baja.workbench.view.BWbComponentView.registerForComponentEvents(BWbComponentView.java:96)
        at com.tridium.lonworks.ui.device.BLonDeviceManager.registerFolder(BLonDeviceManager.java:413)
        at com.tridium.lonworks.ui.device.BLonDeviceManager.reloadValue(BLonDeviceManager.java:384)
        at com.tridium.lonworks.ui.device.BLonDeviceManager.handleComponentEvent(BLonDeviceManager.java:502)
        at javax.baja.workbench.view.BWbComponentView.route(BWbComponentView.java:142)
        at javax.baja.workbench.view.BWbView$WbViewBinder.event(BWbView.java:317)
        at com.tridium.sys.schema.ComponentSlotMap.fireComponentEvent(ComponentSlotMap.java:894)
        at com.tridium.sys.schema.ComponentSlotMap.add(ComponentSlotMap.java:1664)
        at javax.baja.sys.BComponent.add(BComponent.java:694)
        at javax.baja.sync.AddOp.commit(AddOp.java:45)
        at javax.baja.sync.SyncBuffer.commit(SyncBuffer.java:179)
        at com.tridium.fox.sys.broker.BBrokerChannel.syncFromMaster(BBrokerChannel.java:1018)
        at com.tridium.fox.sys.broker.BBrokerChannel$ClientSyncThread.run(BBrokerChannel.java:1115)
ERROR [12:00:19 13-Nov-06 EST][FoxSpace] subscribe(/Drivers/LonNetwork/Cvahu/deviceData): com.tridium.fox.session.Server
Exception: javax.baja.naming.UnresolvedException: 7df1
com.tridium.fox.session.ServerException: javax.baja.naming.UnresolvedException: 7df1
        at com.tridium.fox.sys.LocalizableExceptionTranslator.messageToException(LocalizableExceptionTranslator.java:92)
        at com.tridium.fox.session.FoxSession.sendSync(FoxSession.java:367)
        at com.tridium.fox.sys.BFoxConnection.sendSync(BFoxConnection.java:378)
        at com.tridium.fox.sys.BFoxChannel.sendSync(BFoxChannel.java:132)
        at com.tridium.fox.sys.broker.BBrokerChannel.subscribe(BBrokerChannel.java:596)
        at com.tridium.fox.sys.broker.BFoxComponentSpace$FoxSubscribeCallbacks.subscribe(BFoxComponentSpace.java:395)
        at javax.baja.sys.Subscriber.subscribe(Subscriber.java:115)
        at javax.baja.workbench.view.BWbComponentView.registerForComponentEvents(BWbComponentView.java:96)
        at com.tridium.lonworks.ui.device.BLonDeviceManager.registerFolder(BLonDeviceManager.java:413)
        at com.tridium.lonworks.ui.device.BLonDeviceManager.reloadValue(BLonDeviceManager.java:384)
        at com.tridium.lonworks.ui.device.BLonDeviceManager.handleComponentEvent(BLonDeviceManager.java:502)
        at javax.baja.workbench.view.BWbComponentView.route(BWbComponentView.java:142)
        at javax.baja.workbench.view.BWbView$WbViewBinder.event(BWbView.java:317)
        at com.tridium.sys.schema.ComponentSlotMap.fireComponentEvent(ComponentSlotMap.java:894)
        at com.tridium.sys.schema.ComponentSlotMap.add(ComponentSlotMap.java:1664)
        at javax.baja.sys.BComponent.add(BComponent.java:694)
        at javax.baja.sync.AddOp.commit(AddOp.java:45)
        at javax.baja.sync.SyncBuffer.commit(SyncBuffer.java:179)
        at com.tridium.fox.sys.broker.BBrokerChannel.syncFromMaster(BBrokerChannel.java:1018)
        at com.tridium.fox.sys.broker.BBrokerChannel$ClientSyncThread.run(BBrokerChannel.java:1115)
ERROR: SyncOp.commit: Load: /Drivers/LonNetwork/Mnlrh103
java.lang.IllegalStateException: from.h != to.h -> 7e23 != 7df1
        at javax.baja.sync.LoadOp.syncComponent(LoadOp.java:70)
        at javax.baja.sync.LoadOp.syncValue(LoadOp.java:186)
        at javax.baja.sync.LoadOp.syncComponent(LoadOp.java:139)
        at javax.baja.sync.LoadOp.commit(LoadOp.java:57)
        at javax.baja.sync.SyncBuffer.commit(SyncBuffer.java:179)
        at com.tridium.fox.sys.broker.BBrokerChannel.syncFromMaster(BBrokerChannel.java:1018)
        at com.tridium.fox.sys.broker.BBrokerChannel$ClientSyncThread.run(BBrokerChannel.java:1115)
ERROR: SyncOp.commit: Reorder: /Drivers/LonNetwork/Mnlrh103
java.lang.ArrayIndexOutOfBoundsException: no dynamic props
        at com.tridium.sys.schema.ComponentSlotMap.reorder(ComponentSlotMap.java:1970)
        at javax.baja.sys.BComponent.reorder(BComponent.java:890)
        at javax.baja.sync.ReorderOp.commit(ReorderOp.java:43)
        at javax.baja.sync.SyncBuffer.commit(SyncBuffer.java:179)
        at com.tridium.fox.sys.broker.BBrokerChannel.syncFromMaster(BBrokerChannel.java:1018)
        at com.tridium.fox.sys.broker.BBrokerChannel$ClientSyncThread.run(BBrokerChannel.java:1115)
ERROR [12:00:21 13-Nov-06 EST][FoxSpace] subscribe(/Drivers/LonNetwork/Cvahu/deviceData): com.tridium.fox.session.Server
Exception: javax.baja.naming.UnresolvedException: 7df1
com.tridium.fox.session.ServerException: javax.baja.naming.UnresolvedException: 7df1
        at com.tridium.fox.sys.LocalizableExceptionTranslator.messageToException(LocalizableExceptionTranslator.java:92)
        at com.tridium.fox.session.FoxSession.sendSync(FoxSession.java:367)
        at com.tridium.fox.sys.BFoxConnection.sendSync(BFoxConnection.java:378)
        at com.tridium.fox.sys.BFoxChannel.sendSync(BFoxChannel.java:132)
        at com.tridium.fox.sys.broker.BBrokerChannel.subscribe(BBrokerChannel.java:596)
        at com.tridium.fox.sys.broker.BFoxComponentSpace$FoxSubscribeCallbacks.subscribe(BFoxComponentSpace.java:395)
        at javax.baja.sys.Subscriber.subscribe(Subscriber.java:115)
        at javax.baja.workbench.view.BWbComponentView.registerForComponentEvents(BWbComponentView.java:96)
        at com.tridium.lonworks.ui.device.BLonDeviceManager.registerFolder(BLonDeviceManager.java:413)
        at com.tridium.lonworks.ui.device.BLonDeviceManager.reloadValue(BLonDeviceManager.java:384)
        at com.tridium.lonworks.ui.device.BLonDeviceManager.handleComponentEvent(BLonDeviceManager.java:502)
        at javax.baja.workbench.view.BWbComponentView.route(BWbComponentView.java:142)
        at javax.baja.workbench.view.BWbView$WbViewBinder.event(BWbView.java:317)
        at com.tridium.sys.schema.ComponentSlotMap.fireComponentEvent(ComponentSlotMap.java:894)
        at com.tridium.sys.schema.ComponentSlotMap.add(ComponentSlotMap.java:1664)
        at javax.baja.sys.BComponent.add(BComponent.java:694)
        at javax.baja.sync.AddOp.commit(AddOp.java:45)
        at javax.baja.sync.SyncBuffer.commit(SyncBuffer.java:179)
        at com.tridium.fox.sys.broker.BBrokerChannel.syncFromMaster(BBrokerChannel.java:1018)
        at com.tridium.fox.sys.broker.BBrokerChannel$ClientSyncThread.run(BBrokerChannel.java:1115)
ERROR: SyncOp.commit: Load: /Drivers/LonNetwork/Mnlrh103
java.lang.IllegalStateException: from.h != to.h -> 7e23 != 7df1
        at javax.baja.sync.LoadOp.syncComponent(LoadOp.java:70)
        at javax.baja.sync.LoadOp.syncValue(LoadOp.java:186)
        at javax.baja.sync.LoadOp.syncComponent(LoadOp.java:139)
        at javax.baja.sync.LoadOp.commit(LoadOp.java:57)
        at javax.baja.sync.SyncBuffer.commit(SyncBuffer.java:179)
        at com.tridium.fox.sys.broker.BBrokerChannel.syncFromMaster(BBrokerChannel.java:1018)
        at com.tridium.fox.sys.broker.BBrokerChannel.subscribe(BBrokerChannel.java:597)
        at com.tridium.fox.sys.broker.BFoxComponentSpace$FoxSubscribeCallbacks.subscribe(BFoxComponentSpace.java:395)
        at javax.baja.sys.Subscriber.subscribe(Subscriber.java:115)
        at javax.baja.sys.Subscriber.subscribe(Subscriber.java:90)
        at javax.baja.sys.Subscriber.subscribe(Subscriber.java:74)
        at com.tridium.workbench.job.JobMonitor.handleComponentEvent(JobMonitor.java:189)
        at com.tridium.workbench.job.JobMonitor$MySubscriber.event(JobMonitor.java:320)
        at com.tridium.sys.schema.ComponentSlotMap.fireComponentEvent(ComponentSlotMap.java:894)
        at com.tridium.sys.schema.ComponentSlotMap.add(ComponentSlotMap.java:1664)
        at javax.baja.sys.BComponent.add(BComponent.java:694)
        at javax.baja.sync.AddOp.commit(AddOp.java:45)
        at javax.baja.sync.SyncBuffer.commit(SyncBuffer.java:179)
        at com.tridium.fox.sys.broker.BBrokerChannel.syncFromMaster(BBrokerChannel.java:1018)
        at com.tridium.fox.sys.broker.BBrokerChannel$ClientSyncThread.run(BBrokerChannel.java:1115)
ERROR [12:00:22 13-Nov-06 EST][FoxSpace] subscribe(/Drivers/LonNetwork/Cvahu/deviceData): com.tridium.fox.session.Server
Exception: javax.baja.naming.UnresolvedException: 7df1
com.tridium.fox.session.ServerException: javax.baja.naming.UnresolvedException: 7df1
        at com.tridium.fox.sys.LocalizableExceptionTranslator.messageToException(LocalizableExceptionTranslator.java:92)
        at com.tridium.fox.session.FoxSession.sendSync(FoxSession.java:367)
        at com.tridium.fox.sys.BFoxConnection.sendSync(BFoxConnection.java:378)
        at com.tridium.fox.sys.BFoxChannel.sendSync(BFoxChannel.java:132)
        at com.tridium.fox.sys.broker.BBrokerChannel.subscribe(BBrokerChannel.java:596)
        at com.tridium.fox.sys.broker.BFoxComponentSpace$FoxSubscribeCallbacks.subscribe(BFoxComponentSpace.java:395)
        at javax.baja.sys.Subscriber.subscribe(Subscriber.java:115)
        at javax.baja.workbench.view.BWbComponentView.registerForComponentEvents(BWbComponentView.java:96)
        at com.tridium.lonworks.ui.device.BLonDeviceManager.registerFolder(BLonDeviceManager.java:413)
        at com.tridium.lonworks.ui.device.BLonDeviceManager.reloadValue(BLonDeviceManager.java:384)
        at com.tridium.lonworks.ui.device.BLonDeviceManager.handleComponentEvent(BLonDeviceManager.java:502)
        at javax.baja.workbench.view.BWbComponentView.route(BWbComponentView.java:142)
        at javax.baja.workbench.view.BWbView$WbViewBinder.event(BWbView.java:317)
        at com.tridium.sys.schema.ComponentSlotMap.fireComponentEvent(ComponentSlotMap.java:894)
        at com.tridium.sys.schema.ComponentSlotMap.add(ComponentSlotMap.java:1664)
        at javax.baja.sys.BComponent.add(BComponent.java:694)
        at javax.baja.sync.AddOp.commit(AddOp.java:45)
        at javax.baja.sync.SyncBuffer.commit(SyncBuffer.java:179)
        at com.tridium.fox.sys.broker.BBrokerChannel.syncFromMaster(BBrokerChannel.java:1018)
        at com.tridium.fox.sys.broker.BBrokerChannel$ClientSyncThread.run(BBrokerChannel.java:1115)
ERROR: SyncOp.commit: Load: /Drivers/LonNetwork/Mnlrh103
java.lang.IllegalStateException: from.h != to.h -> 7e23 != 7df1
        at javax.baja.sync.LoadOp.syncComponent(LoadOp.java:70)
        at javax.baja.sync.LoadOp.syncValue(LoadOp.java:186)
        at javax.baja.sync.LoadOp.syncComponent(LoadOp.java:139)
        at javax.baja.sync.LoadOp.commit(LoadOp.java:57)
        at javax.baja.sync.SyncBuffer.commit(SyncBuffer.java:179)
        at com.tridium.fox.sys.broker.BBrokerChannel.syncFromMaster(BBrokerChannel.java:1018)
        at com.tridium.fox.sys.broker.BBrokerChannel$ClientSyncThread.run(BBrokerChannel.java:1115)
ERROR: SyncOp.commit: Reorder: /Drivers/LonNetwork/T7350Cs
java.lang.ArrayIndexOutOfBoundsException: no dynamic props
        at com.tridium.sys.schema.ComponentSlotMap.reorder(ComponentSlotMap.java:1970)
        at javax.baja.sys.BComponent.reorder(BComponent.java:890)
        at javax.baja.sync.ReorderOp.commit(ReorderOp.java:43)
        at javax.baja.sync.SyncBuffer.commit(SyncBuffer.java:179)
        at com.tridium.fox.sys.broker.BBrokerChannel.syncFromMaster(BBrokerChannel.java:1018)
        at com.tridium.fox.sys.broker.BBrokerChannel$ClientSyncThread.run(BBrokerChannel.java:1115)
ERROR [12:00:23 13-Nov-06 EST][FoxSpace] subscribe(/Drivers/LonNetwork/Cvahu/deviceData): com.tridium.fox.session.Server
Exception: javax.baja.naming.UnresolvedException: 7df1
com.tridium.fox.session.ServerException: javax.baja.naming.UnresolvedException: 7df1
        at com.tridium.fox.sys.LocalizableExceptionTranslator.messageToException(LocalizableExceptionTranslator.java:92)
        at com.tridium.fox.session.FoxSession.sendSync(FoxSession.java:367)
        at com.tridium.fox.sys.BFoxConnection.sendSync(BFoxConnection.java:378)
        at com.tridium.fox.sys.BFoxChannel.sendSync(BFoxChannel.java:132)
        at com.tridium.fox.sys.broker.BBrokerChannel.subscribe(BBrokerChannel.java:596)
        at com.tridium.fox.sys.broker.BFoxComponentSpace$FoxSubscribeCallbacks.subscribe(BFoxComponentSpace.java:395)
        at javax.baja.sys.Subscriber.subscribe(Subscriber.java:115)
        at javax.baja.workbench.view.BWbComponentView.registerForComponentEvents(BWbComponentView.java:96)
        at com.tridium.lonworks.ui.device.BLonDeviceManager.registerFolder(BLonDeviceManager.java:413)
        at com.tridium.lonworks.ui.device.BLonDeviceManager.reloadValue(BLonDeviceManager.java:384)
        at com.tridium.lonworks.ui.device.BLonDeviceManager.handleComponentEvent(BLonDeviceManager.java:471)
        at javax.baja.workbench.view.BWbComponentView.route(BWbComponentView.java:142)
        at javax.baja.workbench.view.BWbView$WbViewBinder.event(BWbView.java:317)
        at com.tridium.sys.schema.ComponentSlotMap.fireComponentEvent(ComponentSlotMap.java:894)
        at com.tridium.sys.schema.ComponentSlotMap.fire(ComponentSlotMap.java:1274)
        at javax.baja.sys.BComponent.fire(BComponent.java:1051)
        at javax.baja.sync.FireTopicOp.commit(FireTopicOp.java:42)
        at javax.baja.sync.SyncBuffer.commit(SyncBuffer.java:179)
        at com.tridium.fox.sys.broker.BBrokerChannel.syncFromMaster(BBrokerChannel.java:1018)
        at com.tridium.fox.sys.broker.BBrokerChannel$ClientSyncThread.run(BBrokerChannel.java:1115)
ERROR: SyncOp.commit: Load: /Drivers/LonNetwork/Mnlrh103
java.lang.IllegalStateException: from.h != to.h -> 7e23 != 7df1
        at javax.baja.sync.LoadOp.syncComponent(LoadOp.java:70)
        at javax.baja.sync.LoadOp.syncValue(LoadOp.java:186)
        at javax.baja.sync.LoadOp.syncComponent(LoadOp.java:139)
        at javax.baja.sync.LoadOp.commit(LoadOp.java:57)
        at javax.baja.sync.SyncBuffer.commit(SyncBuffer.java:179)
        at com.tridium.fox.sys.broker.BBrokerChannel.syncFromMaster(BBrokerChannel.java:1018)
        at com.tridium.fox.sys.broker.BBrokerChannel$ClientSyncThread.run(BBrokerChannel.java:1115)
ERROR: SyncOp.commit: Reorder: /Drivers/LonNetwork/LonDevice
java.lang.ArrayIndexOutOfBoundsException: actual count 1 != param count 131
        at com.tridium.sys.schema.ComponentSlotMap.reorder(ComponentSlotMap.java:1971)
        at javax.baja.sys.BComponent.reorder(BComponent.java:890)
        at javax.baja.sync.ReorderOp.commit(ReorderOp.java:43)
        at javax.baja.sync.SyncBuffer.commit(SyncBuffer.java:179)
        at com.tridium.fox.sys.broker.BBrokerChannel.syncFromMaster(BBrokerChannel.java:1018)
        at com.tridium.fox.sys.broker.BBrokerChannel$ClientSyncThread.run(BBrokerChannel.java:1115)


From station console:

javax.baja.naming.UnresolvedException: 7df1
 at javax.baja.space.BComponentSpace.resolveByHandle(Unknown Source)
 at javax.baja.space.BHandleScheme.resolve(Unknown Source)
 at javax.baja.naming.BOrd.resolve(Unknown Source)
 at javax.baja.naming.BOrd.resolve(Unknown Source)
 at javax.baja.naming.BOrd.get(Unknown Source)
 at com.tridium.fox.sys.broker.BBrokerChannel.fromOrd(Unknown Source)
 at com.tridium.fox.sys.broker.BBrokerChannel.subscribe(Unknown Source)
 at com.tridium.fox.sys.broker.BBrokerChannel.process(Unknown Source)
 at com.tridium.fox.sys.BFoxConnection.process(Unknown Source)
 at com.tridium.fox.session.SessionDispatcher.dispatch(Unknown Source)
 at com.tridium.fox.session.SessionDispatcher.run(Unknown Source)
 at java.lang.Thread.run(Unknown Source)
javax.baja.naming.UnresolvedException: 7df1
 at javax.baja.space.BComponentSpace.resolveByHandle(Unknown Source)
 at javax.baja.space.BHandleScheme.resolve(Unknown Source)
 at javax.baja.naming.BOrd.resolve(Unknown Source)
 at javax.baja.naming.BOrd.resolve(Unknown Source)
 at javax.baja.naming.BOrd.get(Unknown Source)
 at com.tridium.fox.sys.broker.BBrokerChannel.fromOrd(Unknown Source)
 at com.tridium.fox.sys.broker.BBrokerChannel.subscribe(Unknown Source)
 at com.tridium.fox.sys.broker.BBrokerChannel.process(Unknown Source)
 at com.tridium.fox.sys.BFoxConnection.process(Unknown Source)
 at com.tridium.fox.session.SessionDispatcher.dispatch(Unknown Source)
 at com.tridium.fox.session.SessionDispatcher.run(Unknown Source)
 at java.lang.Thread.run(Unknown Source)
javax.baja.naming.UnresolvedException: 7df1
 at javax.baja.space.BComponentSpace.resolveByHandle(Unknown Source)
 at javax.baja.space.BHandleScheme.resolve(Unknown Source)
 at javax.baja.naming.BOrd.resolve(Unknown Source)
 at javax.baja.naming.BOrd.resolve(Unknown Source)
 at javax.baja.naming.BOrd.get(Unknown Source)
 at com.tridium.fox.sys.broker.BBrokerChannel.fromOrd(Unknown Source)
 at com.tridium.fox.sys.broker.BBrokerChannel.subscribe(Unknown Source)
 at com.tridium.fox.sys.broker.BBrokerChannel.process(Unknown Source)
 at com.tridium.fox.sys.BFoxConnection.process(Unknown Source)
 at com.tridium.fox.session.SessionDispatcher.dispatch(Unknown Source)
 at com.tridium.fox.session.SessionDispatcher.run(Unknown Source)
 at java.lang.Thread.run(Unknown Source)
javax.baja.naming.UnresolvedException: 7df1
 at javax.baja.space.BComponentSpace.resolveByHandle(Unknown Source)
 at javax.baja.space.BHandleScheme.resolve(Unknown Source)
 at javax.baja.naming.BOrd.resolve(Unknown Source)
 at javax.baja.naming.BOrd.resolve(Unknown Source)
 at javax.baja.naming.BOrd.get(Unknown Source)
 at com.tridium.fox.sys.broker.BBrokerChannel.fromOrd(Unknown Source)
 at com.tridium.fox.sys.broker.BBrokerChannel.subscribe(Unknown Source)
 at com.tridium.fox.sys.broker.BBrokerChannel.process(Unknown Source)
 at com.tridium.fox.sys.BFoxConnection.process(Unknown Source)
 at com.tridium.fox.session.SessionDispatcher.dispatch(Unknown Source)
 at com.tridium.fox.session.SessionDispatcher.run(Unknown Source)
 at java.lang.Thread.run(Unknown Source)


*** 5.1:9959  Virtual Components should default to use Virtual Gateway's security ***
  Record Type:  Bug
  Resolved In:  3.2.15; 3.3.1
It was discovered that non super users were experiencing problems when trying
to view virtual components.  The problem turned out to be due to the fact
that since BVirtualComponents are transient/on-demand components, they should
default to use the parent virtual gateway's security settings (permissions, 
assigned categories).  However, prior to this fix, virtuals weren't looking
to the parent virtual gateway for their default security settings, and as a result,
exceptions would occur when logged in as a non super user and trying to use 
virtuals.

This issue has now been fixed, so that the default BVirtualComponent behavior
routes its security related callbacks to the parent virtual gateway.  As a 
result, for category inheritance (for example), virtual components will default 
to use the parent virtual gateway's categories.  

Another change you will notice as a result of this fix is that only the 
virtual gateway will have the "Category Sheet" view available.  Any descendant
virtual components will no longer have this view available by default.
This is because the virtual gateway is persistent (and not the virtual components),
so editing the categories for the virtual gateway will be stored and used
by any descendant virtual components by default.

*** 5.1:10230  Deleting internal composite links leaves orphaned slots ***
  Record Type:  Bug
  Resolved In:  3.3.10
When a user tries to manually delete a slot (in particular, a link)
that is marked with the 'Composite' flag, the following 
warning dialog will now be prompted for the user to confirm:

  You are about to manually delete a slot 
  associated with a composite.  Manual deletion
  of slots marked with the 'Composite' flag can 
  sometimes lead to "orphaned" slots on other 
  components associated with the composite. 
  Are you sure you want to continue?

=========================================================================
5.2  Open
=========================================================================

*** 5.2:3133  Make component space of read-only bog file read-only ***
  Record Type:  Bug
  Resolved In:  
When working with components that exist inside a read-only bog file, the
system will allow changes to be made to the components.  However if the user
attempts to save the bog itself, an error will be raised since the bog file
is read-only.  This can happen for palette bogs which are read-only by virtue
of existing within a zip file, or via bogs which are read-only on the file
system.

#########################################################################
6  bajaui
#########################################################################

=========================================================================
6.1  Fixed
=========================================================================

*** 6.1:273  Copy should be disabled for login passwords ***
  Record Type:  Bug
  Resolved In:  3.0.25; 3.0.102; 3.1.24; 3.2.1
Workbench login password text field previously were fixed to disable copying (via Ctrl+C),
but still allowed the password to be copied using cut (Ctrl+X).  The password 
text field (BTextfield) was fixed to never allow copying in either copy or cut.

*** 6.1:4960  Drop downs menus don't work with dual monitor setup ***
  Record Type:  Bug
  Resolved In:  3.1.3
When using a dual monitor display, any drop down menus or drop down selection
boxes do not adjust for a Workbench session that has been moved to the second
display. You click on the menus in the second display, and the drop down shows
up on the first display (absolute verses relative).

The primary bug was that we "clipped" popup menus to the screen bounds so that
they wouldn't go off the screen. However, we always assumed the primary screen
was being used. Starting in 3.1.3, we check which screen workbench is running
on and use that screen's bounds for popup menu clipping.

A secondary fix required upgrading HotSpot to the latest patch release 1.5.0_02
to 1.5.0_06. The older version did report the correct screen device on startup
until the window was moved back and forth between screens.



*** 6.1:7180  Infinite "Insert disk" errors when using Detail View option in File Chooser ***
  Record Type:  Bug
  Resolved In:  3.0.91
When using the File Chooser dialog in Workbench, if you used the Details View
option you could encounter an endless series of "insert disk" popup dialogs 
from Windows, even if not accessing drive A:.  Starting in build 3.0.91, these 
Windows popups are suppressed when accessing file system roots, or drives
other than drive A:. 

In the event of receiving continuous "Insert disk" errors, the best way
to stop them without terminating Workbench is to hold down the "Esc" key,
which will exit the File Chooser.


*** 6.1:7273  Error/exception when creating a new directory in Directory Chooser ***
  Record Type:  Bug
  Resolved In:  3.0.92
In the Directory Chooser dialog, if without first selecting an existing directory, 
you attempted to create a new directory (click on "Create a new directory" button),
an error would occur.  Error details said "java.lang.NullPointerException".

In 3.0.92 this was fixed.  Now, the Create Directory button is unavailable
until you first select an existing directory.

*** 6.1:7275  Created folder did not show up in Directory Chooser until refresh ***
  Record Type:  Bug
  Resolved In:  3.0.92
The Directory Chooser had a bug where attempting to create a new directory 
directly under the root node in the tree would not update the folder tree 
shown in the dialog.  To see the new folder, you had to cancel, and then 
reopen the Directory Chooser.
This was fixed in 3.0.92.  Now, the Directory Chooser correctly updates 
the folder tree when a new directory is created.

*** 6.1:7554  Support for non-English text input needed ***
  Record Type:  Enhancement
  Resolved In:  3.1.6
Previous versions of NiagaraAX disabled support for Input Methods used
to enter Asian text, because it crashed Workbench running in a browser when
using older versions of the Java plugin. Affected were Chinese, Japanese,
and Korean text input to Workbench--for example, entry of text directly 
into the Lexicon. As a workaround, you could type the text in Notepad, and 
then copy and paste it into Workbench.

Starting in 3.1.6, input methods were enabled such that Asian text is more 
easily entered into Workbench text fields. NiagaraAX currently uses a "passive
client" design, which means that text entry will popup an external window with 
the input method editor. Committing the text with Enter will populate the 
Niagara text field and close the input method editor popup.

*** 6.1:7882  Binding degrade behavior for bound widgets ***
  Record Type:  Enhancement
  Resolved In:  3.1.6
Previously if a binding could not be resolved or was not usable due to security permissions, there
was no easy way to reflect this in the bound widget.  Starting in 3.1.6, a "binding degrade" feature
adds a new property to all bajaui:Bindings called degradeBehavior with a choice of none, disable, or hide.
If a binding is not usable, then this property allows the designer to choose how the UI is gracefully
degraded.  For example, if the user doesn't have permission to invoke a specific action, then a button
bound to that action can be grayed out or hidden entirely.

To preserve backward compatibility, the default degradeBehavior is none.

The following methods were added to the BBinding API:

  - BBinding.getDegradeBehavior()
  - BBinding.setDegradeBehavior()  
  - BBinding.isDegraded
  - BBinding.applyDegradeBehavior()
  
The specification of isDegraded() for various binding types:

  - Binding: if not bound (default case)
  - ActionBinding: if not bound or if invoke permission is unavailable
  - SetPointBinding: if not bound or if write permission is unavailable  

*** 6.1:8123  Setting Tab Placement to Center throws null pointer exception ***
  Record Type:  Bug
  Resolved In:  3.1.10
If a Tabbed Pane is created and its Tab Placement is set to Center, an
error popup reads: "Could not invoke the command 'null'" and an exception
is generated.  In 3.1.10 this was fixed, so if such an invalid setting (in 
this context) is found, Tab Placement is reverted back to Top.

*** 6.1:8304  An indeterminate progress bar available for unbounded tasks ***
  Record Type:  Enhancement
  Resolved In:  3.2.5
(Developer Release Note)
BProgressBar now contains a "indeterminate" property for unbounded tasks.
If set, the widget will display a constant "striping" animation.

*** 6.1:8762  Bound value could be incorrect if it changed while PxView loaded  ***
  Record Type:  Bug
  Resolved In:  3.0.102; 3.1.24; 3.2.1
A race-condition bug was fixed, where a PxView binding to a simple or struct 
within a component might not display the correct value if the value changed 
during the window of time while the PxView was loading, and then did not 
change again.

*** 6.1:8879  Preserve identity in Px encoder/decoder with new API ***
  Record Type:  Enhancement
  Resolved In:  3.2.1
(Developer Release Note)
Previously a Px file could specify the slot name of all slots using the
"name" attribute, but did not have control over including names during
encoding.  No support was provided for handles.

In 3.2 a new API on PxEncoder allows a developer to explictly turn on support 
for encoding all names and handles via the PxEncoder.setPreserveIdentities()
method call.  The PxDecoder automatically sets BComponent handles if it 
encounters an "h" attribute.

*** 6.1:8949  Make extension file filter in File Chooser case-insensitive ***
  Record Type:  Enhancement
  Resolved In:  3.2.2; 3.1.27
When using the File Chooser dialog, any extension filter choice ("Files of type:")
was formerly case senstive. This was changed (the ExtFileFilter in BFileDialog)
such that the case of the selected file extension is now ignored. So, if you
filter on { "jpg", ... }, then "*.jpg", "*.JPG", "*.Jpg" are now all valid files
that appear with that filter applied.

*** 6.1:9175  BWindow.isActive() API removed ***
  Record Type:  Enhancement
  Resolved In:  3.2.3
The bajaui:BWindow.isActive() method which has been available since Niagara 3.0
has been removed in 3.2. It is unsupported on some platforms, and appears to be
largely unused (no use of it was found in the Tridium codebase).

*** 6.1:9756  Right click in property sheet view does same thing as left click. (Linux only) ***
  Record Type:  Bug
  Resolved In:  3.2.14
Right-clicking now works correctly in PropertySheet when running on Linux.

#########################################################################
7  bql
#########################################################################

=========================================================================
7.1  Fixed
=========================================================================

*** 7.1:7875  BQL does not appear to use slot facets to display StatusNumeric values. ***
  Record Type:  Bug
  Resolved In:  3.2.14
Status type values were not using the precision specified
in the facets when translated to string as part of a BQL query
result.  BQL now uses the slot facets for the string conversion
so the precision of the formatted value will be correct.

*** 7.1:8388  BQL Queries of type "Schedule" do not locate TriggerSchedules ***
  Record Type:  Bug
  Resolved In:  3.2.2
BqlQueryBuilder now has better support for finding schedule types
in a query.  It previously had some bugs where some types would not
be found.

#########################################################################
8  chart
#########################################################################

=========================================================================
8.1  Fixed
=========================================================================

*** 8.1:5175  Need a way to zoom all the way out on a chart ***
  Record Type:  Enhancement
  Resolved In:  3.2.4
A "No Zoom" (zoom all the way out) button was added to the pan control widget
that appears when you are zoomed in on a chart.  After zooming in several
times, this allows you to see the whole chart again with a single click.

*** 8.1:5784  HistoryChart adds Export to Pdf and Svg ***
  Record Type:  Enhancement
  Resolved In:  3.1.3
Beginning in 3.1.3, the History Chart view has exporters to PDF and SVG (click
Export, select exporter in Export dialog). The SVG exporter is a prototype.
Please note that Pie charts will not export to PDF, however, the SVG exporter
supports all chart types.

*** 8.1:6955  Y-axis tick increment changes on vertical pan in chart ***
  Record Type:  Bug
  Resolved In:  3.2.4
In some cases, vertical panning in a chart could result in the chart
shrinking vertically, changing the y-axis tick values.  This was fixed
so that panning causes no zooming artifacts.

*** 8.1:7062  Chart should ignore {stale} flagged history samples ***
  Record Type:  Bug
  Resolved In:  3.0.92
Previously, the History Chart view would display data that had the "{stale}"
status flag marked.  This was not the correct default behavior because data marked
as stale is not always reliable.  Starting in build 3.0.92, the default behavior
was changed so that stale values are not displayed in the History Chart view.
However, you can still view stale data in the other history views--for example,
the History Table and History Editor.

*** 8.1:7170  "Last Month" history filter does not chart any data. ***
  Record Type:  Bug
  Resolved In:  3.0.91
The "Last Month" and "Last Year" history queries were not working.  These 
queries were fixed starting in build 3.0.91.

Both queries are commonly used in the History Chart, History Table, and History 
Editor views of a history.  Basically, the end time of these 
query selections was being calculated incorrectly, so in most cases people 
reported seeing little or no data for these two choices.  For example,
if the current month is August of 2005, and you selected to query a history for
"Last Month" data, the old query would have requested data for 

    start: July 1, 2005 00:00:00:000
    end: July 1, 2005 23:59:59:999
    
This query is obviously using the wrong end day for "Last Month", so it has 
been fixed. Using the same example as above, the query as of build 3.0.91
results in:

    start: July 1, 2005 00:00:00:000
    end: July 31, 2005 23:59:59:999
    
The "Last Year" query has also been fixed; its old behavior would have been
similar to the incorrect old behavior for "Last Month".

*** 8.1:7758  Current cursor position shows value displayed on chart ***
  Record Type:  Enhancement
  Resolved In:  3.1.2
Starting in build 3.1.2, a new feature is added in chart views. When you hover
the mouse over a chart - it will display a popup showing a date/timestamp and
value at that point, which allows you to view the exact value at any time.

*** 8.1:7880  Incorrect time format sometimes displayed in charts ***
  Record Type:  Bug
  Resolved In:  3.1.6
In some 3.0 builds (e.g., 3.0.99) it was found that history charts would display
x-axis date/time values formatted incorrectly, especially if the Workbench options
or user options were set for 24-hour time format display.  In build 3.1.6 this
was fixed--charts now use Workbench's current settings for date and time display.

*** 8.1:8142  Charting enhancements for 3.1 ***
  Record Type:  Enhancement
  Resolved In:  3.1.25; 3.2.1
As of build 3.1.7, the following charting enhancements have been made:

1. Support for new chart types:
   - Area
   - Discrete Area
   - Bar
   - StackedBar
   - Pie
   
2. Rollups for numeric history data. Rollups allow min, max, 
   average and sum per a specific interval in a time range.

3. Can hover the mouse over chart to get the exact value and 
   time for that intersetion on each set of axes.  This value
   is defined by the axis values, not by the actual series 
   data points. (also see issue 7758)

*** 8.1:8633  Time axis should always show start/end ***
  Record Type:  Enhancement
  Resolved In:  3.2.5; 3.1.31
Start time is now always displayed for charts.  The last tick mark will also
usually always be displayed.


*** 8.1:8671  ChartBuilder: Need positive way to indicate which y-axis scale is used for each data series. ***
  Record Type:  Enhancement
  Resolved In:  3.2.4
If multiple Y-axes exist on a chart (plotting histories with different value
ranges), each Y-axis now paints the corresponding swatches from the legend. 
This lets you see which series matches up with which Y-axis.

*** 8.1:9082  Better charting of histories across multiple timezones. ***
  Record Type:  Enhancement
  Resolved In:  3.2.2
The History Chart Builder has been enhanced to better handle the
charting of multiple histories from multiple timezones.  The following
improvements have been made:

First, the chart no longer "auto-calculates" the time axis when specific
times are requested. Prior to this change, requesting a time range with an
empty result would display 1970 on the time axis, because the time axis was
trying to auto-calculate bounds on an empty data set.

Second, for specific time range queries, the configured time range is "zoneless",
where each history is queried in its own timezone. Combined with the first
enhancement, the result is that the charts align by local time. That is, if
the user queries 8:00AM - 5:00PM for a history in EST and another in CST, the
values at 8:00AM for each history will align so that the 8:00AM values can be
visually compared.

Finally, a labeling bug was fixed that was introduced by the other charting
enhancements. This bug caused the time labels to use the local workbench
timezone regardless of the timezone that was actually being charted.

*** 8.1:9643  BITableToCsv and BITableToText don't use facets correctly ***
  Record Type:  Bug
  Resolved In:  3.2.12
Fixed BITableToCsv and BITableToText to correctly respect column
facets on the BITable object.  Which also fixes the original bug
where exporting chart data would not include the seconds in the
timestamp column.

BITableToCsv continues to only encode the value for non-AbsTime
types - not sure if this is correct or not - but seems to make
sense when trying to use numeric data in Excel.


*** 8.1:9845  chart scale alway 2 decimal places regardless of facets ***
  Record Type:  Enhancement
  Resolved In:  3.2.16; 3.3.1; 3.1.31
Chart values are now displayed using the facet precision of 
the point the history extension is associated with.

#########################################################################
9  control
#########################################################################

=========================================================================
9.1  Fixed
=========================================================================

*** 9.1:8018  Daily/Interval time triggers can get lost ***
  Record Type:  Bug
  Resolved In:  3.0.100; 3.1.7
A bug was found in the Control module's TimeTrigger component (Interval, Daily)
that in certain situations could cause the trigger to be lost and not execute.
Any object that used a TimeTrigger could have been affected, but in particular, 
this bug was noticeable when using a NiagaraHistoryImport descriptor to import 
a  history from another Niagara station, using a daily interval ("Daily" 
Trigger Mode value for the Execution Time property of the import descriptor).

This problem worsened if the Randomization option was used to specify the daily
execution interval--it was found that the random execution time might come and 
pass without the import executing.  If this occurred, it would not execute again
until a station restart or configuration change was made.

This bug was fixed in builds 3.0.100 and 3.1.7, such that this history import 
issue, as well as any other object using the TimeTrigger (especially if defined 
with a "Daily" TriggerMode) should no longer skip a planned execution.

*** 9.1:8882  DiscreteTotalizerExt did not permanently subscribe the parent point ***
  Record Type:  Bug
  Resolved In:  3.0.103; 3.1.25; 3.2.1
The DiscreteTotalizerExt did not permanently subscribe its parent point. Runtime
values were found to be incorrect unless some other extension was added, or the
point was linked into other control logic.  This was fixed; a DiscreteTotalizerExt
now causes its parent control point to be permanently subscribed.

#########################################################################
10  crypto
#########################################################################

=========================================================================
10.1  Fixed
=========================================================================

*** 10.1:7345  QNX-based JACEs now have SSL support ***
  Record Type:  Enhancement
  Resolved In:  3.0.92
Starting in build 3.0.92, SSL support (using the CryptoService) now works
in QNX-based JACEs (JACE-2, -4, -5 series).  The crypto module contains the
needed libraries for QNX-based hosts.

NOTE: The crypto module will have limited availability until government review
of export restrictions is completed.

*** 10.1:8586  Add licensing checks ***
  Record Type:  Enhancement
  Resolved In:  3.1.21
In order to comply with US export regulations on cryptographic software, the
crypto module now performs licensing checks. The required license feature is 
"crypto", and there is one boolean attribute "ssl".

*** 10.1:10841  SSL does not work on JACEs under AX 3.2 ***
  Record Type:  Bug
  Resolved In:  3.2.18; 3.3.18
Due to changes in IBM j9 VM version 2.3 used in Ax Release 3.2, SSL is not
supported on embedded QNX platforms; JACE-4xx, JACE-2xx, JACE-5xx and JACE-6xx.
Windows platforms; Web Supervisor, SoftJace, JACE-NXS support SSL in Ax Release
3.2.

If SSL is required on an embedded JACE, AX Release 3.1 or earlier will need to
be installed.

#########################################################################
11  devkit
#########################################################################

=========================================================================
11.1  Fixed
=========================================================================

*** 11.1:7304  Incorrect save changes dialog in Lexicon Editor ***
  Record Type:  Bug
  Resolved In:  3.1.4
The save changes dialog in the Lexicon Editor behaved incorrectly, where every
time a change was made, then an attempt was made to try to change modules or 
locale (by the two dropdowns), the message:

"View has been modified, save changes to "{0}"?" appeared.  

Also, pressing no and then changing the view agains repeats the dialog, even 
though no new changes took place.

Two changes were made to related to this. First:
"View has been modified, save changes to "{0}"?" has been cahnged to:
"View has been modified, save changes to "<lexicon> - <module>"?"

And secondly, the bug with the dialog popping up on every module of lexicon 
change after pressing "No" again has been fixed.


*** 11.1:7543  New Driver code would not compile network class ***
  Record Type:  Bug
  Resolved In:  3.0.96
*Developer Release Note*
When using the "New Driver" wizard in Workbench (under the Tools menu), the 
auto-generated code for the network had a faulty line.  Unless you made changes 
to the network code, trying to compile the auto-generated code would result in 
an exception similar to the one below.  Starting in build 3.0.96, this faulty 
auto-generated line was fixed--the auto-generated code should now compile before
any developer changes.

Parsing [D:\niagara\r3dev\rel\testDriver\build.xml]
Resolved [baja -> d:\niagara\r3dev\rel\modules\baja.jar]
Resolved [control -> d:\niagara\r3dev\rel\modules\control.jar]
Resolved [alarm -> d:\niagara\r3dev\rel\modules\alarm.jar]
Resolved [driver -> d:\niagara\r3dev\rel\modules\driver.jar]
Resolved [gx -> d:\niagara\r3dev\rel\modules\gx.jar]
Resolved [bajaui -> d:\niagara\r3dev\rel\modules\bajaui.jar]
Resolved [workbench -> d:\niagara\r3dev\rel\modules\workbench.jar]
Resolved [basicDriver -> d:\niagara\r3dev\rel\modules\basicDriver.jar]
Resolved [serial -> d:\niagara\r3dev\rel\modules\serial.jar]
Java Compile [com.tridium.testDriver]
D:/niagara/r3dev/rel/testDriver/src/com/tridium/testDriver/BTestDriverNetwork.java:58:48:58:
58: Semantic Error: Type "com.tridium.testDriver.BFooNetwork" was not found.
FATAL: Cannot compile package: com.tridium.testDriver

#########################################################################
12  driver
#########################################################################

=========================================================================
12.1  Fixed
=========================================================================

*** 12.1:7233  Add time calculation methods to BProxyExt ***
  Record Type:  Enhancement
  Resolved In:  3.1.3
(Developer's Release Note)
API enhancement: Starting in build 3.1.3, the following two methods were added
to driver:Tuning:

 /**
   * Convenience for translating getLastReadTicks() into a BAbsTime.
   * Return BAbsTime.NULL if no reads have occurred yet.
   */
  public final BAbsTime getLastReadTime()
  {                                               
    if (readTicks == 0) return BAbsTime.NULL;
    return BAbsTime.make(System.currentTimeMillis() - (Clock.ticks() - readTicks));
  }

  /**
   * Convenience for translating getLastWriteTicks() into a BAbsTime.
   * Return BAbsTime.NULL if no writes have occurred yet.
   */
  public final BAbsTime getLastWriteTime()
  {                                               
    if (writeTicks == 0) return BAbsTime.NULL;
    return BAbsTime.make(System.currentTimeMillis() - (Clock.ticks() - writeTicks));
  }


*** 12.1:7429  Force write upon WritablePoint user commands ***
  Record Type:  Enhancement
  Resolved In:  3.1.6
The proxy point framework is designed to allow flexible configuration
for when a point writes its value to an external device.  One of the use
cases we desire to support is to handle the case where both Niagara and an
external agent may be attempting to control the same point.  An example of
this might be a setpoint available for writing through Niagara, but also
changable through a local operator display.

By disabling automatic writes through the tuning policy, it is possible to
configure Niagara to write only when it is explicitly changed on the Niagara
side of things.  However, consider this scenerio
  - Niagara writes 75 to the device
  - It is changed to 77 locally, Niagara will read this value,
    but caches the fact that it last wrote 75
  - A user attempts to write 75 back to the device

In this case, Niagara will not write 75 to the device, because it doesn't think
the value has changed (last written value is a different variable then the last
read value). In order to make this scenerio work more intuitively, beginning in
build 3.1.6, the proxy point framework was changed so that any command action
invoked on a WritablePoint will force a write to the external device.

From an API perspective this change adds a new method to AbstractProxyExt
and ProxyExt called writablePointActionInvoked().  The default implementation
for ProxyExt is to set the forceWrite flag.

*** 12.1:7613  Default behavior on exceptions for readSubscribed() and write() ***
  Record Type:  Enhancement
  Resolved In:  3.1.1
(Developer Release Note)
In 3.0 if any proxy point (ProxyExt extends from BProxyExt, a BITunable)
raised an exception in a readSubscribed() or write(), it was dumped to 
standard output, but no other action was taken.  In some write scenarios,
(e.g. queue full) this was found to leave a writable point's ProxyExt in a 
"write pending" state, such that subsequent writes were not processed.  
This write failure issue was fixed in build 3.0.96, but only for serial-based
drivers (ProxyExt extends from BBasicProxyExt class)--see issue #7599.

In 3.1 the default behavior for all proxy points (extending from BProxyExt)
was improved on handling thrown exceptions:

- If write() throws an exception, then the writePending flag is cleared,
  and writeFail() is called to mark the point in fault.

- If readSubscribed() throws an exception, then readFail() is called
  to mark the point in fault.

There is no workaround for this issue in 3.0 systems. However, scenarios
where the old behavior becomes an issue are expected to be rare.

*** 12.1:7701  Ping Monitor did not stop immediately when disabled ***
  Record Type:  Bug
  Resolved In:  3.0.100; 3.1.2
When the Ping Monitor is disabled in most drivers, the monitoring of devices
does not stop immediately.  The disable does not take effect until the next
cycle through the list of devices.  This can sometime lead to the impression
that the disable did not take effect, as the devices are still being pinged.

In build 3.0.100, a disable of the Ping Monitor becomes immediately effective.
If running an earlier build and you disable the Ping Monitor, please note that
you must simply wait until the ping cycle completes before devices are not
pinged.

*** 12.1:7883  BProxyExt needs writeReset() callback for complete lifecycle. ***
  Record Type:  Enhancement
  Resolved In:  3.1.6
(Developer's Release Note)
In build 3.1.6, the following public method was added to 
javax.baja.driver.point.BProxyExt in order to make the proxy extension 
lifecycle complete:

  public void writeReset()

This method should be called when a pending write to the device is canceled or
short circuited.  This often happens when an attempt is made to write a value 
with a null status bit.  This method clears the fault cause and clears the 
tuning's write pending flag.

*** 12.1:7986  Negative time values disallowed in TuningPolicy ***
  Record Type:  Enhancement
  Resolved In:  3.1.7; 3.0.100
It was possible to set TuningPolicy properties MaxSendTime, MinSendTime, and 
StaleTime to negative values.  This was usually inadvertent, and had the same 
affect as a 0 time.  However, this could add to confusion when troubleshooting 
related behavior.  Starting in builds 3.0.100 and 3.1.7, slotFacets have been
added to limit these TuningPolicy properties to ensure only positive values.

*** 12.1:8137  Added ability to import histories from a delimited file (i.e. CSV) ***
  Record Type:  Enhancement
  Resolved In:  3.1.10
Starting in 3.1.10, the ability to import histories from a file (delimited file
such as CSV) was implemented. This feature was added to the driver module as
part of the new file support (i.e. FileNetwork -> FileDevice ->
FileHistoryDeviceExt -> FileHistoryImport descriptors). 

A view on the FileHistoryDeviceExt is called "Delimited File Import Manager". 
This manager view allows you to create delimited file import descriptors (or 
Excel CSV import descriptors). For each import descriptor you create, you are
prompted to define the target file (ord), as well as a mapping between the 
target file's columns and the history's columns. A file can only be imported 
if it has columns that corresponds to a history's timestamp and value column.
Optionally, you can import the status column if the particular file supports it.

Once the file import descriptors are created and initialized, they will work
just as other history import descriptors to periodically (or manually) import
data into a history from a file.

*** 12.1:8138  IFileDevice is an interface for devices supporting files ***
  Record Type:  Function
  Resolved In:  3.1.10
(Developer's enhancement release note) 
 Starting in 3.1.10, from a developer standpoint, BIFileDevice is the common interface that should be implemented by
a device that supports files (i.e. may be useful for file synchronization, file
importing, file exporting, etc). It might commonly be implemented by devices
that have a file system, and you can resolve files in the device's system given
relative Ords.

*** 12.1:8373  Add dropdown for Timestamp Format for file import descriptors ***
  Record Type:  Enhancement
  Resolved In:  3.1.18
When working under the "Delimited File Import Manager" view of a FileDevices's 
Histories extension (FileHistoryDeviceExt), any added file import descriptors 
(types DelimitedFileImport or ExcelFileCsvImport) now have an improved field 
editor for the "Timestamp Format" property.  Prior to this change, the editor 
was simply a String, that required you to manually type the timestamp format 
string.  The editor is now an (editable) drop-down list.  This allows you to 
enter your own custom timestamp format as a string (as before), or instead 
choose one of the predefined timestamp formats from the drop-down list.

*** 12.1:8456  Added collection 'Interval' property for history config override ***
  Record Type:  Enhancement
  Resolved In:  3.1.18
When using the Delimited File Import Manager view to create import descriptors
for files from which to import histories, there is a new property that can be
used to specify the collection interval of the imported history.  When creating 
a Delimited file import descriptor (or Excel CSV File import descriptor), the 
edit dialog will now display an 'Interval' property.  Users should always set 
this property to the collection interval of the original data being imported.
If it is not known or irregular, you can specify the collection interval as 
"irregular".

This collection 'Interval' property is important because it lets users specify 
what they think the collection interval should be for the imported history, and 
then if they want to start using Niagara objects to append data to the imported
history, they can configure their history extension to use the same collection 
interval, thus avoiding an incompatible configuration difference which results
in a split history.

*** 12.1:8514  Failure notification when duplicate timestamps detected in imported data ***
  Record Type:  Enhancement
  Resolved In:  3.1.19
During the history import process, it is important to fail fast when detecting 
a duplicate timestamp condition in the data being imported (duplicate timestamps
are not allowed in histories).  Previously, if a duplicate timestamp was 
discovered in the data being imported, there was not a useful indication given 
to the user to explain which timestamp was duplicated, so it was difficult for 
the user to take the appropriate actions to fix the raw data to import.  This 
has been improved, such that an error message indicating the duplicate timestamp 
is displayed in the 'Fault Cause' property of the import descriptor.

*** 12.1:8515  If file import fails, provide the line number where the failure occurred ***
  Record Type:  Enhancement
  Resolved In:  3.1.19
During the history import process, it is important to identify to the user if
an error occurred during the import process.  Previously, if an error occurred
while parsing through the lines of a file to import, there was not a useful 
indication given to the user to identify the line number where an error occurred, 
so it was difficult for the user to take the appropriate actions to fix the raw 
data to import.  This has been improved, such that an error message indicating 
the faulty line number is displayed in the 'Fault Cause' property of the 
import descriptor.

*** 12.1:8528  Sometimes Identifier pattern filter in history file import did not work ***
  Record Type:  Bug
  Resolved In:  3.1.19; 3.0.101
It was discovered that the pattern matching code did not handle empty strings 
appropriately.  This pattern matching code is used on the history file import
descriptors, as well as the config rule patterns for histories imported using
the Niagara Driver.  If the data being imported contained blank (empty) strings 
for a wildcard pattern, these empty strings were incorrectly allowed to pass 
unfiltered.  The code has now been fixed so that empty strings will be filtered 
out if the pattern string tells it to do so.

*** 12.1:8553  Poll thead spins if rate defined as 0s ***
  Record Type:  Bug
  Resolved In:  3.1.24; 3.2.1
If the Poll Service for a driver has its Fast Rate, Normal Rate, or Slow Rate 
configured to 0 seconds, and there are no objects subscribed to poll, the poll
thread will spin.  Note that the typical defaults for these rates are non-zero
values.  A separate but related issue (8779) applies to Poll Services in the
Bacnet driver, which are separated under each NetworkPort type.

Beginning in 3.1.24 and 3.2.1, a check was inserted to prevent this behavior.  
As a workaround in 3.0, avoid this problem by ensuring that the poll rates are
always greater than zero.

*** 12.1:8732  Importing boolean histories from integer columns always uses 'false' ***
  Record Type:  Bug
  Resolved In:  3.1.23; 3.2.1
There was a bug discovered when trying to import a CSV file using an integer 
column representing boolean values (i.e. 0 = false, 1 = true).  After importing
the boolean history, the result would have all false values.  This bug has now
been fixed, so that when an integer value other than zero is imported as a
boolean history record, it should use a value of true.

*** 12.1:9583  BDescriptors show inappropriate alarm, unackedAlarm statuses ***
  Record Type:  Bug
  Resolved In:  3.1.31; 3.2.16
When a device containing BDescriptors gets marked down, and then returns to normal, the descriptors can be left in
a state of {alarm, unackedAlarm}, even though nothing is wrong with them.  This is due to the way their status is
calculated, which uses the status from the device instead of their own status.  The incorrect status will be cleared
the next time the descriptors are executed.

BDescriptors are a base class for certain driver objects, such as ScheduleImportExts, ScheduleExports,
HistoryImports, and HistoryExports.  Depending on the specific driver implementation, you may not see the incorrect
status behavior in your driver.

Beginning in 3.1.31, and 3.2.15, the status is now computed correctly, and will not display the alarm status after
the device goes down and returns to normal.


*** 12.1:10184  configFatal() on BProxyExt ***
  Record Type:  Enhancement
  Resolved In:  3.3.10
The ability to indicate a fatal configuration fault in a BProxyExt has been
added for 3.3, similar to the capability that has previously existed in BDevice
and BDeviceNetwork.  Once invoked, the proxy extension goes into fault, and
cannot be cleared without restarting the station (and clearing whatever
problem drove the point into fault in the first place).


#########################################################################
13  email
#########################################################################

=========================================================================
13.1  Fixed
=========================================================================

*** 13.1:5622  Emails queued but not sent if multiple OutgoingAccounts ***
  Record Type:  Function
  Resolved In:  3.2.1; 3.1.25
It was found that newly-added email accounts (OutgoingAccounts) did not start
polling until a platform daemon restart. Emails queued, but were not sent.
This was fixed. The EmailService was modified to look for newly-added email 
accounts and poll them immediately.

*** 13.1:5627  OutgoingAccount changes and debug tools ***
  Record Type:  Function
  Resolved In:  3.2.1
It was discovered that the 'Max queue size'  was not working properly
in the outGoingAccount of the EmailService. The number of e-mails sent by
the EmailService was not being limited by the property. This has been fixed.

The user has control over various aspects of the EmailService's outGoingAccount.
They can set a maximum queue size, which will limit the number of e-mails sent
each day. They can also set a 'Persistent' property on the outGoingAccount to 
control whether the e-mail queue is saved on station restart. To change from 
disk-based persistence to RAM-based persistence, set the 'Persistent'
property found on the outGoingAccount property sheet. Setting this property
to TRUE tells the system to write the queue to disk. Setting 'Persistent' to
FALSE tells the system to only queue to RAM, which means the queue is lost
on a station restart.

For troubleshooting, if using 3.1.22 or later, you can change the log 
level in the station for email from Message to Trace (on station, 
Spy > logLevel, enable Trace). This lets you see how many emails get
sent per poll, and also see each individual email get queued up.

In addition, starting in 3.1.25 and 3.2.1, you can enable a "Debug"
property in an OutgoingAccount, so that all communication between
the target mail server and the station is also sent to standard output.

*** 13.1:6528  Alarms routed by the email service do not pass Unicode characters ***
  Record Type:  Enhancement
  Resolved In:  3.0.81
In earlier AX builds, alarms routed by email service did not properly pass
unicode characters in the subject field and body text of the email.  Often,
the "?" character was used instead. Starting in build 3.0.81, this problem
was fixed.  The charset for the subject and body of outgoing emails is now
explicitly set to UTF-8.

*** 13.1:6841  Binary file attachments not sent by Email ***
  Record Type:  Bug
  Resolved In:  3.1.19
An Email component has an "attachments" property using EmailPartList data
to specify attachments for delivery. Formerly, to attach a binary file it
was necessary to manually enter EmailParts, including the file name, MIME
type, and Blob part (bytes[] from the file).  This was difficult to set up,
and an Email did not actually send binary attachments before 3.1.19.

EmailPartList now has an "Add Attachment" action to improve this. When 
invoked, an ord to a file can be entered.  This automatically populates 
EmailParts for the file name, MIME type, and Blob information by reading 
the specified file.  Note that any file type may be attached to an Email
in this way, whether text types (e.g. .xml, .txt, .properties) or binary 
types (e.g. .zip, .jpg, .bog, .doc, .dll, .exe).

*** 13.1:7276  EmailService not clearing all sent emails ***
  Record Type:  Bug
  Resolved In:  3.0.92
Fixed in Build 3.0.92
After sending all alarm emails, one email would remain in the email folder.  
Upon each subsequent poll of the OutgoingAccount, another email would be sent 
for it. This happened in OutgoingAccounts configured as persistent.  The email 
was sent,  but then the file failed to delete because the underlying OS has a 
lock on the associated xml file.

Starting in build 3.0.92, this issue was fixed.  An OutgoingAccount now keeps 
track of which emails were sent, and will not send them again, even if their 
persistent file cannot be deleted.

*** 13.1:8863  EmailRecipient did not format alarmData in message body correctly ***
  Record Type:  Bug
  Resolved In:  3.1.25; 3.2.1
Alarm data in emails was being incorrectly formatted by the EmailRecipient, 
where the EmailRecipient was used as the base, instead of the Alarm Record.

For example:
 "%alarmData.presentValue% Is within the alarm limits" could appear as:
 "%err:email:EmailRecipient:alarmData% Is within the alarm limits"
instead of how it correctly appeared in the Alarm Console, as:
 "20.0 Is within the alarm limits"

This was fixed--the EmailRecipient now formats the alarm data in the email
using the Alarm Record as base, so this text should match that in the Alarm
Console.

*** 13.1:8927  EmailService could generate exceptions if host had empty domain address ***
  Record Type:  Bug
  Resolved In:  3.1.25; 3.0.103; 3.2.1
If a NiagaraAX host had its TCP/IP Configuration using an empty DNS Domain, 
EmailService operation could result in exceptions generated that looked like:
"javax.mail.MessageException: 501 5.0.0 HELO requires domain address".  This
was fixed; now the host IP is sent in cases where the domain address is blank.

In addition, the OutgoingAcccount and IncomingAccount components have a new
"Debug" property, which can be useful when troubleshooting issues with the
EmailService.  While set to true, all related mail server communication is
sent to the station's standard output. 

*** 13.1:9408  Emails will not send with jre 1.6 ***
  Record Type:  Bug
  Resolved In:  3.2.8
There is a bug in jre 1.6 which requires mail.jar to be in jre/lib/ext.

mail.jar was added to this directory for future releases of the distribution image (3.2.8 and
above). To fix this error in 3.2.6 or 3.2.7, simply download the JavaMail Api from  
http://java.sun.com/products/javamail/downloads/index.html, retrieve mail.jar from the
JavaMail zip file, and copy mail.jar to rel/jre/lib/ext

In 3.2.8 and above, The Email Service will not start without mail.jar in jre/lib/ext,
the following exception is generated to direct the user:

ERROR [16:02:11 08-Jan-07 EST][sys.service] Service start failed: Email Service
javax.baja.sys.BajaRuntimeException: EmailService will not trasmit and receive email without 
mail.jar in jre/lib/ext, download the the JavaMail Api from 
http://java.sun.com/products/javamail/downloads/index.html, retrieve mail.jar from the
JavaMail zip file, and copy to rel/jre/lib/ext.
   at javax.baja.email.BEmailService.serviceStarted(BEmailService.java:77)
   at com.tridium.sys.service.ServiceManager.startService(ServiceManager.java:176)
   at com.tridium.sys.service.ServiceManager.startAllServices(ServiceManager.java:157)
   at com.tridium.sys.station.Station.initServices(Station.java:151)
   at com.tridium.sys.station.Station.bootStation(Station.java:48)
   at com.tridium.sys.station.Station.main(Station.java:755)
   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
   at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
   at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
   at java.lang.reflect.Method.invoke(Method.java:597)
   at com.tridium.sys.Nre.runClass(Nre.java:201)
   at com.tridium.sys.Nre.main(Nre.java:126)


*** 13.1:10003  Email Storage Location Switching with active queue ***
  Record Type:  Bug
  Resolved In:  3.0.107; 3.1.31; 3.2.16
Perstistent emails now follow the storage location. For example, if 
persistence is turned on, the emails become persistent. Emails also follow 
the Persistence Location as it changes if persistence is turned on. This fix
is also required for Issue 10010, so that the queue size is more accurate.


#########################################################################
14  file
#########################################################################

=========================================================================
14.1  Fixed
=========================================================================

*** 14.1:7753  Export of Table to Text produces exception ***
  Record Type:  Bug
  Resolved In:  3.1.3
When performing an Export of a "Table to Text," for example in a Points Manager
view, an exception might occur if data contained non-ASCII characters. This 
could occur whether choosing "View internally" or "Save to file."  This was
fixed starting in build 3.1.3, where all text exports now default to UTF-8
encoding--the standard default for NiagaraAX.


*** 14.1:8223  Workbench created files/folders with '#' and ':' characters ***
  Record Type:  Bug
  Resolved In:  3.2.2
In various dialogs in Workbench (for example Directory Chooser), you could
add a file or folder that had one or more invalid characters "#" or ":", such
as "test#1" or "foo:bar.txt". The item would either be created but not
shown in the display (say "test#") or created with a truncated name ("foo"). 
This was fixed, such that name is checked as valid before creating a file or
folder in Workbench.

In earlier Workbench versions, avoid using invalid characters such as "#" or 
":" in file and folder names. 

#########################################################################
15  fox
#########################################################################

=========================================================================
15.1  Fixed
=========================================================================

*** 15.1:6959  Workbench disconnects from JACE station upon large copy/duplication  ***
  Record Type:  Bug
  Resolved In:  3.2.5
When duplicating or deleting a large number of components in a JACE station, 
Workbench may drop its connection to that station. This is most likely to occur
when pasting, duplicating, or deleting large (or multiple) folders or components.

The workaround in Workbench is to simply connect again to that JACE station.  In 
most cases, the command (copy/paste/delete) is completed properly.  However, if
this happens, it is recommended that you check to make sure that the operation 
completed successfully.
Previous versions of Niagara occasionally had their Fox connection time out
when doing a copy/duplicate of a very large data set. The operation would
complete successfully, but the user was forced to log back into their station.
The fox transfer protocol has been enhanced to prevent these time outs and to
also provide users with progress feedback which is displayed on the "Please
Wait" dialog. Workbench will continue to use the old protocol with stations
running 3.2.4 and older to provide backward compatibility.

*** 15.1:7551  Memory leak in NiagaraNetwork ping caused station failure in QNX-based JACE ***
  Record Type:  Bug
  Resolved In:  3.0.99; 3.1.2
Prior to build 3.0.99, if a station running in any QNX-based JACE (JACE-2, -4, 
-5 series) had a remote NiagaraStation under its NiagaraNetwork with invalid 
credentials, a memory leak occured from the monitor ping of the remote station.
Forcing garbage collection did not help.  If left in this state, the station 
eventually failed.  This issue does not affect stations running on Win32 hosts.

This issue was fixed in build 3.0.99, and in 3.1.2. As a workaround, for any
station in a QNX-based JACE using an earlier software build, under its 
NiagaraNetwork remove or disable any NiagaraStation that does not have valid 
credentials.

*** 15.1:8038  Reconnect before disconnect could cause orphaned Fox connection ***
  Record Type:  Bug
  Resolved In:  3.1.7; 3.0.101
It was possible in certain network situations that a client side Fox connection
could disconnect and reconnect before the server side had timed out.  The result
was an orphaned Fox session which could cause proxy points to stop updating
until a manual disconnect was performed on the client side. Starting in builds
3.1.7 and 3.0.101, the fix for this problem is to perform an automatic disconnect
when this situation is detected - the lastDisconnectCause will be "Reconnect 
while server still connected".

*** 15.1:9025  Public API to open FoxSessions station-to-station ***
  Record Type:  Enhancement
  Resolved In:  3.2.6
Several AX developers have built applications which require a full proxy
session to a remote VM be opened within a Supervisor station.  This was
possible with the existing 3.0 public APIs, but was obtuse, undocumented,
and didn't support sharing of the connection.  In 3.2 there is a new
fox:javax.baja.fox.BFoxProxySession API which provides a clean public API
for opening proxy component sessions to a remote station.  This new API
exposes the engage/disengage methods used by NiagaraNetwork peer connections
which allow referenced counted shared connections.  See the BFoxProxySession
bajadoc (especially the class header) for all the gory details.

*** 15.1:9072  Do not open port until station fully started ***
  Record Type:  Bug
  Resolved In:  3.2.4
In previous versions the fox port was opened as the station was starting
which allowed incoming fox connections to be setup before the station had 
fully started.  In 3.2 the fox port is not opened until the station has fully
started (using the new BComponent.stationStarted() callback).


*** 15.1:9159  FoxSession could loop with NullPointerExceptions on heavily-loaded network ***
  Record Type:  Bug
  Resolved In:  3.1.29; 3.2.3
A fix was made to an issue that could occasionally occur on a heavily-loaded
network, where a FoxSession would enter an infinite loop, spewing 
NullPointerExceptions to standard output.

*** 15.1:9172  Add username to fox session logging ***
  Record Type:  Enhancement
  Resolved In:  3.2.5
Fox log messages now include the username when logging connections
from Workbench.  

Sessions from the workbench use the log format:
  "Workbench [<username>] @ <hostname>"
  
Sessions from stations use the log format:
  "Station [<stationnae>] @ <hostname>"
  
Or the more general format is:
  "<event> <localId> <dir> <remoteId> :: <app> [<user>] @ <host>"  
  Opened: 2 <- 9 :: Workbench [admin] @ somehost

*** 15.1:9571  ServerConnections don't cleanup rejected sessions ***
  Record Type:  Bug
  Resolved In:  3.2.10
The fix for 8038 had the side effect that Workbench connections which were rejected by a station
were orphaned in the FoxService/ServerConnections list.  Since most Workbench connections first
try their existing null credentials, this would create one orphaned ServerConnection per login
attempt.  These orphaned connections shouldn't cause any real problem, but are a nuisance if you
are trying to figure out who is logged on.  This issue resolves the problem such that all server
connections should correctly be cleaned up however the session disconnects.

#########################################################################
16  gx
#########################################################################

=========================================================================
16.1  Fixed
=========================================================================

*** 16.1:7229  Line with gradient stroke becomes invisible if oriented same as gradient angle ***
  Record Type:  Bug
  Resolved In:  3.1.4
The Line shape found in the bajaui palette (Shape folder, Line) has a Stroke
property with a Gradient option (default option is Solid). Previously, in 3.0
systems, if Stroke was set to Gradient, and the line's orientation was the same
as the "Angle" in the Gradient Editor, the line became invisible. Thus, a 
horizontal line became invisible when its gradient angle was 90; a vertical line
became invisible when the gradient angle was 0.

Beginning in 3.1.4, AwtLinearGradient now internally handles verifing that
startpoint != endpoint, so this problem will not occur.

As a workaround in 3.0, set the gradient Angle to any other value, even if just 
+/- 0.1 from 0 or 90 degrees. Adding or subtracting 0.1 from a 0 or 90 degree
angle does not affect the visual presentation of the line in the Px view.

#########################################################################
17  history
#########################################################################

=========================================================================
17.1  Fixed
=========================================================================

*** 17.1:6380  Chart builder shows Dec 1969 on time axis ***
  Record Type:  Bug
  Resolved In:  3.1.29
Prior to this fix, the bounds for the time axis on a chart
were auto-calculated based on the values in the data set.
If the data set was empty, the bounds could not be calculated
and the default behavior displayed an axis with a start time
from 1969 (Java's epoch).

With this fix, the time axis now displays the query time range
instead of trying to auto-calculate the range.


*** 17.1:6706  Added delta logging ability for numeric histories ***
  Record Type:  Enhancement
  Resolved In:  3.0.81
Delta Logging Enhancement:  The history module has been enhanced to support 
querying a numeric history for delta values.  The delta values are computed 
by taking the difference between one numeric record and the next (the latter's 
timestamp is used for the delta value).  This is a useful feature when logging
such data as electric consumption that might use a running total, but the 
consumption from timestamp to timestamp is actually the delta value.

You can still collect the history as normal, and then use the "delta=true" flag
in the history query to request the delta collection for the history.  If you
know the rollover values for a point being logged as a running total, you
can use the two new properties in the History Config to specify the behavior
of the delta logging when the rollover occurs (the user can specify the
minimum and maximum value, or null if it is unspecified).  These two new
properties in the History Config are called 'Min Rollover Value' and 'Max
Rollover Value' respectively.

The History Chart and History Table views for a history now include a "Delta"
checkbox to enable/disable the display of delta values.  

*** 17.1:6715  Need to record when a station starts ***
  Record Type:  Enhancement
  Resolved In:  3.0.82
The LogHistoryService now defaults severity to 'message' rather than 'error'. 
Many useful things are logged such as station started at the 'message' severity.

*** 17.1:6768  Numeric records should support both 32-bit and 64-bit storage ***
  Record Type:  Enhancement
  Resolved In:  3.0.83
The Numeric COV and Numeric Interval History Extensions now have a property called
'Precision' which allows a user to select the numeric precision to use when storing
the log values persistently.  The default is 32-bit precision (single precision)
which is equivalent to the precision of a float type in Java.  The other option
is 64-bit precision (double precision) which is equivalent to the precision of
a double type in Java.  64-bit precision allows for a larger range of valid decimal
numbers, however it takes more storage space in persistent memory.  Thus it should
only be used when needed (i.e. in cases where you have extremely large or small
values, with lots of decimal places).

*** 17.1:6777  History files corrupted by large history config ***
  Record Type:  Bug
  Resolved In:  3.0.83
In rare cases (most likely in a station saved in build 3.0.82 prior to using
the history-3.0.82.1 patch), it was possible to corrupt a history file if
the history configuration settings were complex enough to cause the
perisistent storage for it to exceed its bounds.  This problem has been fixed
so that the bounds for storage are resized if the history configuration
settings require it.  Symptoms of this problem include exceptions similar
to the following:

javax.baja.history.HistoryException 
        at com.tridium.history.db.BLocalHistoryDatabase.getTable(BLocalHistoryDatabase.java:815)
        at com.tridium.history.db.BLocalDbHistory.getTable(BLocalDbHistory.java:458)
        at com.tridium.history.db.BLocalDbHistory.getConfig(BLocalDbHistory.java:106)
        at com.tridium.history.db.BLocalDbHistory.getRecordType(BLocalDbHistory.java:97)
        at com.tridium.history.fox.BHistoryChannel.getHistory(BHistoryChannel.java:502)
        at com.tridium.history.fox.BHistoryChannel.process(BHistoryChannel.java:109)   
        at com.tridium.fox.sys.BFoxConnection.process(BFoxConnection.java:317)
        at com.tridium.fox.session.SessionDispatcher.dispatch(SessionDispatcher.java:68)
        at com.tridium.fox.session.SessionDispatcher.run(SessionDispatcher.java:47)
Caused by: java.io.IOException: File format version is not supported by this release. The maximum version supported by t
his release is 1 but the format version for this file is 2048.
        at com.tridium.history.file.BFileHistoryTable.createFromFile(BFileHistoryTable.java:160)
        at com.tridium.history.db.BLocalHistoryDatabase.getTable(BLocalHistoryDatabase.java:806)
        ... 8 more



*** 17.1:7265  History database could cause station deadlock ***
  Record Type:  Bug
  Resolved In:  3.0.92
In rare situations (only for a station with a large number of histories), there
was a potential for a station watchdog timeout to occur caused by an
excessive amount of time needed to close unused histories.  Histories that
have not been used for a particular amount of time are closed during a periodic
history cleanup cycle.  In the special case where there were a large number of
histories to process, this task was tying up the station's control engine
thread for enough time to cause a watchdog timeout.

In build 3.0.92, this bug was fixed such that the periodic history cleanup 
process (CloseUnusedHistories action) is now performed on a separate thread to 
keep the control engine thread free.

*** 17.1:7381  History Chart incorrectly applied timezone offset ***
  Record Type:  Bug
  Resolved In:  3.0.93
There was a timezone offset bug in the History Chart view.  Users would only
notice the problem if the histories in view were collected using a different 
timezone than the timezone of the Workbench client used to view the History 
Chart.  For example, a JACE collects a history using one timezone and exports 
it to a Supervisor, which is using a different timezone.  The result of such a 
situation would be that the chart would display the history data using the 
timezone of the Workbench client (Supervisor), and not the correct timezone of 
the collected data (JACE timezone).  So the charted data would appear offset 
by the timezone hour difference.

This bug was fixed in 3.0.93, so that the History Chart view will always display
the history's data using its collected timezone.

*** 17.1:7489  Delta toggle retained zooming control ***
  Record Type:  Bug
  Resolved In:  3.0.95
There was a minor bug in the history chart view.  While viewing a history
chart and using the zooming feature, a zoom control appears in the upper
right corner of the chart.  This object controls zooming in and panning 
up/down/left/right.  When you zoom out completely (full chart view), this
zoom control should disappear.  The bug occurred when you were zoomed in
on a chart, and then you changed the time range or toggled the 'delta' button.
These actions cause the chart to be rebuilt (and zoomed out completely to the
full chart view), but the zoom control would not disappear.  In build 3.0.95
this was fixed, so that the zoom control will now disappear when the history 
chart is rebuilt.

*** 17.1:7575  Export to CSV encoded numeric value together with units ***
  Record Type:  Bug
  Resolved In:  3.0.96
In table views that use the CollectionTableModel, the CSV export feature
was exporting values encoded together with their units.  This caused
problems for applications that consume CSV data.  By including the units
with the value, the string representation of the value could not be
converted back to a numeric.  This is important for applications like
charting.

Views affected by this change include the History Table view and the
Collection Table view.  The Collection Table is typically used to
display BQL query results.

Starting in build 3.0.96, these views still display the units in table cells,
but when exported to CSV the units are removed.

*** 17.1:7676  Exported History Collections use client time zone. ***
  Record Type:  Bug
  Resolved In:  3.0.100; 3.1.2
Prior to this build 3.0.100 fix, if you tried to export a history table that 
was collected using a different timezone than the timezone used by your 
Workbench session (client), then the exported history table would use the 
Workbench timezone instead of the history's collection timezone.  

For example, if you were using Workbench in EST, and you were viewing a history
table collected in CST, if you exported the history table (export table to 
PDF/text/CSV), then the timestamps of the exported table would use EST instead 
of CST.  This bug was fixed in 3.0.100, such that the exported history table 
will use the collection time zone (in this example scenario, CST).

As a side effect of this fix, when you export a history table to CSV (and CSV 
only), the "Trend Flags" and "Status" column values are now converted to their
numeric representations (instead of their String representations as they were
previously).  This is more appropriate for use in CSV format.  Tables exported 
to PDF and text will still behave as before (String representations for these 
columns).

*** 17.1:7746  HistoryChartBuilder is not embeddable in a Px view. ***
  Record Type:  Bug
  Resolved In:  3.1.25; 3.2.1
(original release note)
The HistoryChartBuilder will now work when embedded in a px page.  When you
hit "Build", however, you will still be hyperlinked to a new page (not
embedded in the px page), displaying the freshly minted chart.
The HistoryChartBuilder will now work when embedded in a Px view.  Formerly, 
the view displayed correctly, but could produce an exception when you pressed
the "Build" button.

Note that results from the HistoryChartBuilder are not fully embedded in the
same Px view.  In other words, when the "Build" button is pressed, the results
display in a new view.  However, pressing the Back button will go back to the 
Px view with the builder in it.

*** 17.1:8143  Incorrect values in tooltip popup of chart with multiple units ***
  Record Type:  Bug
  Resolved In:  3.1.28; 3.2.2
When charting multiple histories that have different units, values
displayed in the "tooltip" popup (when hovering mouse over chart) 
did not display the correct values for each history. This was fixed.

*** 17.1:8145  Incorrect enum values in tooltip popup of chart of enum history ***
  Record Type:  Bug
  Resolved In:  3.2.11; 3.1.31
A history chart for a history with enumerated values would not always
show the correct enum value in the "tooltip" popup (when hovering mouse
over chart), for example, only the lowest or highest enumeration.  This
was fixed.

*** 17.1:8318  History charts should show correct time range if no data is found ***
  Record Type:  Enhancement
  Resolved In:  3.3.8
Charts that display not data now correctly display the time range
selected (instead of 31-Dec-69).

*** 17.1:8397  Chart data export after using History Chart Builder ***
  Record Type:  Enhancement
  Resolved In:  3.2.4
From within any History Chart view, there is now a right-click Export feature
that provides similar functionality as the export feature from table-based
views.  For example, the Export dialog allows you to select Table to PDF, 
Table to Text, or Table to CSV, and you can view internally or in an external
application, or save to file.  This feature may be especially useful after
building a chart using the History Chart Builder. 

*** 17.1:8593  NaN value causing NumericCov history ext to not collect ***
  Record Type:  Bug
  Resolved In:  3.0.102; 3.1.21
It was discovered that the numeric change of value (COV) history extension could
fail to start collecting if a NaN (not a number) value was encountered at startup.
A check for this rare condition has now been added so that this problem is fixed.

*** 17.1:8631  New history relative ord scheme for AxSupervisor ***
  Record Type:  Enhancement
  Resolved In:  3.0.102; 3.1.24; 3.2.1
A special history id syntax was required to provide a mechanism for graphics which
are portable between JACE folders on an AxSupervisor.  For example, given a
network with two JACE stations, "Foo" and "Bar":

  NiagaraNetwork
    Foo
      Graphic
    Bar
      Graphic
      
In the situation above, lets say you want the Graphic to be able to access the OAT 
history for the respective Niagara stations, as follows:

  /NiagaraNetwork/Foo/Graphic -> history:/Foo/OAT
  /NiagaraNetwork/Bar/Graphic -> history:/Bar/OAT
  
In order to accomplish this and allow the Graphic to be portable, a new syntax was
added to the History Ord scheme which checks for a '@' character in the History Id.
Using the same example as above, the history Ids within the graphics would be 
reformatted as follows:

  /Foo/OAT -> @OAT
  /Bar/OAT -> @OAT

The new History Ord scheme will detect the starting '@' character and use the parent
Niagara Station instance to resolve the history.

*** 17.1:9091  Incorrect check for changes caused excessive history config rewrites ***
  Record Type:  Bug
  Resolved In:  3.2.2; 3.1.28; 3.0.104
Prior to this change, history configuration changes were not
being detected correctly.  The result was a false positive
which would cause the history configuration to be rewritten
much more frequently than necessary.

This only affects Niagara versions and histories where the
HistoryConfig includes the minRolloverValue and maxRolloverValue
properties.

With this fix, a configuration change is only detected when
a change has actually occurred.

*** 17.1:9179  Duplicate/Out of order timestamped records possible on system clock change ***
  Record Type:  Bug
  Resolved In:  3.2.10
Histories in Niagara should always have records appended in ascending 
timestamp order.  Out-of-order or duplicate timestamped records can cause
faulty, erratic behavior.  A common way for this condition to occur is
when there is a backwards system clock change (even a slight backwards
change due to a time synchronization can sometimes lead to this).

For example, if you have an interval history extension collecting values
every 15 minutes, a backwards system clock change could lead to duplicate
timestamped records (perhaps off by just a few milliseconds).  The diagram
below shows how this can happen.

Suppose a 15 minute interval collection, starting on the hour:


...11:30-------11:45-------12:00-------12:15-------12:30...
                        ^          ^
                        |          |
                        |__________|
                     
(backwards system clock change causes the 12:00 record to be recorded twice)


This problem is now prevented by the code.  When an attempt is made to append
a record to a history, its timestamp is checked and verified against the
last timestamped record added to the history.  If the record is determined
to be out-of-order (or a duplicate), it is not appended to the history, and
the history extension will go into a fault status until the next successful
append occurs (ie. enough time expires for the system clock to "catch up" to
the last timestamp appended to the history).

*** 17.1:9309  Tools/Options/Unit Conversion in Workbench not working correctly in history table/chart ***
  Record Type:  Bug
  Resolved In:  3.2.14
It was discovered that the presentation of histories in Niagara wasn't using
the appropriate unit conversion settings.  
For example, if a Workbench user set the Tools -> Options -> Unit Conversion
property to something other than the default (none), then any historical data
viewed in Workbench should follow this unit conversion rule.  However, prior
to this fix, the history chart view, history table view, history collection
table view, and history editor view were always using the collected units for 
the history and not converting the values to the appropriate units.  Also, if
you attempted to export any of the history data from these views, the exported
data would also not be converted appropriately.

This issue has now been fixed, so that the affected history views (as well as
exporting) now correctly convert to the appropriate units defined by the
Unit Conversion property.  Please remember that the Tools -> Options ->
Unit Conversion property is used when connected via Workbench, no matter which
user you used when you connected to a station.  Individual user Unit Conversion 
settings are used when connected via a browser.

*** 17.1:9597  anyone can do history db maintenance ***
  Record Type:  Bug
  Resolved In:  3.2.10
The fox history space was not correctly transferring permissions from the station.
Access to the history database is now determined by the permissions for the user
on the history service.


*** 17.1:10802  Inconsistent results when editing String histories ***
  Record Type:  Bug
  Resolved In:  3.3.10
There was a bug when updating records in histories with variable record sizes
(such as String histories).  Only the first and last section of the history
could be modified.  This was due to a flushing problem where only the first
and last pages of the history's records were getting written, even after
records on pages in between had been modified from their original values.
This bug has now been fixed, so that modified (dirty) pages of records are also
cached and written when a history is flushed.

=========================================================================
17.2  Open
=========================================================================

*** 17.2:6242  Drag and Drop not working in Database Maintenance history view ***
  Record Type:  Bug
  Resolved In:  
Currently, the drag and drop feature is not supported in the "Database
Maintenance" History view.  You must use the arrow buttons to make the
history selections desired.  Operations are performed only on the selected
histories located in the list on the right.

*** 17.2:6806  Enter Key not saving for numerous fields in history extension ***
  Record Type:  Bug
  Resolved In:  
There are a few known properties in a History Extension that, when changed
by the user, require clicking the "Save" button in the property sheet view
in order to apply the changes.  Unlike other properties where you can simply
hit the Enter key to submit a change, a few properties have special editors
which don't allow for the Enter key to act as a key binding for submitting
the change(s).  The following History Extension properties are known to
exhibit this behavior:

Active Period
History Name
Capacity
Min Rollover Value
Max Rollover Value

*** 17.2:6915  Disconnect when disabling/enabling too many histories ***
  Record Type:  Bug
  Resolved In:  
There is a known history creation bug that can occur under rare circumstances 
(although it is not always repeatable even under the same conditions).  
Basically, if you have a large number of histories being collected in a 
station (i.e. 500+ histories collecting at the same interval), if all of
the histories are first created at the same time, it can cause an
extreme workload for the station's control engine thread and occasionally 
lead to a station watchdog timeout.  This only occurs when the histories
are first created (meaning the first time they are enabled and/or the first
appended record for an empty, non-existent history).

To workaround this problem, avoid creating large numbers of histories at once, 
and instead space out their creation.  For example, if you have 1000 interval 
history extensions collecting on the same interval, avoid deleting all of the
histories (using the Database Manager view) while the extensions are still 
active.  If the extensions are still active when the histories are deleted, 
then the next record append that occurs on the interval will cause all of the 
histories to require a creation.  This can lead to an extreme cycle workload for the 
control engine thread, which can sometimes be enough to trigger a station 
watchdog timeout.  In such a case as this example, delete a few histories
at a time and allow enough time for the creation process to be spaced out.



#########################################################################
18  historyFunc
#########################################################################

=========================================================================
18.1  Fixed
=========================================================================

*** 18.1:7510  History Rollup (oBIX implementation) ***
  Record Type:  Function
  Resolved In:  3.0.95
The historyFunc module was added to provide some functions that are commonly
performed on collections of data (histories).  History rollups are one such
feature.  The history rollup implemented follows the oBIX standard.  The 
oBIX definition of a history rollup requires that given a history of numeric 
records, a start and end query time for the history, and a rollup interval 
(relative time), the result should contain history rollup records spaced 
evenly at the specified rollup interval.  Each history rollup record contains 
the minimum, maximum, average, and sum of the numeric history records that 
were used to form the history rollup record.  The history rollup record 
should also indicate the start (exclusive) and end (inclusive) times that 
were used for the rollup.  These start and end times are relative to the 
overall query start time and the rollup interval.

You can use a BQL query to accomplish a history rollup.  The query follows the
pattern of the example below:

  bql:historyFunc:HistoryRollup.rollup(<BITable>, <BRelTime>)

      <BITable> is the numeric history in table form (can use 
      another BQL query to form this table, allowing you to 
      specify start/end times)
      
      <BRelTime> is the rollup interval
         
Example:

  history:|bql:historyFunc:HistoryRollup.rollup((select * from /demo/MyHistory), baja:RelTime '1800000')
  
The example above will rollup the history /demo/MyHistory to an interval 
of 30 minutes.  Since no start and end times are declared in the BQL query 
(select * from /demo/MyHistory), by default the absolute start and end 
times of the history will be used.

The result of the history rollup query is a table (BITable) of history rollup
records.  

*** 18.1:7718  Add "Count" to history rollup record ***
  Record Type:  Enhancement
  Resolved In:  3.1.2; 3.0.100
In order to conform with the oBIX specification for history rollup records, a
record "Count" field was added.  It is simply the number of records used to
compute the history rollup record.

*** 18.1:7719  History Rollup records use Workbench (client) timezone ***
  Record Type:  Bug
  Resolved In:  3.0.100; 3.1.2
Previously, when a history rollup was performed on a history that was collected
using a different timezone that the timezone of the Workbench session (the 
client), then the resulting history rollup records would incorrectly use the 
client's timezone rather than the timezone of the original collected history.
This has been fixed now, so that the timezone of the original collected
history will persist in the history rollup.

#########################################################################
19  html
#########################################################################

=========================================================================
19.1  Fixed
=========================================================================

*** 19.1:8273  Pipe character "|" incorrectly displayed in Help docs ***
  Record Type:  Bug
  Resolved In:  3.1.14
In HTML files like the NiagaraAX Help docs, the pipe character '|' was displayed
as "&#9474;".  This was fixed in 3.1.14.

*** 19.1:8356  Convert HtmlTokenizer.java to UTF-8 ***
  Record Type:  Enhancement
  Resolved In:  3.1.15
Some HTML character entities were not being displayed properly. This was
fixed by converting non UTF-8 characters to UTF-8.

#########################################################################
20  hx
#########################################################################

=========================================================================
20.1  Open
=========================================================================

*** 20.1:6292  Image background not visible to Hx users ***
  Record Type:  Bug
  Resolved In:  
This problem occurs with Hx access to a Px view engineered with image brushes.
As a workaround, do not use image brushes if a view will be accessed by 
Hx users.

*** 20.1:6349  MSIE cannot animate 24-bit PNG's ***
  Record Type:  Bug
  Resolved In:  
This problem can occur with Hx station access using Microsoft IE browser. 
Unlike Firefox, IE cannot display the full alpha channel for PNG type images.
So currently, you cannot animate 24-bit alpha PNGs in MSIE. Supposedly, IE7
(when available) will correct this.

*** 20.1:6367  Some kitPx module objects do not render in Hx ***
  Record Type:  Bug
  Resolved In:  
These widgets from the kitPx palette are not rendered in Hx:

  analog meter
  bargraph (mildly supported)
  setpoint slider
  setpoint toggle button
  setpoint checkbox 
  increment setpoint button
  decrement setpoint button


=========================================================================
20.2  Fixed
=========================================================================

*** 20.2:6539  BoundLabel mouse rollover effect not supported in Hx ***
  Record Type:  Bug
  Resolved In:  3.2.10
Beginning in build 3.2.16, Hx BoundLabels now support a blue border highlight
when its mouse over property is set to 'Outline'.

*** 20.2:6982  Hx did not recognize lexicons when displaying dialog controls ***
  Record Type:  Bug
  Resolved In:  3.0.91
Hx contained non-localized text strings that ignored lexicon settings.
Examples included buttons such "New", "Edit", "OK", "Cancel", "Add", and
"Delete" (among others) that appeared in various dialogs.  In 3.0.91,
this was fixed such that the majority of these now localize correctly.

*** 20.2:7228  Bound Label status colors did not update in HX / Firefox until refresh ***
  Record Type:  Bug
  Resolved In:  3.0.92
If a Bound Label with status colors enabled (Status Effect = Color) on a
Px page was viewed in Hx and Firefox, a status flag color change could occur
but not be reflected in the browser (the value change showed, but not color).
A manual Firefox page refresh was needed to see the updated status color.

This was fixed starting in build 3.0.92.  This problem did/does not occur when
viewing Hx using IE (Internet Explorer).

*** 20.2:8099  Hx unable to load History Chart ***
  Record Type:  Bug
  Resolved In:  3.1.10
Hx charting does not support user-defined time ranges yet.  Previously, an Hx
media Px page would produce an error when viewed in a browser, if it contained
a chart with a user-defined time range.  This was fixed in build 3.1.10.  Now,
if a history chart is set to a "timeRange", when it displays in Hx, it will be
defaulted to the "today" range.

*** 20.2:8116  Enhanced Hx to support basic charting ***
  Record Type:  Enhancement
  Resolved In:  3.2.12
Basic support for charting was added in Hx, using SVG to render the chart. 
This is natively supported in Mozilla Firefox 1.5+, but requires the 
Adobe SVG plugin for Internet Explorer.

Also added was an HxHistoryChartBuilder that mimics the functionally
in the Workbench version.  Hx should be able to render all chart types
and rollups that are available in the Workbench version.

Note that charts in Hx currently have some limitations--their size is usually
hard-coded to 800x400 pixels, and they can not be panned, or zoomed in or out.

*** 20.2:8146  Hx History Chart Builder did not filter out string histories ***
  Record Type:  Bug
  Resolved In:  3.1.14
The Hx History Chart Builder was fixed in 3.1.14 to filter out
history types using string data (which produced mixed results). In
this way, it is now consistent with the History Chart Builder in 
Web Workbench. Examples of histories no longer seen in the Hx Chart
Builder are a station's AuditHistory and LogHistory.

*** 20.2:8178  HX Chart should work with component reference ***
  Record Type:  Bug
  Resolved In:  3.1.12
HxHistoryChart previously only supported being a view on a BIHistory. This
has been updated to also allow views on the HistoryExt of a component, which
is consistent with Workbench charting.  Being a view on a HistoryExt allows
charts to be used with relative ords, and resuse of Px pages.


*** 20.2:8244  Hx unable to open file using apostrophe in file name ***
  Record Type:  Bug
  Resolved In:  3.1.15
In the directory browser (http://<host>/ord?file:^), Hx would list files that 
used an apostrophe in their file name (for example, "te'st.txt"), but it would
not open them.  An HTTP 404 error was returned instead.  Hx was fixed to open 
files named using an apostrophe.

*** 20.2:8246  Unable to add events to a CalendarSchedule in Hx ***
  Record Type:  Bug
  Resolved In:  3.1.14
In Hx access, clicking in a CalendarSchedule could produce an "NS_ERROR_ILLEGAL_VALUE"
error and exception, preventing the addition of events.  It was found the latest
version of Firefox was stricter on XML HTTP Request header formatting.  This was
fixed in Hx starting in build 3.1.14

*** 20.2:8266  Some constant colors in widgets did not render in Hx ***
  Record Type:  Bug
  Resolved In:  3.1.14
Some colors used in PxPages would not show up correctly when using Hx, because
of a processing bug when converting them to HTML. Examples include aquamarine
and blueViolet.  This was resolved in 3.1.14. All colors chosen should display
correctly in Hx - minus the alpha channel which is not supported in HTML.


*** 20.2:8343  Buttons perform action events when disabled ***
  Record Type:  Bug
  Resolved In:  3.2.5
If a button on a Px page contained an action binding, and the button was 
disabled, the action was still performed if clicked in Hx.  The Hx version
has be fixed to also be disabled.

*** 20.2:8368  Directory List in Hx would show spaces as "&nbsp;" ***
  Record Type:  Bug
  Resolved In:  3.1.16
Hx contained a formatting bug in Directory List ("http://<host>/ord?file:")
where folders and file names with spaces appeared with "n&nbsp;" instead
of a space.  For example, "Sys&nbsp;Home" instead of "Sys Home".  This
was fixed so that spaces appear correctly.

*** 20.2:8778  Hx scheduler assiged events on the wrong day in some locales ***
  Record Type:  Bug
  Resolved In:  3.0.102; 3.1.24; 3.2.1
The Hx Scheduler did not correctly handle non-Us weekday orders, which
could result in events being added on the wrong day.  For example, with
the locale set to Finland (FI), where the first day of the week is Monday
and not Sunday, after adding an event to Sunday, it would appear in Monday.
The Hx Scheduler was fixed to always respect the locale's weekday ordering.

*** 20.2:10953  New line character does not convert to Hx ***
  Record Type:  Enhancement
  Resolved In:  3.3.16
Line break characters within a label are now correctly handled in hx.
Previously they were encoded to '&#a;'. They now cause a line break to appear
within the label text.

#########################################################################
21  niagaraDriver
#########################################################################

=========================================================================
21.1  Fixed
=========================================================================

*** 21.1:7601  NiagaraNetwork should not allow station child named identically as the running station ***
  Record Type:  Enhancement
  Resolved In:  3.1.6
Previously, the NiagaraNetwork allowed you to create a child NiagaraStation
named the same as its (own) running station.  Now, such a configuration will
give the NiagaraStation component a fault status, with a Fault Cause string of
"Station name is same as this station."  This was fixed in build 3.1.6.

NOTE: Stations in any Niagara network should always be uniquely named,
otherwise problems with items like histories are likely to occur.

*** 21.1:8005  Hide unused 'Retry Interval' property on NiagaraHistoryDeviceExt ***
  Record Type:  Bug
  Resolved In:  3.1.7
The Niagara History Device Ext (component "Histories" under a NiagaraStation) 
has an unused property called "Retry Interval".  This property is not used, as
it was replaced long ago by the behavior of the frozen "Retry Trigger" slot. 
Starting in build 3.1.7, the "Retry Interval" property has been hidden by 
default, so that it will not add confusion to the user.

*** 21.1:8970  Users with operator-level access unable to issue operator actions to Niagara proxy points ***
  Record Type:  Bug
  Resolved In:  3.0.103; 3.1.25; 3.2.1
When using operator only security permissions on Niagara proxy points, users were unable to invoke
operator actions.  This was caused by an invalid default in the hidden action NiagaraProxyExt uses to
query the default value.  This action now correctly defaults to operator level, so that operator actions
function correctly in Niagara proxy points.

#########################################################################
22  pdf
#########################################################################

=========================================================================
22.1  Fixed
=========================================================================

*** 22.1:779  Added the ability to email a .pdf report on a timed basis ***
  Record Type:  Enhancement
  Resolved In:  3.2.3
The new ReportService can now generate and email report .pdfs on
a timed or scheduled basis.  See the developer documentation for
more details about the ReportService.

*** 22.1:5227  Support for common header/footers in report PDFs ***
  Record Type:  Enhancement
  Resolved In:  3.2.2
Support for common headers and footers in report PDFs was added with the
new ReportPane.  The ReportPane allows its contents to span multiple pages,
and allows each page to have a common logo as well as a page number and
timestamp.

*** 22.1:7074  Export:Save to File allowed overwrite without warning dialog ***
  Record Type:  Bug
  Resolved In:  3.0.92
The Export dialog, such as launched from the table options menu in any manager
view, handled saving files poorly - allowing a user to inadvertently overwrite
an existing file.  Starting in 3.0.92, the Export dialog now correcly checks 
the existence of a file before exporting, and prompts the user to confirm the 
overwrite or cancel the operation.

Also, note that if the default extension for the requested exporter was not 
already appended to the entered filename (i.e .pdf, .txt, .csv), it will 
be automatically added before the file is checked for existence.

*** 22.1:7432  Cannot print PDF from JACE ***
  Record Type:  Bug
  Resolved In:  3.0.94
Printing from JACEs failed due to lack of a geometery implementation in the 
micro gx environment.  Starting in build 3.0.94, a rectangle-only implementation
was added, and JACEs should now be able to correctly render PDF documents.

*** 22.1:8317  PDF rendered non-ASCII characters incorrectly ***
  Record Type:  Bug
  Resolved In:  3.1.15
PDF documents previously failed to render non-ASCII (international) characters 
correctly. This occured due to a mismatch between the Java string encoding and 
the string encoding used by the PDF writer (ISO-8859-1).  This was fixed to 
correctly convert the encoding and display non-ASCII characters correctly.

#########################################################################
23  platform
#########################################################################

=========================================================================
23.1  Fixed
=========================================================================

*** 23.1:6952  Station auto-save frequency display units inconsistent between property sheet and plugin ***
  Record Type:  Enhancement
  Resolved In:  3.1.1
The PlatformServices plugin (view) and the property sheet for PlatformServices
displayed the units for the "Station Auto Save Frequency" inconsistently.  It
displayed in hours in the plugin view, and hours-minutes-seconds in the property
sheet. Starting in 3.1.1, the slot facets for the property were changed, and
this value now displays in hours-minutes in both places.

Note that nothing functioned incorrectly as a result of this inconsistency, so 
the change is purely cosmetic.  No workaround is needed for 3.0 systems.

*** 23.1:6990  Backup cannot be restored to an unbranded machine ***
  Record Type:  Bug
  Resolved In:  3.0.88
Backup files created from licensed jaces are prevented from being restored
to empty, unlicensed machines because the "brand" check is incorrect.

To work around this problem, the file transfer client or API can be used to
copy a !licenses/Tridium.license file from another machine before attempting
to restore the backup.

Also, backup files created from jace NX devices are prevented from being 
restored to jaces that don't yet have the sun-jre-win-x86.dist installed. 

To work around that problem, use the Distribution Installer or Software Manager
to install sun-jre-win-x86 before attempting to restore the backup.



*** 23.1:7064  Large file transfers take very long time to complete ***
  Record Type:  Bug
  Resolved In:  3.0.90
After a file transfer to a remote platform, platform code sent a lot of nav 
events to Workbench about the files that were added and removed. This section 
of code was responsible for many redundant network requests for "config" files.
This caused extremely long (several minute) delays in the file transfer code 
after big file transfers.  This issue was fixed starting in build 3.0.90. 

*** 23.1:7077  PlatformDaemon.make() should always throw AuthenticationException if invalid credentials ***
  Record Type:  Bug
  Resolved In:  3.0.90
This problem affects only programmers who use the javax.baja.platform API
to build Niagara-based tools.

After platform daemon credentials were changed, it was possible to invoke
PlatformDaemon.make() using the old credentials without any errors.   An
exception was eventually thrown the next time a network request was sent to
the platform daemon, but that made the cause of the problem harder to deal
with.

This issue was fixed starting in build 3.0.90.      

As a workaround for programmers using an earlier build, they should follow 
calls to PlatformDaemon.make() with a call that causes a network request to
the platform daemon, for example:

  PlatformDaemon daemon = PlatformDaemon.make(host, port, user, password);
  daemon.getStationManager().getAllStations();   // exception will be 
                                      // thrown if user/password are invalid


*** 23.1:7236  Edit in PlatformService, TcpIpService causes ActionInvokeException in QNX JACE ***
  Record Type:  Bug
  Resolved In:  3.0.92
When accessing a station running on a QNX-based JACE, and saving a TCP/IP 
configuration change under its PlatformServices, a prompt appears to confirm 
the reboot of that host.  Upon confirmation, the TCP/IP change takes place, 
and the JACE reboots, but an "ActionInvokeException" error message appears.

This was fixed in build 3.0.92, where instead you now see "Save successful. The
system is now being rebooted."  The error message from 3.0.91 and earlier can 
be safely ignored, since the problem is only cosmetic.

*** 23.1:7307  Station's PlatformServices missing after multiple dist file installs in empty JACE ***
  Record Type:  Bug
  Resolved In:  3.0.92
Note: A station's Platform Services are sourced from a platform.bog file. 

This problem happens when multiple dist files are installed at the same time,
which is typical when restoring a backup dist file to a blank JACE. The problem 
was that the Installer was providing a "default" platform.bog for dist 
files that don't have changes for the platform (core, vm, os dists), and that when 
several dists are installed in a single action, the last platform.bog version "wins."  
So, if nre-config-{model}.dist provides a correctly populated platform.bog, but 
nre-core-qnx-ppc.dist, ibm-j9-qnx-ppc.dist, and qnx-jace-{chipset}.dist all provide
empty platform bogs, the correct one in the config dist file became overwritten.

This behavior was used before the dist files were "split," to ensure that when a
station starts that a platform.bog file exists. However, it is now inappropriate,
causing this problem.  Starting in build 3.0.92, the Distribution File Installer
was fixed to not overwrite the correct platform.bog file (in the config dist file).

If using a pre-3.0.92 build of NiagaraAX, you can work around this bug by installing
specific dist files to empty JACEs *before* installing a backup dist file (or an
nre-config-<model> file, or before using the Commissioning Wizard), as follows:

 - If an empty QNX JACE:
    - nre-core-qnx-ppc.dist
    - ibm-j9-qnx-ppc.dist
    - qnx-jace-james.dist  or qnx-jace-york.dist
 
 - If an empty JACE-NX:
    - nre-core-win-x86.dist
    - sun-jre-win-x86.dist
        

*** 23.1:7387  Hx edit of PlatformService TCP/IP settings does not accept blank DNS domain ***
  Record Type:  Bug
  Resolved In:  3.1.1
If an HX user uses a web browser to change settings on the TCP/IP Platform
Service for a station running 3.0 software, edits prevent the "DNS Domain" 
field from being blank (error appears). As a workaround, some string must be
entered for domain. To be consistent with the equivalent view for 
Workbench users, this edit behavior was removed in version 3.1.1.


*** 23.1:7390  HX view for TCP/IP settings allows DNS Domain edit when DHCP is enabled ***
  Record Type:  Bug
  Resolved In:  3.1.1
When an HX user uses a browser to edit TCP/IP settings in PlatformService for
a station running version 3.0 software, the "DNS Domain" field is enabled even
when DHCP is already enabled.  In this case, this field should be unavailable, 
just as the (static) IP Address and Subnet Mask fields. Version 3.1.1 of this
Hx view correctly disables the DNS Domain field when DHCP is being used.

*** 23.1:7401  DuplicateSlotException error in some cases when changing platform's module content filter ***
  Record Type:  Bug
  Resolved In:  3.0.94
When using the Commissioning Wizard to change the Module Content Filter
level, an error (DuplicateSlotException) sometimes occured immediately after
the filter change was applied. 

This error was fixed in patch 3.0.93.1 of the platform module.  There is no 
known workaround when this problem occurs in earlier builds.



*** 23.1:7421  "Audit" button in Workbench Tcp Ip Platform Service Plugin not functional in browser ***
  Record Type:  Bug
  Resolved In:  3.1.1
Browser access of Workbench to a 3.0 station's PlatformServices, TcpIpService 
editor includes an "Audit" button. When pressed, this produces an HTTP 404 error
(File not found). The Audit button was removed from this view in version 3.1.1.

*** 23.1:7450  Imported modules and dist files are not useable without Workbench restart ***
  Record Type:  Bug
  Resolved In:  3.1.1
In the release 3.0 version of Workbench, many installable files that are 
imported into the software database cannot be installed using platform tools
without first restarting Workbench.

Software is imported when:
1) Files are moved from !sw/inbox the first time the Commissioning Wizard, 
Software Manager, or Distribution File installer is run.
2) Files are imported using the Import button on the Software Manager platform
view.
When an administrator tries to install one of the recently imported files,
an exception is thrown. This behavior was fixed in build 3.1.1.

As a workaround for Workbench 3.0, after importing software, close and restart
Workbench.  Imported files will then be usable.

*** 23.1:7486  Add Garbage Collection action to PlatformService ***
  Record Type:  Enhancement
  Resolved In:  3.0.95
Added a means for requesting the Java Virtual Machine (JVM) in which the 
Niagara instance is running perform garbage collection.   This results in the
JVM making a "best effort" toward releasing unused objects and making the 
memory available to the "heap," but it is not guaranteed to be 
instantaneous or complete.

To request garbage collection for a station running 3.0.95 or higher, invoke 
the right-click "Request Garbage Collection" action on the PlatformServices
container or on the System Platform Service.

Please note that current heap and memory statistics for any running station
opened in Workbench are available via the Resource Manager view on the 
Station component.

*** 23.1:7587  Corrupt module files in software database makes platform installer views unusable ***
  Record Type:  Bug
  Resolved In:  3.1.1
If a file in the software database becomes corrupt, it may cause platform
installer software, such as the Distribution File Installer, the Software 
Manager, and the Commissioning Wizard, to fail (when rebuilding software list),
possibly halting Workbench.

This behavior, which although possible is very unlikely, has been fixed in 
release 3.1.1.   Users who see this problem with earlier versions of Niagara 
may be able to continue working by identifying the corrupt file (it will be 
stored somewhere under the !sw directory) and deleting it, or by re-installing 
Workbench.

*** 23.1:7605  Restart Station action of PlatformServiceContainer in QNX-based JACE caused errors ***
  Record Type:  Bug
  Resolved In:  3.1.1; 3.0.98
For a QNX-based Jace running build 3.0.97 or earlier, if the "Restart Station" 
action of its station's PlatformServices container is invoked, nothing results.
Instead, an exception is thrown:

javax.baja.sys.ActionInvokeException
   at com.tridium.fox.sys.broker.BFoxComponentSpace$FoxTrapCallbacks.invoke(BFoxComponentSpace.java:320)
   at com.tridium.sys.schema.ComponentSlotMap.invoke(ComponentSlotMap.java:1188)
   at com.tridium.sys.schema.ComponentSlotMap.invoke(ComponentSlotMap.java:1173)
   at javax.baja.sys.BComponent.invoke(BComponent.java:1000)
   at javax.baja.ui.commands.InvokeActionCommand.doInvoke(InvokeActionCommand.java:96)
   (etc)

In build 3.0.98, and in 3.1 releases, the "Restart Station" action has been 
fixed. Now, a *reboot* of the QNX-based JACE occurs (station restarts are not 
available on QNX-based platforms).

As a workaround in JACEs running pre-3.0.98 release, a manual reboot is available
using a platform connection (Reboot button in the Platform Administration view).
Developers can programmatically request reboots using the hidden "reboot" action on 
the SystemPlatformService.

*** 23.1:7609  Changing locale using PlatformService on QNX-based JACE fails ***
  Record Type:  Bug
  Resolved In:  3.1.1
If the "Locale" field is changed in the PlatformServices Container view for a 
station running release 3.0 software on a QNX-based JACE, an exception 
is thrown when the changes are saved.

The problem has been fixed in version 3.1.1.   You can use the following 
workaround to modify the locale on a QNX-based JACE having 3.0 software:

1) Using the File Transfer Client platform view, copy the file 
   /niagara/lib/system.properties from the JACE to the local computer   

2) Open the local copy in a text editor (Workbench will do), and change the 
   line that looks like this:

   #niagara.lang=en

   to look like this (where en_GB is the new locale code):
   niagara.lang=en_GB

   then save the changes.
 
3) Using the File Transfer Client, copy the updated system.properties file back
   to the /niagara/lib directory on the JACE.

4) Reboot the JACE using the Platform Administration platform view.

*** 23.1:7697  Low memory detection scheme added for station running on a QNX-based JACE ***
  Record Type:  Enhancement
  Resolved In:  3.1.2; 3.0.99
Starting in build 3.0.99, a station running on a QNX-based JACE periodically
tests for low memory conditions (excessive Java heap).  The current heap free
byte count is compared against the "Minimum Free Heap Size", as defined in the
SystemPlatformService (PlatformServices container). The test runs once a minute.

If the heap free byte count is less than the defined min free heap size, a 
garbage collection cycle is forced.  If there still is not enough free memory,
a "low memory warning" appears in all Workbench views of the station. The 
warning is a yellow message box overlayed on any new view accessed, or on any 
current view that is refreshed.  The warning is removed when the heap free byte
count rises above the defined min free heap size--such as might occur if enough
components are deleted from the station.

The default "Minimum Free Heap Size" setting for QNX-based JACEs are:
 - JACE-2  : 3 MB
 - JACE-4/5: 8 MB
This property is found on the Platform Service Container Plugin view.

Note that all memory statistics, including heap, are accessible on a station
opened in Workbench, via the Resource Manager view of the Station component.

*** 23.1:7712  Display Platform port in Station's Platform Manager ***
  Record Type:  Enhancement
  Resolved In:  3.1.2
Starting in build 3.1.2, a read-only "localDaemonPort" property was added to 
a station's PlatformService.  It shows the port number on which the platform 
daemon that started the station is listening. This could prove useful in case
someone changed the platform daemon port, and forgot what the new value is.

*** 23.1:7717  Error removing DNS Server in TcpIpService view of QNX-based JACE ***
  Record Type:  Bug
  Resolved In:  3.1.2
When removing a DNS Server in the TCPIP Platform Service Plugin view of a
QNX-based JACE, if you Save the changes but do not reboot (as prompted), after
you refresh the view garbage text appears in the old DNS Server entry.

This was fixed in revision 3.1.2.

*** 23.1:7842  JACE-NXS support for UPS (NXS-UPS) added in PowerMonitorService ***
  Record Type:  Enhancement
  Resolved In:  3.1.7
Platform support for a JACE-NXS includes a PowerMonitorService under a
station's PlatformServices, which can monitor a UPS option (model NXS-UPS,
which is a USB-connected "SITOP DC-USV 15" by Siemens). Currently, this is
the only UPS supported by the PowerMonitorService in a JACE-NXS station.

The PowerMonitorPlatformServiceNxsWin32 container provides various properties,
including monitor states for primary power present, battery OK, and running
on battery. Included is a configurable shutdown delay time. Separate alarm
support is provided for low battery, loss of power, and loss of USB connectivity
to the UPS.

If the JACE-NXS is not equipped with the NXS-UPS option, the PowerMonitorService
component is still present, however, most properties have no application.

*** 23.1:7960  Memory leak in TimeUtil in QNX-based JACEs ***
  Record Type:  Bug
  Resolved In:  3.0.100; 3.1.6
A case was reported of a QNX-based JACE leaking OS memory. Investigation found
that the /time servlet was being invoked every second on the platform daemon 
using method
 TimeZone::getCurrentNativeTimeZone()
Each invocation resulted in a small (< 128 byte) memory leak. 
From a station, a VM memory leak would also occur due to the same bug each
time "BSystemPlatformService getPlatformTimeZone()" is called.

This memory leak bug was fixed in build 3.0.100 and build 3.1.6.

*** 23.1:7987  FileTransferOperation.makeDelete public API method did not work correctly ***
  Record Type:  Bug
  Resolved In:  3.0.99; 3.1.7
(Developer's Release Note)
This issue affects customers who write Java code that uses the public platform
API to perform file transfers with the platform daemon.

In NiagaraAX 3.0.98 and earlier, the FileTransferOperation.makeDelete() 
method mistakenly created a FileTransferOperation that sent a "put" request 
instead of a "delete" request.  This has been corrected for builds 3.0.99 and
3.17 and higher.

There is no workaround for this problem.

*** 23.1:8071  Constant Windows "No Disk" popup when accessing File Chooser ***
  Record Type:  Bug
  Resolved In:  3.1.17
In AX 3.0 and 3.1 builds prior to 3.1.17, when opening the File Chooser from 
platform or platform service interfaces, sometimes a Windows error dialog
pops up, having the title "Windows - No Disk" and the message "There is
no disk in the drive. Please insert a disk into the drive." 

The problem has been fixed in build 3.1.17.  There is no workaround for earlier
builds.

*** 23.1:8073  API ability to check validity of dist for target JACE ***
  Record Type:  Enhancement
  Resolved In:  3.3.16
In AX release 3.3, the javax.baja.platform.InstallManager class has been
enhanced to include three new methods:

- the new checkInstall() method allows a developer to determine whether a 
software installation would work before actually attempting it, and to 
provide details about which files would be installed, which modules would be 
uninstalled, and which dependencies cannot be met.

- the new getPlatformParts() method enumerates all of the "platform parts"
including installed software, OS, model name, brand name, system board, etc. 
on the remote host, against which software dependencies may be defined.  This
will be useful for some OEM developers in choosing which of several
distribution files is the correct one to install for a particular device.

- the new registerInstallableFile() method allows a developer to copy
a file into the appropriate subdirectory under !sw, so that installer
code can automatically install it to satisfy dependencies that are declared
against it.

*** 23.1:8127  Rename history.zip and alarm.zip after save complete to avoid corruption ***
  Record Type:  Bug
  Resolved In:  3.1.10
Prior to build 3.1.10, the following procedure was using to save alarm and
history data:

1) Rename existing history.zip/alarm.zip to backup version 
2) Write new data directly to history.zip/alarm.zip

If the flash disk becomes full during this process, the new history.zip or
alarm.zip could become corrupt. The next time the station starts, it may not be
able to read the zip files and the history/alarm databases would not be
properly initialized. Manual intervention would be required to replace the
history.zip/alarm.zip files with the backup versions.

In builds 3.1.10 and 3.0.101 and later, the procedure was changed slightly 

1) Remove existing backup (this is important to increase free disk space) 
2) Write new data to a .working file 
3) Upon success, rename existing alarm.zip or history.zip file to backup 
4) Rename .working file to alarm.zip or history.zip

Note that there is still the potential for data loss if the new data will not
fit onto the flash disk. The new approach, however, prevents the need for manual
intervention to recover the backup data.

*** 23.1:8133  Low disk space warning in all station views ***
  Record Type:  Enhancement
  Resolved In:  3.1.10; 3.0.101
Starting in build 3.1.10 and 3.0.101, any station periodically tests the free
disk space available on the platform. If less than 1 MB of free disk space is
detected, a "low disk warning" appears in all Workbench views of the station.

The warning is a yellow message box overlayed on any new view accessed, or on
any current view that is refreshed.  The warning is removed when free disk space
is increased to more than 1 MB.

*** 23.1:8265  Win32 native platform authentication requires explicit membership in local groups ***
  Record Type:  Bug
  Resolved In:  3.1.15; 3.0.101
This problem affects only Win32 platforms whose Niagara service is configured
to use basic/native authentication.  In most cases, it applies to an AxSupervisor
or perhaps an AX SoftJACE. 

In the Win32 basic/native access control implementation for the Niagara Service, 
in AX 3.0 build 100 or earlier, or in AX 3.1 build 14 or earlier, an account is 
considered to be a member of a local group only if it's *explicitly* granted 
membership in the group.   If that local group's membership includes *groups* in 
which the account is a member, the test will fail and the platform logon will be
denied.

For example, suppose the Niagara service is running on an AxSupervisor that is 
the member of the ACME domain, and the machine's local "Users" group contains 
the following members:

 ACME\Domain Users
 NT AUTHORITY\Authenticated Users
 NT AUTHORITY\INTERACTIVE

Even if a user "ACME\jdoe" who is a member of the "Domain Users" group attempts to 
make a platform connection to this AxSupervisor, the login attempt will be 
rejected.

The problem has been fixed in builds 3.0.101 and 3.1.15.   To work around it
in earlier builds, you can:

1) use the Windows "Computer Management" control panel applet to add all affected 
  members directly to the local groups
  
2) configure the Niagara service in the host to use digest/file authentication.
To make the change:
  a) Open the "Control Panel | Administrative Tools | Services" window and stop 
    the "Niagara" service
  b) Under the directory where Niagara is installed, there is a daemon 
    subdirectory.   Open the "daemon.properties" file in a text editor.
  c) Change the "authtype" line to appear "authtype=digest/file"
  d) By default, the service will use "tridium" and "niagara" as its
  username and password.   To use different values, change or add "user" 
  and "password" properties to the file
  e) Save the properties file changes and restart the Niagara service

*** 23.1:8288  Change default station backup count to 0 on QNX-based JACEs ***
  Record Type:  Enhancement
  Resolved In:  3.1.15; 3.0.101
Starting in build 3.0.101 and 3.1.15, the default station backup count on all
QNX-based JACEs (JACE-2, -4, -5 series) has been changed from 3 to 0. This 
frees up significant flash disk space.

Background: Each time the station saves its database, it can optionally keep 
a "backup copy" of the old config.bog named config_backup_<timestamp>.bog.
If desired, you can change the backup count by opening the station running on
the JACE, and going to Config -> Services -> PlatformService property sheet and
adjusting the value for its property "Station Auto-Save Version to Keep".


*** 23.1:8377  Allow merging of username and password in daemon.properties file ***
  Record Type:  Enhancement
  Resolved In:  3.1.16
(Developer's Release Note)
The javax.baja.platform.InstallOperation now has a setIgnoreAuthChanges(boolean) 
method, which when set to true will prevent the installation of a distribution 
file from clobbering the platform's current authentication settings. Standard
platform operations performed by Workbench will remain unaffected.

*** 23.1:8555  Web Workbench access of "Get Online" in License Service is faulty ***
  Record Type:  Bug
  Resolved In:  3.1.21
When accessing a station via Web Workbench, the License Platform Service
Plugin provided the "Get Online" button to retrieve the license from the
Niagara Central portal.  Using this feature would either produce an error,
or report licenses are up-to-date (yet still produce a license request form).
In either case, operation was not as intended.

Starting in AX-3.1 build 3.1.21, the "Get Online" button is disabled when
accessing the station's Services > PlatformServices >LicenseService via 
Web Workbench.  Use of this feature is supported only with a (full) Workbench
connection to the station.



*** 23.1:8556  Web Workbench access of station's Platform License Service fails on some hosts ***
  Record Type:  Bug
  Resolved In:  3.1.21
When using Web Workbench to access a station in some hosts (e.g. JACE-2),
you may be unable to open the "License Platform Service Plugin", meaning
the default view on the station's Services > PlatformService > LicenseService.
A "Cannot display page" error occurs with details showing an exception.
This occurs if the host running the station does not have the "portalApi"
module installed.

This was fixed in AX-3.1 starting in build 3.1.21.

As a workaround for hosts running earlier builds, open a platform connection
to the JACE and use the Software Manager to install the portalApi module.

*** 23.1:8731  Hx TCP/IP Platform Service plugin uses bad lexicon keys ***
  Record Type:  Bug
  Resolved In:  3.0.102; 3.2.1; 3.1.24
In AX-3.0 builds 3.0.101 and earlier, and AX-3.1 builds 3.1.22 and earlier, 
the HX view for the TCP/IP Platform Service mislabels the Gateway and DNS Hosts
fields.

Also, for a QNX device with more than one network adapter (i.e JACE-2), several
fields' endabled states aren't correctly handled on the second adapter.  On the
HX version of the view, the enabled states aren't correctly changed when the 
enabled field of the second adapter are changed.   On all versions of the view,
the DHCP enabled field shows "true" when it should be "false".

There is no workaround for this bug.  Users wishing to make changes to the
second network adapter must upgrade the software (3.0.102 or 3.1.24 or
later).


*** 23.1:8843  NullPointerException when module is not present on the target host ***
  Record Type:  Bug
  Resolved In:  3.1.25; 3.2.1
(Developer/OEM release note)
Customer-written software that uses the 
javx.baja.platform.InstallOperation.uninstallModule() method will get a
NullPointerException if they give the name of a module that is not currently
present on the remote host, similar to:            

java.lang.NullPointerException
   at com.tridium.install.BInstallManifest.commit(BInstallManifest.java:725)
   at com.tridium.install.BInstallManifest.commit(BInstallManifest.java:661)
   at com.tridium.platform.daemon.PlatformInstallManager.install(PlatformInstallManager.java:162)
   ..

A check for the existence of the module has been added in AX 3.1, build 3.1.25.

Customers wishing to work around this problem when writing software to work with
AX 3.0 code should programmatically verify the presence of any modules before 
calling uninstallModule() with their module names.

Also, programmers should note that the correct way to provide the name of
a module is without any path information or ".jar" suffix.  That is, "platform"
is correct, but "platform.jar" or "!modules/platform.jar" is not.

*** 23.1:8981  Work around issue #8950 in AX 3.1 installer scenarios ***
  Record Type:  Enhancement
  Resolved In:  3.1.25; 3.2.1
QNX-based JACEs running AX version 3.0.102 or earlier have a bug in the platform
daemon that prevents certain files from being installed if a station has been 
started since the device booted.  This bug is documented as issue #8950, and has
been fixed in AX versions 3.0.103 and later.

Starting in build 3.1.25, the following installation tools automatically perform
additional steps when upgrading Niagara core software from 3.0.102 or earlier on
QNX-based JACEs, to work around this bug:
- Commissioning Wizard
- Distribution File Installer
- Provisioning
- "plat distinstall" command-line utility 
- public platform API (javax.baja.platform)

When these tools perform an upgrade to an affected Niagara core version, they 
will take the following steps before starting any file transfers:
- temporarily unset the station's "Auto-Start" property
- reboot the device
- reconnect after reboot completes
- restore the station's "Auto-Start" property to its correct value

Note that other upgrades to software not impacted by this 3.0 bug will work 
normally, without the extra device reboot.


*** 23.1:9289  JACE station fails to start with exception in BSystemPlatformServiceQnx.isLowDisk() ***
  Record Type:  Bug
  Resolved In:  3.1.29.2; 3.0.106.1
A station with a restricted resource license could fail to start, with a
NullPointerException in BSystemPlatformServiceQnx.isLowDisk() due to a race
condition in the initialization code.

This bug was fixed in platform.jar patch version 3.1.29.2 and in build 3.1.30.

*** 23.1:9370  Some JACE software upgrades from 3.0 to 3.1 fail ***
  Record Type:  Bug
  Resolved In:  3.1.30; 3.2.6
This documentation replaces release note 8950.

QNX-based JACEs running AX version 3.0.102 or earlier have a bug in the platform
daemon that prevents certain files from being installed if a station has been 
started since the device booted.  This bug is documented as issue #8950, and has
been fixed in AX versions 3.0.103 and later.

Niagara AX 3.1 builds 3.1.25 and later automatically perform additional steps when upgrading 
Niagara core software from 3.0.102 or earlier on QNX-based JACEs, to work around this bug:
- Commissioning Wizard
- Distribution File Installer
- Provisioning
- "plat distinstall" command-line utility 
- public platform API (javax.baja.platform)    

When these tools perform an upgrade to an affected Niagara core version, they 
will take the following steps before starting any file transfers:
- temporarily unset the station's "Auto-Start" property
- reboot the device
- reconnect after reboot completes
- restore the station's "Auto-Start" property to its correct value

However, for builds 3.1.25 to 3.1.29 the workaround does not run when the installation is 
performed after the administrator has manually stopped a station, or after a station has 
failed, and the 3.1 upgrades fail.  The installer code in builds 3.1.31 and later has been 
fixed to correctly handle halted and failed stations.

Customers upgrading QNX-based JACEs from Niagara AX 3.0 builds 3.0.102 and earlier to AX 3.1
should upgrade their Workbench client to build 3.1.30 or later, or use one of the following
workarounds:

1) start the software upgrade while the station is running
2) ensure the software upgrade starts while the station is idle as follows:
- use the Station Director to disable "auto-start"
- reboot the JACE
- use the Station Director to re-enable "auto-start"
      
Note that other upgrades to software not impacted by this 3.0 bug will work 
normally, without the extra device reboot.


*** 23.1:10016  "nodisplay" part breaks backup dists ***
  Record Type:  Bug
  Resolved In:  3.3.1; 3.2.16
A bug was found in releases 3.2.14 and 3.2.15 that broke backups on QNX Jaces
when trying to restore them. This has been fixed.

When restoring a backup done under builds 3.2.14 and 3.2.15 "nodisplay" part must be removed from the backup dist.xml file.

*** 23.1:10173  NullPointer exception when using the public platform API to install backup distributions ***
  Record Type:  Bug
  Resolved In:  3.2.17
Programmers who use the javax.baja.platform.InstallManager class, with versions 
3.2.16 of the platform module, to install backup distribution files will 
encounter exceptions similar to the following:

  java.lang.NullPointerException
    at com.tridium.install.InstallScenario$UpdateModuleContentMessage.getMessageString(InstallScenario.java:1359)
    at com.tridium.platform.daemon.BDaemonSession.sendMessage(BDaemonSession.java:876)
    at com.tridium.platform.daemon.BDaemonSession.sendMessage(BDaemonSession.java:861)
    at com.tridium.install.InstallScenario.commit(InstallScenario.java:503)
    at com.tridium.install.InstallScenario.commit(InstallScenario.java:452)
    at com.tridium.platform.daemon.PlatformInstallManager.install(PlatformInstallManager.java:140)
    ...

This problem has been corrected in a 3.2.16.1 patch of the platform module,
and in later 3.2 builds.  There is no workaround for 3.2.16.


*** 23.1:10204  DaemonSecurityManager methods throw AuthenticationException after successfully changing authentication settings ***
  Record Type:  Bug
  Resolved In:  3.3.3
When developers use DaemonSecurityManager's useSingleAdminAccount() or useOsGroups() methods to change
the authentication settings for a platform daemon, the change will be made successfully, but
an AuthenticationException will be thrown.

This exception is the result of a follow-up request being made by the daemon session code after the message
is sent, with the old credentials.

This problem affects all released versions of AX where DaemonSecurityManager is implemented.

To work around the problem, developers should catch and ignore the AuthenticationException that
is thrown.   A simplified example:

    PlatformDaemon daemon;                  
    String host;
    int port;
    String oldUsername;
    String oldPassword;
    String newUsername;
    String newPassword;
    
    daemon = PlatformDaemon.make(host, port, oldUsername, oldPassword); 
    try
    {
      daemon.getSecurityManager().useSingleAdminAccount(newUsername, newPassword);
    }
    catch (AuthenticationException ae)
    {
      // AuthenticationException is probably the result of a known bug in 
      // BDaemonSession, and if so can be safely ignored
    }
    // Verify that the new credentials work correctly.   If they don't, an AuthenticationException will be thrown
    daemon = PlatformDaemon.make(host, port, newUsername, newPassword);



*** 23.1:10823  InstallOperation.installModule doesn't upgrade existing module if null version is requested ***
  Record Type:  Bug
  Resolved In:  3.2.17; 3.3.11
The javadoc for the version parameter of the InstallOperation.installModule()
method says "version of the module to install, or Version.NULL for latest 
available version", but if Version.NULL is used, existing modules aren't 
upgraded when the operation is committed using Niagara AX version 3.2.16 
or earlier.  

This problem has been addressed in patch version 3.2.16.5 of the platform
module, and will be available in all products based on AX builds 3.2.17 and
later.

There is no workaround for uncorrected versions of the API.


*** 23.1:10824  Exception thrown when InstallManager is used to install backup distributions ***
  Record Type:  Bug
  Resolved In:  3.2.17; 3.3.11
Developers programming against the public javax.baja.platform API may encounter
the following exception when using InstallManager to install backup 
distribution files.

This problem has been fixed in patch 3.2.16.5 of the platform module, and
will be available with all AX products based on builds 3.2.17 and later.

=========================================================================
23.2  Open
=========================================================================

*** 23.2:8345  Generate alarm on station save failure ***
  Record Type:  Enhancement
  Resolved In:  3.2.2
In AX 3.2, a failed station save for any reason (for example, disk full) will
cause an alarm to be raised.   If a subsequent save is successful, the alarm 
state will be considered "normal".

A new "Station Save Alarm Support" container slot on the station's 
PlatformServicesContainer contains properties used to configure this alarm.

#########################################################################
24  platBacnet
#########################################################################

=========================================================================
24.1  Fixed
=========================================================================

*** 24.1:7948  Ethernet driver received extra byte in packets ***
  Record Type:  Bug
  Resolved In:  3.0.100
In builds prior to 3.0.100, QNX-based JACEs using the BACnet Ethernet link layer
would report an incorrect number of bytes received from the wire.  The number
was one greater than the actual number of bytes received.  The extra byte
caused troubles in decoding the packet received from BACnet, which could
present itself in several ways.  Most of the time, the relevant piece of data
would not be successfully retrieved, and some sort of exception stack trace
would be displayed in the output window.

This was fixed in Build 3.0.99.1 of the platBacnet module.  The correct packet
is now returned to the application layer.



*** 24.1:8458  Ethernet driver doesn't handle packets between 128 and 256 bytes ***
  Record Type:  Bug
  Resolved In:  3.0.101; 3.1.18
This problem is only applicable to 5xx series JACEs.

When Niagara receives a BACnet/Ethernet packet with a length between 128 and
256 bytes, the length is not calculated correctly.  The incorrect length
calculation prevents the packet from being recognized.  For an unsolicited
packet, the packet will simply be ignored.  But for a packet that is a response
to a Niagara request, this will lead to the request timing out, and a failure
of the transaction.

This has now been fixed.  The length is calculated correctly, and the packets
are recognized properly.

#########################################################################
25  platDaemon
#########################################################################

=========================================================================
25.1  Fixed
=========================================================================

*** 25.1:6769  Drag and drop files in File Transfer Client showed incorrect path ***
  Record Type:  Bug
  Resolved In:  3.1.1
In 3.0.x, dragging and dropping files in File Transfer Client did not show 
correct path in the verification popup dialog.  For example if you dragged a 
file from your local machine to a specific folder under the remote host's
! directory, the popup dialog would display "Transfer file(s) to !?" instead 
of "Transfer file(s) to !/folder?".  However, the drag and drop operation did
copy the file to the correct folder.

In 3.1.1, this issue was fixed. The verification popup shows the target path.

*** 25.1:6889  Details dialog doesn't show dependencies for OS, VM, or NRE Core items ***
  Record Type:  Bug
  Resolved In:  3.1.1
In version 3.0 of the Software Manager, the dialog that displays after
double-clicking the row for a non-module part (OS, VM, NRE, arch, model, 
etc.) doesn't show dependencies. In NiagaraAX 3.1, the dependencies are 
now correctly displayed.

Note this is a display problem only, and does not affect the actual dependency 
checks performed during software installation.  No 3.0 workaround is necessary.

*** 25.1:6906  Make reboot limit & reboot limit period configurable through the UI ***
  Record Type:  Enhancement
  Resolved In:  3.1.1
The platform daemon on any QNX-based JACE uses two properties to limit the
number and frequency of system reboots triggered by station failures:

 failureRebootLimit=x       (where x is integer, default is 3)
 failureRebootLimitPeriod=y (where y is long in ms., default is 3600000)

These properties are stored in the !daemon/daemon.properties file on the JACE.
In AX version 3.1, these properties are exposed in the PlatformServices of
a station running on the JACE, and are editable by an administrator.

*** 25.1:6927  Corrupt module manifest on JACE can prevent platform views from opening ***
  Record Type:  Bug
  Resolved In:  3.1.1
In NiagaraAX 3.0, a corrupt module on a JACE could cause platform installation
views to fail, such as the Software Manager, and trouble in other views such as
Platform Administration, Station Copier, and Station Director (verify function).

In NiagaraAX 3.1, the platform daemon now attempts to validate module manifests
before sending them to the Workbench client.  When a corrupt module is found, it
is reported in a well-formed XML response, such that the client can continue to
function.

As a workaround in NiagaraAX 3.0, you can stop the station on a problem JACE,
then delete module files using the File Transfer Client view.  Then, re-install
the modules using the "Verify Software" function from the Station Director view.

*** 25.1:6938  Add icon and version to descriptions of items to be installed ***
  Record Type:  Enhancement
  Resolved In:  3.1.1
When the Distribution File installer version 3.0 identifies upgraded modules 
for out-of-date software, it displays them without version information. In 
version 3.1, the formatting has been changed to include icons and full
version information.

Note this is a cosmetic change which does not affect the function of the 
installer--no 3.0 workaround is necessary.

*** 25.1:6943  Unable to export Platform Text Summary with Daemon Console Output ***
  Record Type:  Bug
  Resolved In:  3.1.1
In two platform views that provide exporter functions (Platform Administration
and Station Director), Workbench's export function (File > Export) would fail
with an error if set up to display Daemon Console Output (Setup tab in Export
dialog). Error details would show a SocketTimeoutException.

The problem has been corrected in builds 3.1.1 and later.  In all 3.0.x builds
this problem remains, and there is no workaround.

*** 25.1:7018  Refreshing Remote File System view duplicates "config".   ***
  Record Type:  Bug
  Resolved In:  3.0.90
When navigating to the "Remote File System" child under a "Platform" node
in the Workbench nav tree, an additional "config" child was added under 
the Remote File System. This was a cosmetic problem that did not cause any 
functions to work incorrectly, and there was no workaround. 
Starting in build 3.0.90 this was fixed ("config" children not added).

*** 25.1:7022  New platform daemon installed on Swedish Windows doesn't accept login credentials ***
  Record Type:  Bug
  Resolved In:  3.0.90
The platform daemon (niagarad) now correctly authenticates users to Windows
systems in most non-English locales.   The fix is available in builds 3.0.92
and higher.

Customers having build 3.0.91 or earlier should perform the following
work-arounds to avoid problems:

1) when creating native accounts for use on a Jace NX using the User Manager,
use only ASCII characters in the account names

2) after installing Workbench or Web Supervisor on a non-English version of 
Windows:

- open a command (DOS) window and issue the "net stop niagara" command to shut 
down the Niagara service

- modify the {system home}/daemon/daemon.properties file with a text editor by 
adding the following lines:

  authtype=digest/file
  user=youraccount
  password=yourpassword
  
note that the password will be encrypted after the first time the platform
daemon reads it

- issue the "net start niagara" command to re-start the Niagara service

*** 25.1:7065  When exception occurred using Commissioning Wizard, dialog could not be closed. ***
  Record Type:  Bug
  Resolved In:  3.0.90
When using the Commissioning Wizard to install modules to a QNX-based JACE
that had a running station, the wizard incorrectly attempted to restart the
stopped station after the installation was complete.  This resulted in an 
exception being thrown, and you could not close the Commissioning Wizard dialog.
To recover from this, you had to terminate Workbench using the Windows Task 
Manager.

The problem of not being able to close the Commissioning Wizard was fixed 
starting in build 3.0.90.  In addition, the wizard no longer attempts to restart
the station following the reboot from the software installation.

To avoid this problem (if using earlier builds), use the Station Director 
to stop the running station before opening the Commissioning Wizard.

*** 25.1:7088  Cannot load platform after installing a backup or config dist file ***
  Record Type:  Bug
  Resolved In:  3.0.90
After using the Distribution File Installer to install a distribution file 
created by a backup, or after using the Distribution File Installer or 
Commissioning Wizard to install an nre-config-xxx.dist distribution file, the 
correct Platform Services were sometimes not available to stations.

Often, the station encountered stack traces similar to the following:

ERROR [09:57:08 13-Jul-05 EDT][sys.service] Service start failed: History Service
javax.baja.sys.ServiceNotFoundException: platform:SystemPlatformService
   at com.tridium.sys.service.ServiceManager.getService(Unknown Source)
   
When this problem occurred, the Platform Services node in Workbench's nav tree
had no service children, and double-clicking the Platform Services node
resulted in an error.

This was corrected in build 3.0.90.

If using an earlier build, you can sometimes solve this problem by installing
the backup/config dist file twice.   There is no other known workaround apart
from using build 3.0.90 or later.

*** 25.1:7091  Allow installation from backup dists to leave TCP/IP settings unmodified ***
  Record Type:  Enhancement
  Resolved In:  3.0.90
In build 3.0.90, a new step was added to the Distribution File Installer's
wizard that will allow the administrator to ignore TCP/IP changes that are
contained in a backup distribution file.

The step shows the administrator a summary of the TCP/IP settings that will be 
installed with the distribution file, and has a checkbox labeled "update the 
remote host's TCP/IP settings" which is checked by default.

If the checkbox is unchecked, the installer will leave the host's TCP/IP 
settings unmodified when the file is installed.

*** 25.1:7099  Repeatedly changing platform daemon credentials causes daemon to deadlock ***
  Record Type:  Bug
  Resolved In:  3.0.94
It was found that repeatedly changing the platform daemon credentials (in a
platform connection, from Platform Administration view, "Update Authentication")
could cause the platform daemon to deadlock.  Regaining a platform connection
then required a host reboot. Typically, the last entered credential (password)
were found to be working.

This issue was fixed in release 3.0.94. As a workaround in earlier releases, 
avoid changing the platform daemon credentials multiple times in succession.

*** 25.1:7121  Distribution File Installer threw exceptions if invalid dist files ***
  Record Type:  Bug
  Resolved In:  3.1.1
In 3.0, when the Distribution File Installer loaded a directory containing 
invalid dist files, an exception dialog was raised for each invalid dist file
in the directory, saying:

"Error parsing {filename}.  Error parsing manifest XML for distribution file
{filepath}"  

NOTE: A dist file is considered invalid if it has a badly-formatted manifest, 
or is otherwise unreadable.

This was a cosmetic problem for which there is no 3.0 workaround.

In 3.1, this issue was fixed--the Distribution File Installer identifies bad
dist files.

*** 25.1:7131  Rename in Station Copier allows invalid names, station start problems result ***
  Record Type:  Bug
  Resolved In:  3.1.1
Using Rename in the Station Copier allows invalid station
names, which will result in a station failure upon start.
Use caution when renaming stations using the Station Copier.

NOTE: A valid station name should begin with a letter, and contain 
only letters, numbers, and underscores.  

If a station on a Win32 host has been renamed using an invalid 
name and will not start as a result, you can fix it by browsing
to the {niagarahome}/stations/ directory using Windows Explorer 
and renaming it manually.   There is no straightforward workaround
for renaming a misnamed station on a QNX-based JACE.

This was corrected in 3.1.1.

*** 25.1:7132  QNX JACE did not reboot after authentication set from Commissioning Wizard ***
  Record Type:  Bug
  Resolved In:  3.0.91
When the Commissioning Wizard was used to update the authentication settings
for a QNX-based platform, the wizard did not finish properly, and could not be
closed.  The JACE was not automatically rebooted, and so the new authentication
settings were not yet effective. 

This was corrected in build 3.0.91.

If using an earlier build, workarounds for this problem include:
- use the Update Authentication button on the Platform Administration view
to change authentication settings instead of the Commissioning Wizard

- if Commissioning Wizard is used and becomes stuck, terminate Workbench
with Windows Task Manager, then reopen Workbench and use the Platform 
Administration view to explicitly reboot the platform daemon, forcing the
new authentication settings to take effect

*** 25.1:7165  Distribution File Installer cannot be closed when exception is thrown ***
  Record Type:  Bug
  Resolved In:  3.0.91
If the final step of the Distribution File Installer encountered an error 
resulting in an exception being thrown, you could not close the dialog window. 
You had to terminate Workbench using the Windows Task Manager.
Starting in build 3.0.91 this issue was fixed.

*** 25.1:7240  Connecting to a Win32 platform without credentials crashes platform daemon  ***
  Record Type:  Bug
  Resolved In:  3.0.91; 3.0.88
When you attempt to open a platform connection to a Win32-based host
(Jace NX, Workstation, Web Supervisor) running build 3.0.88.1 or earlier,
and leave both the user name and password blank, the platform daemon
running on that host crashes.

This error was corrected in the 3.0.88.2 patch, and in all subsequent builds
(3.0.89 and above).  To avoid this problem when opening a platform connection
to a host running version 3.0.88.1 or earlier of Niagara, when prompted for 
platform credentials, always provide a user name.

*** 25.1:7366  Backup command from Platform Administration view produces error message ***
  Record Type:  Bug
  Resolved In:  3.1.1
If you click the Backup button in the Platform Administration view while 
connected to host that is not running a station, and your Workbench system
home has no "backups" subdirectory, a popup error message occurs, with details
showing a null pointer exception.

As a workaround, manually create a "backups" subdirectory in your Workbench
system home.  Note that this subdirectory is automatically created the first 
time you do a backup with a running station opened (on any host).

This was corrected in 3.1.1.

*** 25.1:7389  VM Tuning Parameters available in Platform Administration of QNX-based JACE ***
  Record Type:  Enhancement
  Resolved In:  3.0.93
A "VM Tuning Parameters" button was made available in the Platform Administration
view when connected to any QNX-based JACE, starting in build 3.0.93.  Clicking this
button produces a "VM Tuning Parameters" dialog that lets you change the J9 VM heap
size and other various other parameters to modify the behavior of the VM.  Generally,
you should only change VM settings from defaults upon advice from System Engineering.

NOTE 1: Changing the J9 VM settings from defaults can have negative side effects
and render a station inoperable!  Only qualified personnel should adjust VM settings.
After changing VM settings using this dialog, if the station stops operating, you
can click the "Defaults" button in this dialog to reset the VM parameters back to the
default ("as shipped") state.

NOTE 2: Because the need for changing J9 VM settings is typically rare, yet 
potentially detrimental, starting in build 3.0.94 you must first enable your 
Workbench PC to allow access (to see the "VM Tuning Parameters" button).  After
doing this, if platform-connected to a QNX-based JACE, only then do you see 
this button in the Platform Administration view. (See issue #7415)

Enable by adding this line to your Workbench PC's <NiagaraHome>\lib\system.properties 
file:

 niagara.vmtuning.enabled=true

If this entry is missing, commented out, or is set to false, the "VM Tuning Parameters"
button does not appear in the Platform Administration view.

*** 25.1:7403  Filestore won't delete directories with '.' ***
  Record Type:  Bug
  Resolved In:  3.1.1
Version 3.0 of the platform daemon cannot delete directories that contain
subirectories having names beginning with ".".   Although it is not customary 
for Niagara directories to use such names, it is possible for them to exist 
and cause problems with the Station Copier or File Transfer Client.

This problem was fixed in version 3.1.1.  As a workaround for a platform 
running 3.0.x, you can use the File Transfer Client to explicitly delete any
directory with a name starting with ".".  Once deleted, the parent directory
can then be deleted. 

*** 25.1:7404  Platform daemon could crash while doing a station copy ***
  Record Type:  Bug
  Resolved In:  3.0.94
A bug was found where copying a station could cause the platform daemon to 
crash.  This was due to how the daemon handled deleting the old station that
had a long directory.  This was fixed in build 3.0.94.

*** 25.1:7415  Hide VM Tuning Parameters button ***
  Record Type:  Enhancement
  Resolved In:  3.0.94
Due to the volatility of the vm tuning parameters (see issue #7389), the VM 
Tuning Parameters button will not appear in platform administration unless the
key/value pair "niagara.vmtuning.enabled=true" is found in system.properties
on the Workbench client. The default if the property is not found is false.

*** 25.1:7451  Error checking station's config.bog for module references, when local module copies not available ***
  Record Type:  Bug
  Resolved In:  3.1.1
When a station is verified using the "Verify Software" button on version 3.0 of
the Station Director platform view, or version 3.0 of the Station Copier,
an exception is thrown if the station contains objects from modules that
do not exist on the Workbench PC.

This is an uncommon condition that will probably be seen only with stations
that use modules that aren't part of the standard Niagara release, like 
those written to support Niagara appliances.

The problem has been fixed in version 3.1.1.   Users who see this problem
while using 3.0 software can work around it by putting a copy of the missing 
module file(s) into the modules subdirectory of their Workbench PC's Niagara
working directory.    

*** 25.1:7452  ClassCastException in Commissioning Wizard if out-of-date NRE core, OS, or VM dists ***
  Record Type:  Bug
  Resolved In:  3.1.1
It is possible that the "Module Installation" step in the Commissioning Wizard 
will identify software that should be installed or upgraded that is not module 
software, such as OS, Niagara Core, or JRE software in distribution files. When
version 3.0 of the the Commissioning Wizard reaches the "Review of Changes" 
step, an exception is thrown if the user choses to install one or more of those
distribution files.

Version 3.1.1 of the Commissioning Wizard corrects this problem.  The problem
is rare, and users who do see it in 3.0 software can work around it by
using the Distribution File Installer to upgrade the OS, Niagara Core, and JRE
before using the Commissioning Wizard.


*** 25.1:7562  File names with special characters can cause failed platform operations ***
  Record Type:  Bug
  Resolved In:  3.1.1
Release 3.0 of the platform daemon may send file or user information to
the Workbench client using invalid XML, causing a exceptions to be thrown.
This problem was noted when copying a station (Station Copier) that contained
a file name using an ampersand ("&") character.  Although a legal character, 
it was not "escaped" correctly in the copy (as a result the copy failed).

Release 3.1 platform code was reviewed to ensure that XML attributes are 
properly escaped, and corrected where necessary.  As a workaround in any 3.0
platform, avoid special characters in file, user, and group names.

*** 25.1:7581  Renaming a station causes its AutoStart and RestartOnFailure settings to be lost. ***
  Record Type:  Bug
  Resolved In:  3.1.1
When using version 3.0 of the Station Copier to rename a station, its
Auto-Start and Restart on Failure settings are lost.

This problem has been fixed in version 3.1.1.   Administrators using earlier
versions should use the Station Director to verify these settings after
performing a station rename.

*** 25.1:7584  Platform installation functions to local (Workbench) host are invalid ***
  Record Type:  Bug
  Resolved In:  3.1.1
In release 3.0, a platform connection to the local (Workbench) host provided 
installation functions intended for remote JACE hosts.  Examples include the 
Distribution File Installer and Station Copier views, as well as installation 
and verification buttons in the Software Manager and Station Director views. 
These functions are not valid for the local host, since the software that would
be installed is the software Workbench is currently using. If used, unpredictable
results could occur, possibly corrupting the Workbench installation.

In release 3.1, during a platform connection to the local (Workbench) host, 
platform functions not applicable to the local host are changed, as follows:
- Distribution File Installer is no longer available
- Station Copier is no longer available
- Software Manager's Install, Upgrade, Downgrade, and Uninstall buttons are disabled
- Station Director's "Verify Software" button, when pressed, lists missing modules, but
  does not offer to install them.
- Platform Administration's "Set Module Filter" button is disabled

Please note that in release 3.0 systems, when using a platform connection to the 
local (Workbench) host, you should avoid installation operations using the above
platform functions.

*** 25.1:7631  Station names longer than 31 characters caused the platform daemon to crash ***
  Record Type:  Bug
  Resolved In:  3.0.98; 3.1.1
A problem was found in versions 3.0.97 and earlier of the platform daemon,
where the daemon could crash if the name(s) of the installed station(s) was 
longer than 31 characters.

This problem has been fixed in builds 3.0.98 and 3.1.1.   As a workaround
in earlier versions, use shorter station names.

*** 25.1:7689  SoftJACE rebooted by Commissioning Wizard if "Install station" step selected ***
  Record Type:  Bug
  Resolved In:  3.1.2
In  release 3.0, if the "Install a station" step is selected when running the
Commissioning Wizard on any host, a reboot of that host occurs upon 
wizard completition.  A reboot is needed for any QNX-based JACE, but is
not needed for a Win-32 host.  In particular, this issue is noticable
when using the Commissioning Wizard to commission a SoftJACE.

In 3.1.2, the wizard behavior was changed for any Win-32 target host
(SoftJACE, JACE-NX) such that a reboot does not occur from installing 
a station.

*** 25.1:7702  Allow user to skip re-install of up-to-date nre-config-* dist ***
  Record Type:  Enhancement
  Resolved In:  3.1.2
Starting in build 3.1.2, in the Commissioning Wizard's "Distribution File 
Installation" step, the wizard now performs a check to see if the host is 
already up-to-date with the dist files.   If so, the wizard step will display 
a checkbox saying  "Re-install the core software.", which is unchecked by default.

Prior to this change, it was cumbersome to skip re-installing the files, as
you had to hit "back" and deselect the step.

*** 25.1:7764  QNX-based JACEs move filesystem support to ETFS (no turning back) ***
  Record Type:  Enhancement
  Resolved In:  3.1.3
In NiagaraAX 3.1, all QNX-based JACEs (JACE-2/4/5s) will switch from using a 
block-oriented flash filesystem driver (devb-nand) to a transactional 
filesystem driver called ETFS.

To support ETFS, the filesystem must be converted from block format to ETFS
format.  This conversion will take place automatically when the new dist 
files are installed to the JACE.  The JACE will boot, detect the need to do a
conversion, convert the filesystem, then reboot again. The file system
conversion will take 2-3 minutes.

It is critical that power is not removed from the unit during the conversion
process. Before starting the conversion process, the JACE will verify that
primary power is present and that battery has sucessfully passed a test.  

If the battery is not good, the JACE will skip the conversion and continue to
use the old fileystem. The conversion will happen automatically the next time
the JACE boots and the battery test passes.

In order to perform the upgrade, the JACE must have approximately 2.5 MB of
free disk space. You will not be able to install the OS system upgrade if
enough disk space not available.

IMPORTANT NOTE: Once a JACE is converted to ETFS, it cannot be downgraded to 
NiagaraAX 3.0 or or any NiagaraAX 3.0 build. The dist file dependency 
checking will prevent downgrading.



*** 25.1:7820  Allow users to stream station output to a file ***
  Record Type:  Enhancement
  Resolved In:  3.1.6
In release 3.1, a new button "Stream To File" has been added to the Station
Director view. When pressed, the user is prompted for a file where station
output is to be captured, and a modified version of the "Output Dialog" dialog
is raised. In that dialog, the user can view the text as it is being captured,
and can also use the "Dump Threads", "Pause Output" and "Clear Output"
functions that the output dialog provides.

*** 25.1:8046  TCP/IP Configuration view fails to load if hosts file is missing ***
  Record Type:  Bug
  Resolved In:  3.3.14
In all AX 3.0, 3.1, and 3.2 builds, if the /etc/hosts file on a JACE is missing, the platform TCP/IP Configuration view 
and the station's TCP/IP Platform Service Plugins throw exceptions when loaded.

This issue has been resolved in AX 3.3.  To work around this problem in
earlier releases you should:

 - Create a text file on your local computer named "hosts" with no extension.
 
 - Open a platform connection to the JACE, and use the File Transfer Client to
   copy the "hosts" file into the JACE's /etc directory.

*** 25.1:8103  Change the default choice for restoring TCP/IP settings from backup dists ***
  Record Type:  Enhancement
  Resolved In:  3.0.101; 3.1.9
When installing a backup distribution file a confirmation screen is displayed saying "The distribution 
file contains TCP/IP settings that may be used to update the remote host", with the TCP/IP settings
and a checkbox that says "Update the remote host's TCP/IP settings" that is checked by default.

Since backup distribution files are frequently used as "templates" for Niagara-based appliances, they
rarely have the TCP/IP settings that the appliance owner actually intends to use.   If an administrator
of such an appliance mistakenly fails to uncheck the "Update the remote host's TCP/IP settings" 
checkbox, the device will become unreachable over the network.

Since the risk of unintentionally failing to make proper changes to IP settings is much less than the 
risk of unintentinally making unwanted changes, the default for this checkbox was changed to be UNchecked. 
This change is effective starting in builds 3.0.101 and 3.1.9. 

*** 25.1:8104  UI allows configuration of more than 3 DNS servers in QNX-based JACE ***
  Record Type:  Bug
  Resolved In:  3.2.12
In all Niagara AX 3.0 and 3.1 versions, the TCP/IP Configuration view in a 
platform connection or in PlatformServices allow entry of any number of DNS 
servers.  However, in QNX-based JACEs such as JACE-2, -4, and -5 series, the 
QNX OS supports a maximum of 3 DNS servers.

In AX version 3.2, the number of DNS servers for Win32 hosts will be limited 
to two, and for QNX hosts the limit is three.

As a workaround, do not enter more than 3 DNS servers in a QNX-based JACE's
TCP/IP configuration--note that any more entries are simply ignored.

*** 25.1:8131  Station Copier sometimes throws null pointer exception ***
  Record Type:  Bug
  Resolved In:  3.1.10; 3.0.101
Version 3.0.100 and earlier of the Station Copier view will throw a 
null pointer exception when loading, if its initial directory's location is 
stored in a Workbench option, and the directory specified in that option
does not exist.  This prevents the Station Copier from loading.

This has been corrected in builds 3.0.101 and 3.1.0 and later of the Station
Copier.

To work around this problem in uncorrected versions, users may delete the 
file that stores the option:
{system home}users/username/options/platDaemon-StationCopier.options

*** 25.1:8358  Stream to file OK button greyed out ***
  Record Type:  Enhancement
  Resolved In:  3.1.16
In AX 3.1 build 3.1.16, the "Stream To File" dialog in the platform Station
Director has been improved for usability.  The file type dropdown has been
removed, and the extension ".txt" will be assumed for the capture file name
if you enter a filename without an extension.

*** 25.1:8402  Dist File Installer on QNX-based JACE could fail due to invalid delete request ***
  Record Type:  Bug
  Resolved In:  3.1.17
In AX version 3.0 and 3.1 builds prior to 3.1.17, installing a dist file in
a QNX-based JACE using the Distribution File Installer could fail under 
some circumstances, displaying the following in the stack trace:

javax.baja.sys.LocalizableRuntimeException: File transfer commit failed: FileStore: error deleting 'filename'

This problem has been resolved in build 3.1.17.   To work around the problem
in earlier builds, you can use the platform File Transfer Client to explicitly
delete the files identified in the stack trace, and then retry the dist file 
installation.

*** 25.1:8488  Station Copier fails to install station from one platform type to another. ***
  Record Type:  Bug
  Resolved In:  3.1.21
In AX-3.0 builds and AX-3.1 beta builds prior to 3.1.21, the Station Copier
and Commissioning Wizard allow the ^alarm directory to be included with
files that are part of a station copy.  It was found that this caused the
station copy to fail if the source station was originally a different
platform type than the target platform.  For example, copying a station
originally in a QNX-based JACE to a Win32-based JACE.  This happens because
the alarm database formats for QNX and Win32 are different and incompatible.

In AX-3.1 build 3.1.21, the Station Copier and Commissioning Wizard have
been updated to disallow inclusion of the ^alarm directory, to avoid this
compatiblity problem.

As a workaround for this problem when using earlier builds, in a station
copy select the "Copy files from selected directories" option, and uncheck
the "alarm" directory. This will allow the station copy to succeed.

*** 25.1:8950  3.0 to 3.1 upgrades fail with "file open '/niagara/bin/libplatdialup.so' failed" message ***
  Record Type:  Bug
  Resolved In:  3.0.103
When using the Commissioning Wizard to upgrade a AX 3.0 JACE (running build 3.0.102
or earlier) to AX 3.1, the upgrade process sometimes fails with an error:

Wrote "/niagara/bin/libplataccess.so".
javax.baja.sys.LocalizableRuntimeException: File transfer commit failed: FileStore: file open '/niagara/bin/libplatdialup.so' failed
 Resource busy
 at com.tridium.platform.daemon.DaemonFileUtil.sendCommit(DaemonFileUtil.java:696)
 at com.tridium.platform.daemon.DaemonFileUtil.transfer(DaemonFileUtil.java:529)
 at com.tridium.install.InstallManifest.commit(InstallManifest.java:747)
 at com.tridium.install.InstallManifest.commit(InstallManifest.java:644)
 at com.tridium.platDaemon.ui.commissioningwizard.DistStep$InstallDistPane.run(DistStep.java:699)
 at java.lang.Thread.run(Unknown Source)

This problem was fixed in 3.0.103--meaning any AX 3.0 JACE running build 3.0.103
or later will not have this problem when upgraded to AX 3.1.

To avoid this problem when upgrading an AX 3.0 JACE running 3.0.102 or earlier
directly to AX 3.1, you can first do the following:

1) From the Station Director view, disable station Auto-Start on the JACE.
2) Reboot the JACE.
3) Perform the upgrade.
4) Re-enable station Auto-Start, and then start the station.

Or, if you encounter this problem, simply reinstalling the AX 3.1 upgrade 
will succeed.

*** 25.1:9311  Software Manager's "Import software from directory" corrupts original files ***
  Record Type:  Bug
  Resolved In:  3.1.30; 3.0.105
In versions 3.0.104 and earlier of AX-3.0, and in versions 3.1.29 and earlier
of AX-3.1, a bug exists in the Software Manager's "import from directory"
function.   When this function is used, files in the source directory that
are *not* Niagara module or distribution files are truncated to zero length.

This bug has been fixed in AX-3.0 versions 3.0.105 and later and AX-3.1 
versions 3.1.30 and later.

Customers should not use Software Manager's "import from directory" function 
in earlier (uncorrected) versions of the software.  Those customers wishing to
import multiple files into their software database should use the !sw/inbox
directory as described in the "About your software database" section of the
NiagaraAX Platform Guide (p. 33).

#########################################################################
26  platDdns
#########################################################################

=========================================================================
26.1  Fixed
=========================================================================

*** 26.1:7866  TZO provider support in DDNS ***
  Record Type:  Function
  Resolved In:  3.1.5
DDNS with NiagaraAX can be used with TZO as the provider. (See issue 7867
about DDNS Functionality). A DDNS account with TZO can be created at 
http://www.tzo.com. Once created, there are three pieces of information 
required in the Provider section of the "Ddns Configuration" platform view
of the host:

Key    - provided by TZO after account creation
Email  - email address associated with the TZO account
Domain - the domain name associated with the TZO account


*** 26.1:7867  DDNS Functionality ***
  Record Type:  Function
  Resolved In:  3.1.5
In NiagaraAX 3.1, DDNS functionality has been added for all platforms.  DDNS 
allows DNS IP addresses to be dynamically updated. Typically these are DHCP 
addresses (internet/intranet) or dialup addresses.

A new "Ddns Configuration" platform view supports configuration, accessed using
Workbench and a platform connection to the host (as with other platform views).
       
There are three core configuration items for using DDNS:       

Provider - Select from the list of supported providers, the provider you are using.

Mode - Select the operational mode of DDNS. Choices are:

  Disabled - DDNS functionality is completely disabled
  Internet - grabs the IP address assigned to the adapter specified below
  Intranet - grab the IP address as seen when connected to the provider (not all 
             providers will support this)
  Dialup   - use the IP address assigned once a dialup connection has been established

Adapter - If using internet mode, select the adapter to interrogate for an IP address

#########################################################################
27  platDialup
#########################################################################

=========================================================================
27.1  Fixed
=========================================================================

*** 27.1:7005  Dialup Daemon not dialing out after change to Min. Disconnect Time ***
  Record Type:  Bug
  Resolved In:  3.0.89
In a JACE configured for captive network, changing its Min. Disconnect Time
could cause the dialup daemon to crash after the daemon restarted.  This bug
was due to an unitialized variable, and was corrected in 3.0.89.

*** 27.1:7009  Dialup attempting to connect before min disconnect time is expired ***
  Record Type:  Bug
  Resolved In:  3.0.89
A JACE configured for captive network would reach the end of its Max. Connect
Time and then immediately attempt to redial, ignoring its Min. Disconnect Time
(to allow for incoming calls).  This was fixed starting in build 3.0.89.

*** 27.1:7063  Dialup connection ends before job service can finish ***
  Record Type:  Bug
  Resolved In:  3.0.90
There was a bug in the handling of the routing table after an outbound ppp connection had
been established. The side effect of this bug was that if an inbound call used the same ip
address for the caller, the ip routing would get confused. In 3.0.90 a fix was made to correct
this problem. The routing table is now cleaned up after the call has terminated.

*** 27.1:7069  Max disconnect time was used even when connected through Workbench ***
  Record Type:  Bug
  Resolved In:  3.0.90
When attempting to upgrade a JACE over a dialup connection, the dialup 
connection was dropped before the upgrade completed.  This turned out to be 
a bug where new Workbench connections were assigned a min and max connect time.
Workbench connections are not supposed to have these limitations.  This issue 
was corrected starting in build 3.0.90.

*** 27.1:7072  Start button remained enabled when restarting dialup daemon ***
  Record Type:  Bug
  Resolved In:  3.0.90
After restarting the dialup daemon, the Start button remained enabled and the 
status message said the daemon was idle. This was misleading.  Starting in
build 3.0.90, a fix was made such that when the dialup daemon is restarted, the
status message states the daemon is restarting, and the Start button becomes 
disabled.

*** 27.1:7128  Java console error "unable load platdialup" accessing PlatformServices using web Workbench ***
  Record Type:  Bug
  Resolved In:  3.0.91
When using Workbench in browser (IE), an error appeared in Java console when
accessing a station's PlatformServices.  Error was "Unable load platdialup 
native" or similar. This error did not appear when accessing station using 
Workbench. A bug was found that caused Workbench to try and load a connection 
to dialup daemon when viewing the Dialup Platform Service. This issue was fixed 
starting in build 3.0.91.

*** 27.1:7623  JACE-2 modem option (NPB-MDM) ignored DTR drop duration ***
  Record Type:  Bug
  Resolved In:  3.0.98; 3.1.1
Testing of the JACE-2 NPB-MDB option (Radicom modem) found a software function
ignoring the duration arg when dropping DTR.  As a result, the modem would not
hang up properly about 30% of the time.  It was found this problem did not
affect external modems, nor modem options for other JACE platforms.  This issue
was fixed in build 3.0.98.

*** 27.1:7958  Default route not set on dialup-connected JACE-2 (NPM) ***
  Record Type:  Bug
  Resolved In:  3.0.100; 3.1.6
A dialup connected JACE-2 would have PPP (point-to-point protocol) fail when
setting the default route (gateway), causing pings and other IP connections
from the outside to not get responses.  This bug was fixed in build 3.0.100
and 3.1.6.  Note this problem applies to "NPM" platforms (JACE-2 series, any
similar), but not to other JACE platforms such as JACE-4 or JACE-5 series.

*** 27.1:8113  Default route on dialup-connected host set to local instead of remote ***
  Record Type:  Bug
  Resolved In:  3.0.101; 3.1.9
A previous bug fix (7958) for a pppd default route issue was incorrectly being 
set to the local address instead of the remote address. With this fix, the 
correct address is now being used.

*** 27.1:8114  Fix creation of dialup-related files: pap-secrets, chap-secrets ***
  Record Type:  Bug
  Resolved In:  3.0.101; 3.1.9
A couple of files used by dialup were being incorrectly created. This would
cause dialup to fail when establishing the ppp (point-to-point protocol)
connection.  This has been fixed.

*** 27.1:8120  Dialup connection to QNX-based JACE failed during station startup ***
  Record Type:  Bug
  Resolved In:  QNX-1.44; QNX-2.0.8
A bug was found in the QNX ppp driver that prevented a successful connection
while a station in a QNX-based JACE was still starting. This was a minor bug,
because the connection would succeed on a retry. However, because of the delay
this was less desirable. QNX issued a patch which resolves the problem, and it
is included in JACE dist files starting in 3.0.101 and 3.1.13 (QNX-1.44 and
QNX-2.0.8).

*** 27.1:8240  Multiple init string support added in QNX-based JACE dialup configuration ***
  Record Type:  Enhancement
  Resolved In:  3.1.13
Starting in 3.1.13, support was added for entering multiple modem init strings
in the (platform) Dialup Configuration of a QNX-based JACE.  This can be useful
in GPRS scenarios, where a more complicated initializaton sequence may be required.

In addition, a "Select Init String Template" feature simplifies entering init 
strings for core-supported modems, including US Robotics, Cermetek, Radicom, 
Netcom Roadster, and Siemens MC75.

*** 27.1:8241  JACE-2 series dialup configuration made "GPRS friendly" ***
  Record Type:  Enhancement
  Resolved In:  3.1.13
If a JACE-2 series (NPM) type controller has a GPRS (wireless) module installed
and being used, platform access of its "Dialup Configuration" automatically 
disables configuraton of properties like Baud Rate and Port.  This allows the 
dialup daemon to use the GPRS module properly.

*** 27.1:8953  Add modem support for additional COM ports on JACE-2 ***
  Record Type:  Enhancement
  Resolved In:  3.0.103; 3.1.25; 3.2.1
In order to support the release of the single port RS-232 option card (NPB-232)
for the JACE-2 series platform, the list of COM ports for configuring dialup 
modems in that platform has been increased to select from COM1 to COM5. This 
is typically configured in the "Dialup Configuration" platform view. 

Note that for a JACE-2, COM1 is reserved for either:
- the internal modem option card (NPB-MDM) if installed, or if not installed:
- the DB-9 connector on the JACE-2 base board.

COM2 is reserved for the onboard 3-position RS-485 port
(never a valid modem COM port choice).

Therefore, COM3 is the typical selection if a single NPB-232 option card is
used for connection to an external modem.  For more details, see the "NPB-232
Option Installation Sheet".

*** 27.1:9473  JACE-4/5 unable to start dialup connection ***
  Record Type:  Bug
  Resolved In:  3.0.107; 3.1.30; 3.2.8
It was discovered that on a JACE-4 or JACE-5 platform, when dialup attempted to mount
the npm-pppmgr.so library, it was only looking in /ffs0/bin, which is the location
in a JACE-2 (NPM) platform. This caused dialup to fail. 

Now when attempting to mount the npm-pppmgr.so library, dialup looks in both 
/proc/boot (JACE-4/5) and /ffs0/bin (JACE-2) locations.

*** 27.1:9613  Dialup modem would not hang up if connection was lost and then restored. ***
  Record Type:  Bug
  Resolved In:  3.1.31; 3.2.10
A bug was found in the way that dialup monitored the carrier detect line. A fix
has been made that now allows for dialup to correctly determine when carrier 
detected has dropped.

=========================================================================
27.2  Open
=========================================================================

*** 27.2:6642  Workbench cannot dial to platform or station ***
  Record Type:  Enhancement
  Resolved In:  
Dialup in NiagaraAX requires that the platform daemon (niagarad) be installed 
and dialup be enabled. This is different from Niagara r2, where you could 
initiate a dialup connection from JDE without having niagarad running.

*** 27.2:7038  History export does not check for captive networks's Min Disconnect Time ***
  Record Type:  Bug
  Resolved In:  
With the current release of dialup, outbound connections from the NiagaraNetwork
in a station are completely independent of connections initiated as part of 
captive network. Therefore, min disconnect times are not observed for the other
connection. 

For any JACE configured with captive network, to ensure that there is time 
allowed for incoming calls, it is recommended that you set each "Min disconnect 
time" (the captive network one *and* each NiagaraNetwork one) to be greater than
the sum of all "Max connect times", meaning all the max connect times added 
together (the captive network one and the NiagaraNetwork ones).

#########################################################################
28  platLon
#########################################################################

=========================================================================
28.1  Fixed
=========================================================================

*** 28.1:9244  Station fails to exit on shutdown if running LonWorks ***
  Record Type:  Bug
  Resolved In:  3.1.30
In 3.1.29, a race condition was introduced in the lon driver that could cause
the station to hang during shutdown.

This bug was fixed in platLon patch version 3.1.29.2 and will be included in
build 3.1.30 and later.

#########################################################################
29  platMstp
#########################################################################

=========================================================================
29.1  Fixed
=========================================================================

*** 29.1:7641  Bacnet MSTP driver reports "something's broken in mstpSendFrame" ***
  Record Type:  Bug
  Resolved In:  3.0.98
Under heavy CPU utilization, the Bacnet MSTP driver would sometimes print 
"something's broken in mstpSendFrame". This indicated a transmit queue overflow
due to the MSTP driver getting starved for CPU time by the station. Other 
symptoms could include loss of token on the MSTP network.                                

The priority of the MSTP driver was increased to prevent this from occurring.

#########################################################################
30  platPower
#########################################################################

=========================================================================
30.1  Fixed
=========================================================================

*** 30.1:7120  Battery/power return-to-normal alarms were not properly handled ***
  Record Type:  Bug
  Resolved In:  3.0.90
The PowerMonitorService under PlatformServices in a station running on a 
QNX-based JACE generates two types of alarms: battery test bad/good, and 
main power lost/restored. It was found that because both types of alarms 
used the PowerMonitorService as the alarm "source", that an event of one
type could clear an existing alarm of the other type. For example, a power
restored alarm could clear a battery test failed alarm, or a battery test
passed alarm could clear a power lost alarm.

This was fixed starting in build 3.0.90.  Battery and power alarms are now
segregated by source type (e.g. "PowerMonitorService/powerAlarmProxy").

*** 30.1:7504  JACE 4/5 may not shutdown properly if primary power lost ***
  Record Type:  Bug
  Resolved In:  3.0.95
If a battery test occurs during a JACE-4/5's power lost shutdown delay, the 
JACE would fail to shutdown. It would continue running off of battery power 
until primary power was restored or the battery discharged fully.

This bug was fixed in build 3.0.95, where the platPower code was modifed to 
skip the battery test if primary power is not present.

For JACEs running earlier builds, note the battery test rate is once every 15 
minutes. The default shutdown delay is 1 minute, so there is 1 minute window 
every 15 minutes when this problem could occur.

*** 30.1:7881  JACE power alarms display incorrect sourceState in ConsoleRecipient ***
  Record Type:  Bug
  Resolved In:  3.1.6
In QNX-based JACES (JACE-2, -4, -5), the fault state for power-related alarms, 
that is for battery good/bad and primary power lost/restored, was not persisted
across a reboot.  After a reboot, the station's PowerMonitorService would not
issue a "return to normal", thus the station's AlarmConsole would show a stuck
sourceState of "fault".

This was fixed starting in build 3.1.6, where the fault state is now persisted 
across reboots, and the "return to normal" is issued.

*** 30.1:8582  Increase maximum shutdown delay from 10 seconds to 30 seconds on JACE-2 ***
  Record Type:  Enhancement
  Resolved In:  3.1.21; 3.0.102
On the JACE-2 platform, the maximum shutdown delay (time between loss of
primary power and JACE shutdown) has been increased from 10 seconds to 30
seconds.  In scenarios where automatic switchover to backup generators occurs, 
this might allow continuous operation of the station.

=========================================================================
30.2  Open
=========================================================================

*** 30.2:9157  JACE-2 PowerMonitorService property sheet shows incorrect "Shutdown Delay" entry range ***
  Record Type:  Bug
  Resolved In:  
The maximum shutdown delay for a JACE-2 using a NIMH battery is 30 seconds.  
However, the property sheet of the PowerMonitorService (under a station's 
PlatformServices) shows a range of "0ms - 15mins" for this property, which
is actually the time range for the J4xx product.

If a user attempts to set the shutdown delay to a value greater than 30 seconds, 
the message "Invalid shutdown delay detected, setting to default" is printed to
standard output, and the value is limited to 30 seconds.

Also, if a user attempts to set the shutdown delay to a value greater than 15 minutes,
an exception is displayed in Workbench and the value entered is not saved. The user
must re-enter a valid time range between 0 - 30 seconds before being allowed to save.

"CannotSaveException: Cannot save property "Shutdown Delay".  15mins 1sec > 15mins [0ms - 15mins]"

These issues may be fixed in some future build.

#########################################################################
31  platSerial
#########################################################################

=========================================================================
31.1  Fixed
=========================================================================

*** 31.1:8502  Removal of IBM low-level serial driver support for Win32 platforms ***
  Record Type:  Function
  Resolved In:  3.1.19
Due to licensing issues, the mark and space parity support provided by the IBM
low-level Java comm serial driver has been removed from Win32-based platforms.
This driver was included only in NiagaraAX builds 3.1.16, 3.1.17, and 3.1.18.

If you installed one of these builds, you need to delete the following file:

 jre/lib/javax.comm.properties
  All 3.0.x builds (and 3.1.15 and earlier builds) are not affected, and builds
3.1.19 and later now use the prior Sun low-level Java comm serial driver.

#########################################################################
32  platSysmon
#########################################################################

=========================================================================
32.1  Fixed
=========================================================================

*** 32.1:7826  HardwareMonitorService in JACE-NXS station mishandled alarms ***
  Record Type:  Bug
  Resolved In:  3.1.4
Previously, out-of-range CPU and Board temperatures would report to the same alarm
in a JACE-NXS's HardwareMonitorService (under station's PlatformServices), and 
there were related alarm routing and acking issues.  This was fixed by providing
separate alarm support containers under the HardwareMonitorService. In addition,
alarms are now persisted across a reboot to avoid duplicate alarms on restart.

*** 32.1:7896  Hardware monitor (sysmon) alarms in Win32-based JACEs incorrect across reboot ***
  Record Type:  Bug
  Resolved In:  3.1.6
This problem was common to the HardwareMonitorService (platSysmon) in any of 
the Win32-based JACEs, that is platSysmonNp, platSysmonNx, platSysmonNxs

Following a host reboot, sysmon-related alarms (CPU temp, Voltage) did not 
necessarily show the proper "sourceState" in the Console Recipient, because the
station's PlatformServices did not persist the fault state, and did not issue a 
"return to normal". This lead to the source state getting stuck in "fault".

Starting in 3.1.6, this was fixed. The fault state is now persisted across a
reboot, with the return to normal issued as needed.  Note this problem was
similar to the power-related platform alarm issue in QNX-based JACEs (issue 7881).


#########################################################################
33  portalAPI
#########################################################################

=========================================================================
33.1  Fixed
=========================================================================

*** 33.1:9270  Add version to brand.properties submit keys. ***
  Record Type:  Enhancement
  Resolved In:  3.1.30; 3.2.4
(Developer Release Note)
brand.properties may include a list of properties that specify
the information that a user should provide when requesting
a license via email.  The properties are used to populate
a dialog that is displayed when a license request is initiated
and no Internet connection is available.

The property definitions take the following form:

submit.x.key=label

where "x" specifies the position in the list, "key" is the
string id of the property, and "label" is the display label
for the field.

If key=hostId, the dialog is prefilled with the host ID of
the computer that is running the workbench.  With this
enhancement, if key=version, the dialog is prefilled with
the version of the baja module.


#########################################################################
34  program
#########################################################################

=========================================================================
34.1  Fixed
=========================================================================

*** 34.1:7511  Add CsvEmailSender template to program palette ***
  Record Type:  Enhancement
  Resolved In:  3.0.95
The program palette includes a new template program which provides
sample code for:                                                  
  - Running a BQL query which returns an ITable
  - Generating a CSV file for the query using ICsvExporter
  - Sending the CSV file as an email attachment            

This sample code illustrates
  - Programatically resolving a BOrd
  - Using the javax.baja.file.Exporter API
  - Programmatically sending an email via the EmailService


#########################################################################
35  pxEditor
#########################################################################

=========================================================================
35.1  Open
=========================================================================

*** 35.1:5982  Px objects can be added in the editor, yet module is not installed ***
  Record Type:  Bug
  Resolved In:  
You can add objects using the Px Editor even though the module for those objects 
is not installed on the opened remote host.  For example, a remote JACE that 
does not have kitPx.jar installed will still allow GenericFieldEditor to be 
added using the Px Editor.
As a workaround, be aware of the installed modules on any JACE in which you
are engineering Px views.

*** 35.1:6717  Canvas pane under canvas pane causes problems in Px Editor ***
  Record Type:  Bug
  Resolved In:  
Putting a canvas pane under a canvas pane can cause problems in the Px Editor.
Examples include pasted labels are created at maximum size, labels do not move using 
left/right arrow keys, and improper rendering of objects while moving.

As an alternative, use a grid pane (or an edge pane) under canvas panes.  

=========================================================================
35.2  Fixed
=========================================================================

*** 35.2:6808  BoundLabel Text to Icon align problem ***
  Record Type:  Bug
  Resolved In:  3.2.5
When changing the alignment of "Text to Icon" for a BoundLabel with an image
and some text, certain instances are not displayed correctly. For example,
if you change the "Text to Icon Align" from "Left" to "Right", or "Top" to
"Bottom", the text will appear incorrectly in front of the image. As a 
workaround, save the view, reload it, and the label should display correctly.

*** 35.2:6815  Error checking problem when entering Px file name ***
  Record Type:  Bug
  Resolved In:  3.0.95
When creating a new Px view, you get an exception if you name the Px File
the same as a directory, instead of seeing an error in the New Px View dialog.
Please do not enter directory names as Px File names.

Beginning in build 3.0.95, the user will get a dialog indicating that the
filename they entered was illegal.

*** 35.2:7030  Saving canvas pane backround image as null causes problems ***
  Record Type:  Bug
  Resolved In:  3.0.91
In the PxEditor, attempting to save the CanvasPane's background
property as an image with "null" as the location will cause graphical
problems when editing the graphic.  This can be avoided by making
sure an actual image is selected rather than "null", and fixed by 
either changing "null" to a valid image or changing the background
type.  

#########################################################################
36  rdb
#########################################################################

=========================================================================
36.1  Fixed
=========================================================================

*** 36.1:7512  Duplicate history records are sometimes exported ***
  Record Type:  Bug
  Resolved In:  3.0.106; 3.1.30; 3.2.9
When exporting a history, sometimes duplicate records were exported. 
A timeQuery now queries records ten milliseconds past the last timestamp.

*** 36.1:8040  Add ability to import histories from rdb ***
  Record Type:  Enhancement
  Resolved In:  3.1.7
Starting in build 3.1.7, the ability to import histories from a relational 
database table was implemented. This feature was added to the rdb module. 
Now, in addition to the ability to export histories to rdb, you can import 
histories from rdb.  A new view on the RdbmsHistoryDeviceExt object is called
"Rdbms History Import Manager".  This manager view uses the connection 
established in the parent Rdbms device to discover a list of tables in the 
rdb that are available for import.  If you select and create an import 
descriptor for one, you will be prompted to define a mapping between the rdb 
table's columns and the history's columns.

An rdb table can only be imported if it has a column that corresponds to a 
history's timestamp and value column.  You can also optionally import the status
column if the rdb table supports it.  Once the RdbmsHistoryImport descriptors 
are created and initialized, they will work just as other history import 
descriptors to periodically (or manually) import data into a history from a 
rdb table.

*** 36.1:8093  Improve Rdb Import Descriptors for specifying timezone and units ***
  Record Type:  Enhancement
  Resolved In:  3.1.9; 3.1.21
Regarding the new importing feature from rdb, an easier way to allow the user
to specify the timezone and units for the imported history was needed on the
rdb import descriptor objects. So starting in 3.1.9, the Rdbms History Import
Manager view was enhanced so that the user can edit these timezone and unit
attributes on the import descriptors. In turn, the information in the import
descriptor is used as the source for the history generated, so this information
will be passed as meta data to the history when imported.

*** 36.1:8457  Add collection 'Interval' property for history config override ***
  Record Type:  Enhancement
  Resolved In:  3.1.18
When using the Rdbms History Import Manager view to create import descriptors
for rdb tables from which to import histories, there is a new property that 
can be used to specify the collection interval of the imported history.  When 
creating an Rdbms History Import descriptor (i.e. from the discovered rdb tables), 
the edit dialog will now display an 'Interval' property.  Users should always 
set this property to the collection interval of the original data being imported.
If it is not known or irregular, you can specify the collection interval as 
"irregular".

This collection 'Interval' property is important because it lets users specify 
what they think the collection interval should be for the imported history, and 
then if they want to start using Niagara objects to append data to the imported
history, they can configure their history extension to use the same collection 
interval, thus avoiding an incompatible configuration difference which results
in a split history.

*** 36.1:8510  Added support for importing SQL tables with column names containing spaces ***
  Record Type:  Bug
  Resolved In:  3.1.19
For the Rdbms import descriptors, it was discovered that they could not handle 
importing (or even discovering) SQL tables containing space characters in a 
column name.  This bug was fixed; now SQL tables fitting this description
can be discovered and imported.

*** 36.1:8511  In Rdbms History Import Manager, the column editors don't save ***
  Record Type:  Bug
  Resolved In:  3.1.19
It was discovered that the 'Timestamp Column', 'Value Column', and 'Status 
Column' property field editors weren't saving when changed using the Edit 
feature of the Rdbms History Import Manager view.  These same corresponding 
field editors would work when changed from the property sheet view, so the 
problem was limited to the manager edit column's save process.  This bug has 
been fixed; now changes to these properties will correctly save from this view.

*** 36.1:8512  Failure notification when duplicate timestamps detected in imported data ***
  Record Type:  Enhancement
  Resolved In:  3.1.19
During the history import process, it is important to fail fast when detecting 
a duplicate timestamp condition in the data being imported (duplicate timestamps
are not allowed in histories).  Previously, if a duplicate timestamp was 
discovered in the data being imported, there was not a useful indication given 
to the user to explain which timestamp was duplicated, so it was difficult for 
the user to take the appropriate actions to fix the raw data to import.  This 
has been improved, such that an error message indicating the duplicate timestamp 
is displayed in the 'Fault Cause' property of the import descriptor.

*** 36.1:8925  Allow configuration of the Rdbms Worker thread's max queue size ***
  Record Type:  Enhancement
  Resolved In:  3.1.25; 3.2.1
The RdbmsWorker component was enhanced to allow configuration of the max queue 
size supported for Rdbms actions (i.e. exports, imports).  Now if you look 
under the SqlServerDatabase or OracleDatabase component, and look at the 
property sheet for its Worker property, you will see the Max Queue Size is 
exposed for user configuration.  The default queue size is 1000 (the same size
previously hard-coded and unavailable for adjustment).

*** 36.1:9119  Rdb Import discovery could fail to find all tables ***
  Record Type:  Bug
  Resolved In:  3.1.28; 3.2.3
During the import discovery process for a database with a large number of tables,
it was discovered that not all of the tables were being found.  The reason that
some tables were being left out was because of the following error (example for 
an Oracle database):

java.sql.SQLException: ORA-01000: maximum open cursors exceeded
   at oracle.jdbc.dbaccess.DBError.throwSqlException(DBError.java:134)
   at oracle.jdbc.ttc7.TTIoer.processError(TTIoer.java:289)
   at oracle.jdbc.ttc7.Oopen.receive(Oopen.java:120)
   at oracle.jdbc.ttc7.TTC7Protocol.open(TTC7Protocol.java:586)
   at oracle.jdbc.driver.OracleStatement.<init>(OracleStatement.java:385)
   at oracle.jdbc.driver.OracleStatement.<init>(OracleStatement.java:413)
   at oracle.jdbc.driver.OraclePreparedStatement.<init>(OraclePreparedStatement.java:119)
   at oracle.jdbc.driver.OraclePreparedStatement.<init>(OraclePreparedStatement.java:92)
   at oracle.jdbc.driver.OracleConnection.privatePrepareStatement(OracleConnection.java:950)
   at oracle.jdbc.driver.OracleConnection.prepareStatement(OracleConnection.java:802)
   at oracle.jdbc.OracleDatabaseMetaData.getColumns(OracleDatabaseMetaData.java:2552)
   at com.tridium.rdb.BRdbmsDiscoverTablesJob.run(BRdbmsDiscoverTablesJob.java:183)
   at javax.baja.job.BSimpleJob$JobThread.run(BSimpleJob.java:83)
   
This error indicated that there were Java ResultSet and/or PreparedStatement 
instances that aren't being closed appropriately when no longer needed (thus 
it was running out of capacity).  The simple fix was to make sure these 
instances got the close() method called where appropriate.

It should be fixed now, so that all tables will be discovered correctly.

#########################################################################
37  rdbSqlServer
#########################################################################

=========================================================================
37.1  Fixed
=========================================================================

*** 37.1:8617  Could not export histories that contained NaN as a value ***
  Record Type:  Bug
  Resolved In:  3.1.25; 3.2.1
In the past, when trying to export a numeric history to Rdbms, if a NaN (not a
number) value was encountered, the export would fail, and the Rdbms history
export descriptor would go into fault.  

This behavior has been fixed, such that if a NaN value is encountered during 
the export, it will insert an SQL NULL value in its position.

#########################################################################
38  report
#########################################################################

=========================================================================
38.1  Fixed
=========================================================================

*** 38.1:9650  Cannot export PxView ***
  Record Type:  Bug
  Resolved In:  3.2.11
A bug was introduced with exporting to PDF from a Px page.  The bug has been fixed
and exporting to PDF works correctly again.

*** 38.1:9824  Grid Editor empty after switching to Grid Pane or Grid Label Pane. ***
  Record Type:  Bug
  Resolved In:  3.2.14
Fixed the 'Add Row' toolbar command to automatically add that
row as the template row if the template row hasn't yet been
defined.  This fixes a bug where editing the Grid caused the
Grid not to work and not to save.

#########################################################################
39  schedule
#########################################################################

=========================================================================
39.1  Fixed
=========================================================================

*** 39.1:6879  Date Range does not take year into account ***
  Record Type:  Bug
  Resolved In:  3.0.86
Date Range schedules were not taking the year into account when determining
if the start was before the end.  The user would be prevented from adding
special events with a dialog that said "Start cannot be after end."

*** 39.1:6957  Schedule views  need Save and Refresh buttons ***
  Record Type:  Enhancement
  Resolved In:  3.0.87
Save and Refresh buttons were needed on all schedule views because WbBasic
profile has no toolbar, and thus, no way to save or refresh the plugin.

*** 39.1:7041  Weekly schedules did not implement corresponding interface ***
  Record Type:  Enhancement
  Resolved In:  3.0.89
The weekly schedules (BooleanSchedule, EnumSchedule and NumericSchedule) did not 
implement their corresponding interfaces. This kept them from being bound to 
widgets on Px pages. This was enhanced starting in build 3.0.89. 

*** 39.1:7465  Schedule's special event editor allowed invalid day of month selection ***
  Record Type:  Bug
  Resolved In:  3.0.95
The special events editor of a Schedule allowed an invalid day of month selection
from the drop-down list, for example, September 31 (only 30 days in September).
This issue was fixed starting in build 3.0.95.

*** 39.1:7576  Schedule modifications require user to have admin permissions ***
  Record Type:  Bug
  Resolved In:  3.1.2
In all 3.0.x releases, modifications to schedules such as adding, changing,
or deleting events require the user to have admin permissions to successfully
make changes.  An operator-level user "appears" to have editing capability, 
however upon Save, a cryptic "Cannot save plugin" popup error message appears,
and an exception is generated.

For all 3.0.x releases, the workaround to allow operator-level users to make
schedule changes is to add (check) the Operator config flag for all properties
of a schedule.  You can do this from the schedule's Slot Sheet (right-click 
property, select Config Flags, check Operator). Actions do not need to be set.

This was corrected in 3.1.2.

*** 39.1:7656  In slot of the CalendarSchedule was read only (unlinkable) ***
  Record Type:  Bug
  Resolved In:  3.1.2; 3.0.99
The input (In) slot of a CalendarSchedule was set to read-only, and thus did
support a link. This was corrected starting in build 3.0.99.

*** 39.1:7658  Adding trigger time not always adding correctly on TriggerSchedule ***
  Record Type:  Bug
  Resolved In:  3.0.100; 3.1.5
In cases where the Workbench client was in a different time zone than the 
connected station, it was found that entered trigger times in a TriggerSchedule
would display differently. Time editors for adding trigger times in the 
Scheduler were using the time zone of the station. However, the list of 
configured trigger times was using the time zone of the Workbench client. 
Therefore, it appeared that adding one time resulted in a different time being 
added to the schedule. This was fixed--now both user interface components use 
the station time zone.

*** 39.1:7856  CurrentDaySummary doesn't update the first time displayed on a px page ***
  Record Type:  Bug
  Resolved In:  3.1.7
The CurrentDaySummary of a schedule, when displayed on a Px page, did not
update when first displayed. This was fixed in build 3.1.7 -- CurrentDaySummary
now correctly subscribes to the schedule data the first time it is displayed.

*** 39.1:7990  TriggerSchedules consumed excessive CPU ***
  Record Type:  Enhancement
  Resolved In:  3.1.7; 3.0.100
Trigger schedules could consume massive amounts of CPU time if the schedule was
configured in such a way that it would rarely fire.  This in turn would hold
up the calculation of next event for other schedules in the station, since
they all share the same thread for such calculations.  This was fixed by an
optimization in how Trigger schedules calculate their next event.

*** 39.1:8026  HX View errors on Special Event page of schedule ***
  Record Type:  Bug
  Resolved In:  3.1.15
The Hx SpecialEvents editor for a schedule was updated to not display the 
Edit and Delete commands when no special events exist in that schedule.  This 
prevents the "Page cannot be displayed" error message that was previously
displayed when an Hx user selected these commands.

*** 39.1:8050  Default Output edit of schedule yielded bogus warning ***
  Record Type:  Bug
  Resolved In:  3.1.9
A blank weekly schedule (for example, BooleanSchedule), upon edit to have a
non-standard Default Output (for example, "true" vs. "false"), would issue
a popup warning saying "No change of value detected".  This occurred because
schedules consume a lot of CPU when attempting to calculate their next change
of value, and the original design did not anticipate this use case (found to
be common in certain applications).

Starting in 3.1.9, this warning dialog no longer appears. Further, since other
applications might miss the original design intention, all schedules components
have a *new property* "scanLimit", allowing the user to throttle how far into the
future a schedule will search for a change of value.  The default Scan Limit for
a schedule copied from the schedules palette is 2160 hours (90 days).

*** 39.1:8075  Subordinate schedules went "down" if connection to Supervisor lost ***
  Record Type:  Bug
  Resolved In:  3.1.9; 3.0.101
When the connection to a supervisory station was lost, subordinate schedules went
into fault and down status. This should not have happened, because subordinate
schedules are autonomous and do not require a connection to the Supervisor to
operate properly.  This was fixed in build 3.1.9.  Note that the ScheduleImportExt 
extension will continue to carry the fault and down status, and the fault reason.

*** 39.1:8365  Basic Wb Web Profile did not show Scheduler view ***
  Record Type:  Bug
  Resolved In:  3.1.16
In 3.1 builds prior to 3.1.16, a Web Workbench user with a Basic Wb Web Profile
cannot access the Scheduler view for schedule components, regardless of user
permissions.  Only the property sheet displays. This problem does not occur in 
3.0 builds, and was fixed in 3.1.16.

*** 39.1:9414  Calendar Schedule causes 100% CPU usage ***
  Record Type:  Enhancement
  Resolved In:  3.2.8; 3.1.30; 3.0.106.1
A bug in calculating timezones (see Issue 8932) caused schedules 
to ramp to 100 cpu usage. This occurred when a schedule had checked ahead 
for its next change in value and the next change overlapped with a switch to 
daylight savings time.

Effected builds are 3.0.99.2, 3.0.104,
3.0.105, 3.0.106, 3.1.29.2, 3.2.3 - 3.2.7

*** 39.1:10942  Scheduler View Permissions ***
  Record Type:  Enhancement
  Resolved In:  3.3.16
The Scheduler View is now accessible with just readonly access. This includes
access to the summary tab. Additionally, if the user has readonly access to the
BBooleanSchedule, but write access to the specialEvents, the special events tab
will become accessible while the rest of the tabs remain readonly. 

Setup:

Unhide the schedule component slot on the schedule. Expand the children of the
schedule object and set the category of the specialEvents to a different value
than the schedule. This allows the user to be setup with readOnly access to 
the schedule but readWrite access to the specialEvents.

#########################################################################
40  timesync
#########################################################################

=========================================================================
40.1  Fixed
=========================================================================

*** 40.1:8886  Time change by TimeSyncService should update audit log ***
  Record Type:  Enhancement
  Resolved In:  3.1.25; 3.2.1
Whenever a station's TimeSyncService changes the system time, it adds an entry
in the station's AuditHistory (providing it has the AuditHistoryService).

*** 40.1:9056  Timesync poll shouldn't occur on engine thread ***
  Record Type:  Bug
  Resolved In:  3.2.2; 3.0.104; 3.1.28
Improperly configured DNS servers (or DNS servers that take too long to
respond) could cause the DNS lookup required by the timesync service to
timeout, preventing the engine thread from running. This could lead to engine
watchdog timeouts and/or JACE reboots. Timesync polling is now done on a
special thread.

#########################################################################
41  wbutil
#########################################################################

=========================================================================
41.1  Fixed
=========================================================================

*** 41.1:7126  NullPointerException loading the Category Browser ***
  Record Type:  Bug
  Resolved In:  3.0.91
When running Workbench via a browser, accessing a station's CategoryBrowser
would result in a null pointer exception.  This bug was fixed in 3.0.91.

*** 41.1:7231  Double-click in PermissionsBrowser view caused overflow error ***
  Record Type:  Bug
  Resolved In:  3.0.91
In Web Workbench, when in the PermissionsBrowser view of the UserService, if 
you double-clicked on a container in the tree, a java.lang.StackOverflowError
exception was produced.  This was fixed starting in build 3.0.91.


*** 41.1:7734  Category Sheet view required refresh if making multiple saves ***
  Record Type:  Bug
  Resolved In:  3.1.3
Previously, when working in the CategorySheet of any component and you Saved,
no more changes could be made and saved until you first refreshed or changed
the view.  This problem was fixed in build 3.1.3. 

#########################################################################
42  web
#########################################################################

=========================================================================
42.1  Fixed
=========================================================================

*** 42.1:2967  Html pages with UTF-8 encoding were not served correctly ***
  Record Type:  Bug
  Resolved In:  3.0.77
Prior to build 3.0.77, HTML files served by the station using UTF-8 encoding
were not displayed correctly. This was fixed in build 3.0.77.  Now, HTML files 
using UTF-8, with or without initial byte order mark (BOM), or UTF-16 with BOM,
are now processed correctly.  The station's web server always outputs UTF-8.
Note that Hrefs in HTML and CSS must be a valid ord OR a relative file path.

*** 42.1:7150  Web server could pass inappropriate characters with JavaScript ***
  Record Type:  Bug
  Resolved In:  3.0.91
When Niagara is serving HTML, JavaScript, and CSS files from the web
server, it automatically performs translations on ords into the URI
which should be used by the browser.  There was a bug where certain
phrases in JavaScript were inappropriately translated such as the following
snippet of code:

  var event = window.srcElement.event; 
  var foo = "cool";  // gets converted to "/ord?file:cool"  
  
Starting in build 3.0.91 this issue was fixed.  


*** 42.1:7288  LoginServlet incorrectly redirected non-ord requests. ***
  Record Type:  Bug
  Resolved In:  3.0.92
The login servlet incorrectly assumed all requests were for ord based resources.
If someone was attempting to access a servlet, they would get a server 
exception after successful authentication (login), instead of the intended 
resource.

This issue was discovered in development of a servlet for the oBIX driver. 
Although currently there are not may servlets (apart from the login servlet) 
available, this issue would impact any that are developed.  This issue was 
fixed in build 3.0.92.

*** 42.1:7438  Browser Workbench access to QNX-based JACE did not auto convert units ***
  Record Type:  Bug
  Resolved In:  3.0.100; 3.1.2
Web Workbench (browser) access of any QNX-based JACE station did not perform 
auto unit-conversion, if configured in Tools > Options > General, or in the 
User's Facets slot. This problem does not occur when accessing a station on a
Win32 host.  This issue was fixed in build 3.0.100.

*** 42.1:7439  Hx access gives error "java.io.UnsupportedEncodingException: UTF-8" ***
  Record Type:  Bug
  Resolved In:  3.0.95
Users whose browsers were configured for UTF-8 character encoding would
receive server error "java.io.UnsupportedEncodingException: UTF-8" while
accessing Hx pages. This is because the client's requested character encoding 
was being passed directly to the constructor of the Java output writer, which
did not understand "UTF-8" (expecting the Java alias "UTF8" instead).  
This issue was fixed in build 3.0.95.

*** 42.1:7538  Invalid login redirect cookie ***
  Record Type:  Bug
  Resolved In:  3.0.96
If a user requested a resource using a path, for example "/obix/wsdl", and the 
request first required authentication, the user was not sent back to the 
resource after succesful login.  This happened because the cookie containing 
the original request uri didn't have it's path set to "/". In the example
request described ("/obix/wsdl"), the cookie containg this uri would only be
sent to subpaths of /obix.  This issue was fixed in build 3.0.96.

*** 42.1:7683  Browser logout would be ineffective due to undeleted cookie ***
  Record Type:  Bug
  Resolved In:  3.1.2; 3.0.99
In a logout, in some scenarios a station's web server would not correctly
remove the cookie in the client browser. Thus, the logout was ineffective. This
was found to occur if the client browser was in a different time zone than the 
Niagara host, where the client browser time was earlier than the Niagara time.

NOTE: A manual logout is invoked by: http://<stationIP>/logout
In addition, a timed "Auto Logoff" is available in a User's Web Profile.

In build 3.0.99, this was fixed by changing the "Cookie.setMaxAge(0)" mechanism
such that it always removes the cookie in the client browser, regardless of 
time offset with the station's web server. 

*** 42.1:7980  Microsoft IE ActiveX Activation ***
  Record Type:  Bug
  Resolved In:  3.0.100; 3.1.7
Microsoft has begun deploying their plug-in activation patch as an Windows XP update: 

  http://www.betanews.com/article/Microsoft_Rolls_Out_IE6_ActiveX_Change/1141233576
  http://msdn.microsoft.com/library/?url=/workshop/author/dhtml/overview/activating_activex.asp
  http://support.microsoft.com/kb/912945

Microsoft expects this update to deployed to the majority of Windows XP IE users in the 
next 4 to 6 months.  The basic summary is that to work around the Eolas patent, you have
to first click an applet before you can use it (every applet on every page).

Beginning in 3.0.100 and 3.1.7, this was corrected in NiagaraAX according to Microsoft's 
documented workaround:
http://msdn.microsoft.com/library/?url=/workshop/author/dhtml/overview/activating_activex.asp

Background: A previous Tech Tip on March 28, 2006 described this problem:
Microsoft delivered an update for Internet Explorer 6 that changes the way the browser
loads embedded ActiveX control. The modification was implemented in security
update described at http://support.microsoft.com/kb/912945, and has since been
rolled into cumulative security updates for Internet Explorer. Among other
things, this update affects Sun Java Virtual Machine applets from running,
until manually activated by the user. This meant that browser access of a
NiagaraAX station running the Web Workbench applet, or any Niagara R2 station
(GX pages, chart or schedule applets), required the user to constantly "enable"
(click) to view and interact with controls. 

On April 26, a subsequent Tech Tip was issued to advise you that Microsoft has 
released a new "compatibility patch," described at:
http://support.microsoft.com/?kbid=917425, that disables the behavior of the 912945 patch.
This "Internet Explorer ActiveX compatibility patch for Mshtml.dll" (917425) removes the 
need to activate the ActiveX controls.

Solution: For IE browser users, download and install this new compatibility
patch, found at http://support.microsoft.com/?kbid=917425. As mentioned in both
related Tech Tips, you can also use another browser instead of IE, such as
Mozilla Firefox, available at http://www.mozilla.com/ or Netscape, available at
http://browser.netscape.com/.

*** 42.1:7988  Long station username/passwords did not allow Web Workbench login ***
  Record Type:  Bug
  Resolved In:  3.1.7
Station Users that had a combination of a long Name and Password might not
allow browser login using Web Workbench, but would allow login using full
Workbench.  In Web Workbench, a "Cannot display page" message would be seen,
with Details showing a "java.long.ArrayIndexOutOfBoundsException" message.

This was fixed in build 3.1.7, where long username/password combinations 
that encrypt to a Base64 length greater than 80 now omit an extraneous
newline character.

*** 42.1:8044  Erroneous servlet registrations required station restart ***
  Record Type:  Bug
  Resolved In:  3.0.101; 3.1.7
WebServlets pasted into a station using Workbench would fail to correctly
register until the station was restarted. Error messages would say "Duplicate
servlet name:" followed by the servlet name. An example would be to paste an
ObixServer object (itself a servlet) into a 3.1 station, from the obixDriver
palette.  This bug was fixed in builds 3.0.101 and 3.1.7.

*** 42.1:8871  URI cookie needs to be deleted upon successful login ***
  Record Type:  Bug
  Resolved In:  3.2.2
When an unauthenticated user attempts to visit a page, the web server
redirects the user to the login page and sets a cookie with the URL
that the user was trying to navigate to.  Upon successful login, the
server redirects the user back to the page that was originally
requested.

The cookie is a session cookie, such that it is removed when the 
browser is closed.  However, it was not being removed after a successful
login.  As a result, if the user logged out and then logged back
in without restarting the browser, the web server would attempt to
redirect back to the page for the original URL.

If the second login was using an account that did not have access to the
original URL, an "Access Denied" message was displayed, even though that
user was successfully logged in.

*** 42.1:9065  Customizable login page using API web:javax.baja.web.BLoginTemplate ***
  Record Type:  Enhancement
  Resolved In:  3.2.2
(Developer Release Note)
The browser login page can be customized by creating a subclass of
web:javax.baja.web.BLoginTemplate.

A new "loginTemplate" property of type baja:TypeSpec has been added to
BWebService. To use a custom login template, the loginTemplate property must be
set to the custom login template type. If the loginTemplate property is set to
null, the default template is used.

The default template behaves exactly as it did prior to this change.

*** 42.1:9096  Enabled property in servlet did nothing. ***
  Record Type:  Bug
  Resolved In:  3.2.3; 3.1.28
The enabled property on all web servlets (for example, BObixServer) had no
effect when set to false. Now, when enabled is set to false, the server will
respond with an HTTP error code 410: Gone.

*** 42.1:9337  HTTP session ids should be random. ***
  Record Type:  Bug
  Resolved In:  3.2.14
The session ids generated by the Niagara web server were
sequential and therefore highly predictable.  The session
id generation algorithm has been changed to generate
random session ids.

*** 42.1:9369  Allow custom favicon for a station ***
  Record Type:  Enhancement
  Resolved In:  3.2.5
You can now customize the favicon by adding a dynamic slot
named 'favicon' of type baja:Ord onto your WebService.

See Wikipedia for information on favicon and supported formats:
http://en.wikipedia.org/wiki/Favicon

*** 42.1:10100  Nav tree collapses when view is selected in browser ***
  Record Type:  Bug
  Resolved In:  3.2.17; 3.3.1; 3.2.16.3
As a side effect of the issue 9477 enhancement, when using Workbench in a
web browser, if you navigated in the side bar tree, when you selected 
(double-clicked) a component to view, upon loading, the nav tree would reset
(collapse back to the original state).

This bug has now been fixed so that the state of the navigation tree is
retained.  This fix applied to the workbench module version 3.2.16.2 and
beyond.

*** 42.1:10193  Logoff fails with Cookie Digest and Guest account enabled ***
  Record Type:  Bug
  Resolved In:  3.2.17; 3.3.1
If your station was set up with the guest account enbabled and 
the WebService set to use cookie digest authentication, you may
have seen an error page when navigating to /logoff.

This issue has been fixed, and now /logoff exhibits the correct
behavoir of forwarding you back to the /login page regardless of
of station config.


*** 42.1:10719  Log does not correctly handle user agent information ***
  Record Type:  Bug
  Resolved In:  3.3.7; 3.2.17
In previous versions of Niagara the Extended Log Format logging on the Web Service did not encode the user-agent field correctly by.  The field needed to be in quotes, or have the space characters encoded.

This has been fixed by enclosing the user-agent field in quotes for NCSA Extended Log Format and replaces spaces with + for W3C Extended Log Format.

#########################################################################
43  wiresheet
#########################################################################

=========================================================================
43.1  Fixed
=========================================================================

*** 43.1:7311  Name text should be unescaped when renaming multiple components ***
  Record Type:  Bug
  Resolved In:  3.0.92
When renaming multiple components at the same time (select components,
then right-click and select Rename), the Rename dialog shows the
"escaped" characters for any special characters, vs. the "display name."
For example, if you select components named "Folder 1" and "Folder 2" to 
rename, they appear as "Folder$201" and "Folder$202" (where space character
is escaped using "$20"). If you don't remove the escape characters, the 
rename uses them in the new display name.

In build 3.0.92 this was fixed. Now when renaming multiple components,
only the display names (unescaped names) are displayed and used.

*** 43.1:7644  Cut and paste doesn't show links without refresh ***
  Record Type:  Bug
  Resolved In:  3.2.2
It was found that if you cut and pasted a linked component from one folder
to another, the link handles did not appear until you refreshed the display.
The component cut and pasted had one or more outgoing links.

A fix was made for scenarios like this, so that wiresheets now correctly show 
links and knobs on a paste operation.

As a workaround in Workbench AX-3.0 or 3.1, refresh the display after doing
a cut-and-paste of linked components.

*** 43.1:8284  Editing link source through Link Sheet draws invalid link ***
  Record Type:  Bug
  Resolved In:  3.2.5
Previous version of Niagara did not correctly tear down and setup links if the
user manually changed properties of the Link on the LinkSheet. For example if
the LinkSheet was used to change the sourceOrd of the link, the change would
take effect until the station was restarted. Now changes to links should
immediately take effect.

*** 43.1:9802  Opening Alarm Service as user with admin RW throws wiresheet exception. ***
  Record Type:  Bug
  Resolved In:  3.2.14
Previous to build 3.2.14, the wiresheet would throw an exception when
viewing a page containing links created under certain admin permissions. 

This behavior has been corrected in builds 3.2.14 and on.

#########################################################################
44  workbench
#########################################################################

=========================================================================
44.1  Fixed
=========================================================================

*** 44.1:534  Paste Special (Duplicate X) ***
  Record Type:  Enhancement
  Resolved In:  3.2.4
Components now sport a new "Paste Special" command which allows a user
to enter input information in a dialog before the paste operation proceeds.
There are two aspects users can control via Paste Special: number of copies
and keep all links.

The number of copies allows the user to enter a number of copies to make
between 1 and 100.  This function works similiar to the old Duplicate X
feature in Niagara R2.

The keep all links checkbox allows the user to keep every link inside
the "graph" of components being copied.  Under normal pastes, links which
reference source components outside of the graph are automatically trimmed.
By setting keep all links to true, every link is maintained on the paste
operation.

Paste Special can only be used with components selected during a copy
operation.  An error will be displayed if the selection was made using the
cut command.

*** 44.1:7001  AbsTime property edit would select wrong field with some lexicons ***
  Record Type:  Bug
  Resolved In:  3.0.92
If a lexicon was used in which the month.short is less than or greater
than 3 characters, a property sheet edit of a slot using AbsTime data could
result in incorrect selection (focus) of a field after the month value. For
example, if the "Expiration" property for a User was edited, and the hours
field was selected, the focus would apply to the minutes field instead.

This was fixed in 3.0.92.  Now, the text for the month.short field is forced 
to be three characters long, either by appending spaces, or by clipping the 
text. This allows for fields following the month to be correctly indentified 
and focused.

*** 44.1:7023  Right-click in Options dialog should be disabled ***
  Record Type:  Bug
  Resolved In:  3.1.3
A Workbench user could right-click in the Options dialog (Tools -> Options) and
do inappropriate Config Flag changes, or see a popup Error dialog.  Starting in
build 3.1.3, right-clicks are disabled (ignored) in dialogs such as Options.

*** 44.1:7051  Date/time numeric keypress enters incorrect month ***
  Record Type:  Bug
  Resolved In:  3.0.92
If Workbench options (Tools > Options > General) had Time Format
set to any format in which month was "M" (ex: D-M-YY, M/D/YY), 
when using an editor to change an AbsTime value, a number typed
in directly for month would be off by one.  For example, when
using the Change Date/Time option from the Plaform Administration
view, in the month position of the Date field, if you typed in "3"
it would be entered as "4."

This was fixed in 3.0.92, where the BMultiFieldFE (field editor)
now correctly intreprets keyboard entry for the month.

*** 44.1:7081  Using dollar sign character in component name causes text to disappear ***
  Record Type:  Bug
  Resolved In:  3.0.91
Including a dollar sign character ("$") in a component's name would cause
problems displaying the component in various manager views, where that 
component name would appear blank.  For example, a proxy point named 
"Gate$" would appear blank in the PointManager view, a User named "J$W"
would appear blank in the UserManager, and so forth.

Starting in 3.0.91, this was fixed such that component names can include
the "$" character and still display correctly in manager views. The fix
was made to the "AbstractManager", the base class of many common tools 
including UserManager, DeviceManagers and PointManagers. This fix allows
the "$" to be correctly used in the display name, with the programatic slot
name escaped using "$24".

*** 44.1:7127  Accessing JobService in web (browser) Workbench caused "Cannot start component" error ***
  Record Type:  Bug
  Resolved In:  3.0.91
In a web Workbench connection, accessing a station's JobService would cause an 
error "Cannot start component: Job Monitor Pane".  This was fixed in 3.0.91, 
where the JobService can now be viewed in a browser.

*** 44.1:7154  After AutoLogoff, refresh logs user back in ***
  Record Type:  Bug
  Resolved In:  3.0.91
When a web workbench applet detected inactivity it would automatically
log the user off of the FoxSession.  However the HTTP session based on
a cookie would remain open.  Therefore the user could simply refresh the
page to be automatically logged back on.

Now when workbench running in an applet detects auto logoff, each applet will
hyperlink to the /logoff URL causing a HTTP logoff (by clearing the cookie). If
there are more than one browser window open running the workbench applet, then
all of them will perform a logoff. Typically a hyperlink to /logoff, will
then perform a redirect to /logon.

*** 44.1:7157  Ord hyperlink causes newly-entered ord to not save ***
  Record Type:  Bug
  Resolved In:  3.0.92
When entering a Hyperlink Ord value in a property sheet, and then clicking
the hyperlink (blue) arrow button to go to that view (without first saving),
a "save changes?" dialog appears.  It was found that selecting "Yes" would
not save the entered ord after the hyperlink from the property sheet.

This was fixed in 3.0.92, where the BOrdFE (ord field editor) no longer
changes the modified state when using the hyperlink button.

*** 44.1:7310  Clicking Edit in a Manager view when a folder is selected does nothing ***
  Record Type:  Bug
  Resolved In:  3.0.92
In a Manager view with a folder selected, clicking the Edit button did not
do anything. For example, if in the Point Manager view of a device, if you
selected a Point Folder and clicked Edit, nothing happened.

The Edit command in Manager views is not intended to edit folders, but
instead other listed components (devices if the Device Manager, and so on).
To clarify this, starting in 3.0.92 the Edit button is disabled when
only folder(s) are selected.

*** 44.1:7333  Link Mark popup menu text needs to be unescaped ***
  Record Type:  Bug
  Resolved In:  3.0.92
When Link Mark was used with a component named with any special characters 
(such as a space), the "Link To" and "Link From" menu items displayed using
the "escaped" programatic name, rather than the (unescaped) display name.
For example, if you set Link Mark on component named "AHU 8 SF", when you
right-clicked on another component the popup menu entries were 
"Link To AHU$208$20SF" and "Link From AHU$208$20SF".

In build 3.0.92 this was fixed--Link menu items now show the display names.
Also see related issue 7311.

*** 44.1:7410  Provided API to override properties in brand.properties file ***
  Record Type:  Enhancement
  Resolved In:  3.1.6
(Developer's Release Note)
A need existed for overriding properties in brand.properties based upon wb profile,
of which there may be multiples installed on same PC.  This way each profile
could have its own custom properties.  One example could be "workbench.title".

In 3.1.6, two new methods were added to BWbProfile to specify the frame's title 
text and icon. The default implementation continues to use brand.properties as before. 
Support for these methods was also added to docCodeExamples:ExWbProfile to illustrate
their use.

  /**
   * Return the icon which should be used for the shell's
   * frame window (not applicable in applets).  The default
   * icon is configured in brand.properties via the key
   * "workbench.icon".
   */
  public BImage getFrameIcon()

  /**
   * Return the title which should be used for the shell's
   * frame window (not applicable in applets).  The default
   * title text is configured in brand.properties via the 
   * key "workbench.title".
   */
  public String getFrameTitle()

*** 44.1:7411  ResourceMonitor should also plot heap.used. ***
  Record Type:  Enhancement
  Resolved In:  3.1.3
In 3.0 the ResourceMonitor plotted total memory used.  In 3.1 the Java
heap size is plotted instead, which provides a much better indication of
the load running in a JACE.

*** 44.1:7546  Right-click menu in Nav Tree takes a long time to appear if a large selection  ***
  Record Type:  Bug
  Resolved In:  3.1.3
In the Nav Tree, when selecting large numbers of components, a right-click
could result in a significant delay before the context menu appeared, making
it appear nothing was happening.  A subsequent right-click would undo the 
previous request and restart this process again.  This was fixed starting in
build 3.1.3.  Now, a right-click with multiple selections produces the menu
quickly, because multiple potential network requests are coalesced into one.

*** 44.1:7655  Meta Data in alarm extension allowed invalid key entry ***
  Record Type:  Bug
  Resolved In:  3.1.3
Previously when adding Meta Data in an alarm extension, the Facets Editor
allowed entry of a Key with invalid characters, such as spaces, "&", "?",
and so on.  A generic exception was thrown when a Save was attempted, 
with details saying Invalid Facets.

Starting in 3.1.3, the Facets Editor prevents entry of invalid key names
with a popup Error dialog saying "Invalid key name" .

*** 44.1:7730  Added station name to top level of the host in Nav Tree ***
  Record Type:  Enhancement
  Resolved In:  3.1.3
Previously the Nav Tree only showed the hostname and IP for top level nodes.
To see the station name required expanding the tree one level down, making it
difficult to manage a large number of stations.  Starting in build 3.1.3,
the Nav Tree format for display of top level (host) nodes is: 

       Hostname : IP (Station)

- Hostname may be omitted if accessing a station by raw IP address.

- IP may be omitted if the Hostname has not been resolved via DNS yet.

- Station is the name of the first station found under the host, or omitted 
  if no previous station connection has been made.


*** 44.1:8090  Moving bookmark folder to a subfolder deletes bookmarks ***
  Record Type:  Bug
  Resolved In:  3.1.10
In the Bookmark Manager, if an attempt is made to move a 
folder into itself or one of its subfolders, the folder
being moved and its contents are deleted.  

This issue was fixed in build 3.1.10 -- an error dialog will
now prompt you if you attempt to move a node into itself,
and the operation will be canceled, so no data loss occurs.

*** 44.1:8134  Add and edit windows are unwieldy for stations that have mix-ins ***
  Record Type:  Enhancement
  Resolved In:  3.1.10
In AX 3.1 the implementation of MgrModel.appendMixInColumns has been changed.

Custom software meeting the following criteria will be affected by the change:
- custom device extensions for niagaraDriver:NiagaraStation which are added 
using the Mix-In framework
- custom BAbstractManager implementations that explicitly invoke 
MgrModel.appendMixInColumns
There is no known 3.0 software that meets these criteria.

The 3.0 implementation of MgrModel.appendMixInColumns adds a single column
to the manager table for each mix-in, which simply shows the mixin.toString()
result, and adds a single property sheet field editor for each mix-in to the 
add and edit dialogs.   However, it is unlikely that mixin.toString() provides 
useful information in the manager table, and using property sheet editors in
the add and edit dialogs is not ideal because:
- the visual style is inconsistent, so it's unattractive
- read-only mix-in properties take too much space in dialogs intended for 
  editable properties

With AX 3.1, mix-in developers should write BMixinMgrAgent subclasses and
register them as agents on the mix-in type.   The BMixinMgrAgent's getColumns()
method provides the manager with columns to be displayed in the table by 
default and on request, and with editable properties to include in the add &
edit dialogs.


*** 44.1:8271  Extend appName filtering to WbSideBars ***
  Record Type:  Enhancement
  Resolved In:  3.1.14
(Developer's Release Note)
appName filtering has been extended to BWbSideBars.  The default implementation of 
BWbProfile.hasSideBar(TypeInfo) will now look for appNames matching your profile
appName.  You just need to add an "empty" agent tag to your sidebar:

  <type name="ApplianceSideBar" class="appliance.ui.BApplianceSideBar">
    <agent app="demoAppliance" />
  </type>

The signature and semantics of the hasSideBar() method has not changed - but be sure
to use the app name for future SideBars to keep them out of the default WbProfile.
If you do not specify an appName for your SideBar, it will be included in the default
Workbench profile.


*** 44.1:8305  Toggle font size in Workbench ***
  Record Type:  Enhancement
  Resolved In:  3.2.4
There is a new option in Workbench under Tools -> Options -> General called
Font size.  The options are "Normal" for the current font sizes and "Large"
which will increase the point size of all fonts by 4 points.  You'll need to
restart Workbench for the changes to take effect.

*** 44.1:8332  Undo/redo support added for link command ***
  Record Type:  Bug
  Resolved In:  3.2.2
The link command used to create a link between two components now
supports undo and redo capability.  Previously, undo/redo was not
available for link operations.

*** 44.1:8362  Reference HTML "Third Party Licenses" page in Help > About ***
  Record Type:  Enhancement
  Resolved In:  3.0.101; 3.1.16
(Developer's Release Note)
The Niagara Workbench Help "About" splashscreen has a "Third Party Licenses"
link, which formerly pointed to a text file (!lib/readmeLicenses.txt).  This
was changed to point to !lib/readmeLicenses.html, which will permit further
linking.

*** 44.1:8935  Workbench exception when composite parent has hidden slots ***
  Record Type:  Bug
  Resolved In:  3.0.103; 3.1.25; 3.2.1
The Composite Editor previously failed to account for hidden slots on the
composite component when editing composite slots, and would throw an
exception on the client side (Workbench). The exception appeared to be benign,
but was fixed to work correctly without throwing an expection.

*** 44.1:9062  Need to show message to user if incorrect login info is entered ***
  Record Type:  Enhancement
  Resolved In:  3.2.4
Previously when login credentials failed in workbench it just redisplayed
the error dialog.  Now after the first failure the dialog banner gives
the user a message telling them that their login credentials failed.

*** 44.1:9150  "Replace in Files" function adds random text at end of file ***
  Record Type:  Bug
  Resolved In:  3.2.5
Previous versions of Niagara did not properly handle non-ASCII text files
when using the "Replace in Files" command.  Niagara 3.2 now reads text
files in either UTF-16 with BOM or UTF-8 when searching (consistently with 
other Niagara tools), and always outputs UTF-8 when writing replacement
files.

*** 44.1:9830  Customize background of kiosk splash screen ***
  Record Type:  Enhancement
  Resolved In:  3.2.14
BKioskService now has a 'splashFill' property of type BBrush, which
can be used to customize the background of the login splash screen
in the BKioskProfile.

*** 44.1:10168  NavFileEditor does not allow quotes in Ords ***
  Record Type:  Bug
  Resolved In:  3.3.1
If you try using an ord in the NavFileEditor that contains 
a quote, the navfile produced will be invalid.  An example
is a BQL query with a where clause.

This has been fixed so that the NavFileEditor properly
escapes illegal characters in nav files.

*** 44.1:10352  Korean timeFormat keeps BAbsTimeFE from saving correctly ***
  Record Type:  Bug
  Resolved In:  3.2.17; 3.3.1
Prior to Build 3.2.17, if the AMPM time format was before the hour display (like
in the default Korean time format), then a BAbsTimeFE and BTimeFE would
improperly save the time such that any PM time would save as an AM time.

*** 44.1:10789  OrdFE view selector not working correctly ***
  Record Type:  Bug
  Resolved In:  3.3.9
The BOrdFE view selector has been fixed and improved to function more the like
the view drop-down in the Workbench PathBar:

  - Now displays PxViews
  - Uses the display name
  - Displays the view icon as well

*** 44.1:10805  PathBar does not handle ZipFile's correctly ***
  Record Type:  Bug
  Resolved In:  3.3.9
The PathBar did not correctly display the paths of files inside a 
ZipFile.  It only displayed the file you are resolved to - none of
the intervening paths:

   ord: file:!foo/bar.zip|zip:/a/b/c/File.txt
   pathBar: [foo] [bar.zip] [File.txt]
   
The behavoir has been fixed and how correctly displays:

   pathBar: [foo] [bar.zip] [a] [b] [c] [File.txt]

*** 44.1:10856  Hiding sign in BRelTimeFE breaks optional day save ***
  Record Type:  Bug
  Resolved In:  3.2.17; 3.3.12
Using the combination of two facets kept the BRelTimeFE from saving correctly:

1) A minimum facet of above or equal to zero to keep the +/- sign field editor
from appearing.

2) The facet that shows the number of days instead of the number of hours when
the hours are greater than a day.

Now the BRelTimeFE saves the day field with or without the +/- sign field
editor.

=========================================================================
44.2  Open
=========================================================================

*** 44.2:6978  Date selection popup calendar ignores customized baja lexicon key ***
  Record Type:  Bug
  Resolved In:  
If the baja lexicon key "weekday.firstDayOfWeek" value is changed from the default
"sunday" to another day (for example, "monday"), this is not reflected in the
date selection field editor.  This editor appears as a calendar popup when
working with special events in a schedule, or when editing a time range for
a history chart.  The popup date selection calendar always shows Sunday (S) as
the first day of each week.  However, note that other scheduler views that show
weekly or calendar information are correctly formatted using this modified
lexicon key.

#########################################################################
45  build
#########################################################################

=========================================================================
45.1  Open
=========================================================================

*** 45.1:508  slot.exe not ignoring code in java comments ***
  Record Type:  Bug
  Resolved In:  
slot.exe does not ignore slot-o-matic code if that code is in a comment block.
As a workaround, do not put slot-o-matic code inside java comments.

#########################################################################
46  install
#########################################################################

=========================================================================
46.1  Fixed
=========================================================================

*** 46.1:3613  Need to update the EULA for QNX liability limits ***
  Record Type:  Enhancement
  Resolved In:  3.0.80
Text added to license agreement:

High Risk Applications. 
Unless Tridium has provided its express written consent for each component of 
the Niagara Framework, the Licensee will make reasonable business efforts to 
ensure that it is not used in any application in which the failure of the 
Licensed Materials could lead to death, personal injury or severe physical or 
property damage (collectively, "High-Risk Applications"), including but not 
limited to the operation of nuclear facilities, mass transit systems, aircraft
navigation or aircraft communication systems, air traffic control, weapon 
systems and direct life support machines. Tridium expressly disclaims any 
express or implied warranty or condition of fitness for High-Risk Applications.

*** 46.1:7015  Installer copied files from CD as read-only ***
  Record Type:  Enhancement
  Resolved In:  3.0.92
Prior to build 3.0.92, when you installed NiagaraAX from a CD, files in the 
modules, sw, and lexicon directories had the read-only attribute set, as a 
result of the CD copy.  The read-only attribute should not be set on these
files, because you get an error when Niagara tries to overwrite them.

This was fixed starting in build 3.0.92.  The NiagaraAX installer now marks
all files as readable (not read-only). As a workaround in earlier builds
(following an install from CD), you should clear the read-only flag on files
in those directories, using Windows Explorer.

*** 46.1:7289  Ability to modify finishing "Launch Workbench" command ***
  Record Type:  Enhancement
  Resolved In:  3.0.92
(Developer Release Note)
The install.properties file has a new property: finish.launchWbCommand
The default value is bin\\wb_w.exe
This allows you to change the command (Wokbench profile) that is run when, at 
the end of the installation, the "Launch Workbench" option is selected.

*** 46.1:7430  List of directories to skip during install ***
  Record Type:  Enhancement
  Resolved In:  3.0.94
*Developer Release Note*
Added install.skipDirs to install.properties
The Niagara installer will not install the directories in this ; separated list
of directores.      

For example:
install.skipDirs=daemon;certificates
will not install the daemon or certificates directories or any of their 
contents.

*** 46.1:7431  Finish Script added to install.properties ***
  Record Type:  Enhancement
  Resolved In:  3.0.94
*Developer Release Note*
Starting in 3.0.94, added finish.script to install.properties.

The script/program specified here will be run after the Niagara installation
is complete (When the users clicks Okay on the Finish screen).


*** 46.1:7506  Installer Welcome Text changed ***
  Record Type:  Enhancement
  Resolved In:  3.0.95
*Developer Release Note*
Starting in 3.0.95, the Niagara installer welcome text was changed to:

  Welcome to Niagara Install!

  This program will install the NiagaraAX Runtime Environment onto your computer.

  <blank space for additional text - welcome.message3 in install.properties>

  Powered by NiagaraAX
  Build 3.0.95
  29 Sep 2005

The change from "Niagara Runtime Environment" to "Powered by NiagaraAX" also 
appears in the uninstaller.


*** 46.1:7765  Add process to copy docs as part of NiagaraAX Workbench install ***
  Record Type:  Enhancement
  Resolved In:  3.1.17
If the "docs" directory is present in the root of the NiagaraAX Workbench
installer, an option will appear on the Destination Directory screen aking 
the user if they would like to "Install Documentation."  This updates the 
installation sizes accordingly. If the option is selected, the docs directory
from the installation source (e.g CD) will be copied into the installation 
folder.

*** 46.1:8401  Option to copy files from previous NiagaraAX installation ***
  Record Type:  Enhancement
  Resolved In:  3.1.17
If NiagaraAX has been previously installed, then the user is presented with 
a checkbox (option) during the installation process asking if they would like 
to Copy Previous Settings.  The installer displays this option as: 

 "Copy Settings From Last Install. <install directory>"

If the box is checked, the following folders will be copied from the previous 
(last) NiagaraAX installation to the new installation:

 !stations (exception demo and demoAppliance)
 !licenses
 !certificates
 !daemon
 !sw
 !users
 !workbench

 as well as any modules in the old install that are not present in the new 
 install.

Note that the file !users/*/options/platDaemon-DistInstaller.options is not 
copied, so that the dist installer defaults to the directory of the newly 
installed build.

This option is a convenience that saves the user from having to manually copy
files from the previous install, such that the new Workbench can start up using
the pre-established settings and options.  Note that the previous stations 
"demo" and "demoAppliance" are not copied--if previously modified, the user 
can rename them and copy over to the new !stations folder to keep them in the
upgrade sequence.

=========================================================================
46.2  Open
=========================================================================

*** 46.2:9470  Hide "Copy From Previous Install" is previous install was a newer build ***
  Record Type:  Enhancement
  Resolved In:  3.2.8; 3.1.31
If the "last install" detected by the installer is a newer version than is being installed, the "Copy From Last
Install" option is not displayed.


#########################################################################
47  wbapplet
#########################################################################

=========================================================================
47.1  Fixed
=========================================================================

*** 47.1:7197  Web Workbench access needed new Niagara home for downloaded modules ***
  Record Type:  Bug
  Resolved In:  3.0.91
Prior to build 3.0.91, Web browser access of a station serving Workbench used a
local Niagara home directory under the Java 2 platform runtime environment home 
("$java.home") in which to store downloaded Niagara modules and user options.  
For example:  C:\Program Files\Java\jre1.5.0_04\niagara

In some scenarios, a user of that PC might not have write privleges in that 
location, and this would cause problems.

Starting in build 3.0.91, the new location of Niagara home for web Workbench
access is "$(user.home)\niagara\wbapplet".  This guarantees that the user has 
read and write privleges.  On a Windows PC you typically find user files under 
"My Documents and Settings".  For example, for Windows user "JoeUser", the
new Niagara home would be:  C:\Documents and Settings\JoeUser\niagara\wbapplet

*** 47.1:7807  Web workbench in a browser "Out of Memory" exception ***
  Record Type:  Bug
  Resolved In:  3.2.1
By design, if you use Workbench in a web browser, then each JACE to which you
connect (unique HTTP authority) requires its own copy of Workbench in order
to run--we call this loaded copy the NRE (Niagara Running Environment).  So if 
you connect to multiple HTTP authorities, then you could start to use a lot of
memory, and eventually lead to an "Out of Memory" exception.  

In order to improve this performance, the wbApplet.jar file was changed.
Now when a new HTTP authority connection is established, a check is made to
existing (previously loaded) NREs in an attempt to find one with a matching 
module list.  If a match is found, then the NRE is reused, thus saving memory.
If a match is not found, then it simply boots a new NRE just like before.

This solution will be helpful in cases where you make connections to multiple
JACES, where each has the same modules installed.


*** 47.1:8011  Ability to load custom Web applets (such as VES) ***
  Record Type:  Enhancement
  Resolved In:  3.0.100
Starting in build 3.0.100, an updated wbapplet.jar is installed in the /lib
folder of a NiagaraAX installation.  This jar was enhanced to provide support
for custom web applets, such as VES (Vykon Energy Suite).  Prior to build
3.0.100, you had to manually install an updated wbapplet.jar file.

*** 47.1:8227  Exiting Help in Web Workbench (wbApplet) closes all windows ***
  Record Type:  Bug
  Resolved In:  3.2.2
When using Web Workbench, if you produce the Help window by right-clicking
on a component in the station and selecting Views > Guide Help or Bajadoc Help,
another browser window opens: Niagara Help.  When you close that (help) window, 
all Web Workbench windows close.  This was fixed in 3.2.2.

Please note that other problems may exist with Help in Web Workbench--and it
is not found on the main Menu.

#########################################################################
48  kitControl
#########################################################################

=========================================================================
48.1  Fixed
=========================================================================

*** 48.1:5964  Sliding Window Demand Calculation object ***
  Record Type:  Enhancement
  Resolved In:  3.0.80
A SlidingWindowDemandCalc object was added to kitControl, located in the 
Energy folder of the kitControl palette.  It performs the same function as the
the SlidingWindowDemand program object in the Niagara r2 lib jar file. 


*** 48.1:6888  Loop does not execute at selected execute interval ***
  Record Type:  Bug
  Resolved In:  3.0.86
This problem was noticed in releases prior to 3.0.86.

When the station database doesn't have any control objects that use system
timers, such as KitControl SineWave, Ramp, Random, and MulitVibrator, The Loop
Point actual execute time may be erratic, or run at about once every 2 seconds
even though the ExecuteTime property is set a value much smaller.  The 
ActualTime property displays the actual time between pid execution.

This problem was fixed starting in build 3.0.86

As a workaround for stations running under an earlier build, you can add a 
MultiVibrator to the station, and set its period to twice the value of the 
LoopPoint's ExecuteTime property.  For example, if the LoopPoint ExecuteTime 
is 500 milliseconds, set the MultiVibrator's Period to 1 second.

*** 48.1:7040  SequenceBinary's Delay property should default to 0. ***
  Record Type:  Enhancement
  Resolved In:  3.0.89
The SequenceBinary's Delay property default value has been changed from 1 second 
to 0 seconds in build 3.0.89.  Any stations databases created with prior builds 
that have instances of the SequenceBinary component should be examined.  If the 
Delay property was at the previous 1 second default value, after upgrading to 
build 3.0.89 the Delay property will be 0 second.  If the Delay property value 
was any other value (not 1 second), the Delay property will remain unchanged 
through the upgrade. 

*** 48.1:7317  LoopPoint throws nullPointerExceptions when disabled. ***
  Record Type:  Bug
  Resolved In:  3.0.92
In builds 3.0.84 and earlier, it was found that disabling the LoopPoint caused
nullPointerExceptions to be thrown and printed in the Station Director output.
A code change was made build 3.0.92 to correct this problem.

*** 48.1:7409  LoopPoint's "disableAction" feature did not function correctly. ***
  Record Type:  Bug
  Resolved In:  3.0.94
A LoopPoint's "disableAction" is suppose to control the behavior of the loop's
out property when the loop is disabled.  The choices are MaxValue, MinValue,
Hold, or Zero.  In builds 3.0.88 and earlier, the disableAction selected was 
being ignored and the loop out value would hold when the LoopPoint was disabled.
This problem was corrected in build 3.0.94.

*** 48.1:7485  OutsideAirOptimization object low temperature lockout did not function properly. ***
  Record Type:  Bug
  Resolved In:  3.0.95
If the outside air temperature is less that the low temperature limit value, 
free cooling should be disabled. It was found that this low temperature limit
was being ignored in builds 3.0.94 and earlier.  The problem was corrected in
build 3.0.95.  A kitControl 3.0.94.1 patch jar file was also created to correct
this problem.

*** 48.1:7968  Added conversion object StatusNumericToStatusEnum ***
  Record Type:  Enhancement
  Resolved In:  3.1.6
A StatusNumericToStatusEnum component has been added to kitControl, found in
the Conversion folder in the kitControl palette.  This component provides the 
conversion of a StatusNumeric value to a StatusEnum value.  In the conversion,
any decimal component of the input is simply truncated to form the integer 
ordinal of the output.


*** 48.1:7970  SlidingWindowDemandCalc "lastHour" does not add up ***
  Record Type:  Bug
  Resolved In:  3.1.6
Calculation of the "Kwh Last Hour" property (kwhLastHour) was found to omit kWh
values upon hour changes, such that the sum of these calculations did not equal
the total kWh consumption.  The kwhLastHour calculation was modified to fix this
problem in the SlidingWindowDemandCalc component.

*** 48.1:8235  Derivative term in LoopPoint was calculated incorrectly. ***
  Record Type:  Bug
  Resolved In:  3.1.13
The LoopPoint has been modified to correct a problem with the PID algorithm 
when a derivative term was used. 

*** 48.1:8237  BooleanDelay cleared delay function upon status flags change of source value. ***
  Record Type:  Bug
  Resolved In:  3.1.13; 3.0.101
KitControl's BooleanDelay component has been modified to correct a problem that
was causing the delay function to clear prematurely on an input status flag
change.

*** 48.1:8469  Boolean, Numeric, Enum, & String Select components need zero-based selection methods. ***
  Record Type:  Enhancement
  Resolved In:  3.0.101; 3.1.18
KitControl's Boolean, Numeric, Enum, and StringSelect components have been 
modified to allow selection based on zero- or one-based input selection.
A boolean property "zeroBasedSelect" specifies this operation.  When this
property is true, an ordinal value of zero (0) on the Select input (StatusEnum)
will select the first value.  If the zeroBasedSelect property is false (default),
an ordinal value of one (1) selects the first value, as it worked previously.

*** 48.1:8611  LoopPoint Ramp Time not correctly implemented in some scenarios ***
  Record Type:  Bug
  Resolved In:  3.1.22
The Disable Action property of a LoopPoint allows the output value selectable
to max value, min value, hold, or zero, when the LoopPoint is disabled. 
However, upon transition from disable to enable, the Ramp Time was sometimes
inappropriately applied, causing an output spike. The LoopPoint was modified
to correct the Ramp Time function in all cases of direct and reverse acting.

*** 48.1:8619  Facets added for P, I, & D tuning constant precision in LoopPoint. ***
  Record Type:  Enhancement
  Resolved In:  3.1.22
A tuningFacets property has been added to the LoopPoint, to control the 
precision of the tuning constants.

*** 48.1:8791  Facets on Psychrometric needed for SI (European) units ***
  Record Type:  Enhancement
  Resolved In:  3.2.1; 3.1.25
To support SI units, the Psychrometric component, found in the Energy folder of
the kitControl palette, now has a boolean "Unit Select" property.

- If set to English, the "Out Enthalpy" slot is calculated in BTU/pound.
- If set to Metric, the "Out Enthalpy" slot is calcuated in kJ/kg.

Note that if English is used, the temperature input must be in degF, and if
Metric is used, the temperature input must be in degC.

*** 48.1:8910  SlidingWindowDemandCalc is not working correctly when linked from a Numeric point. ***
  Record Type:  Bug
  Resolved In:  3.0.103; 3.1.25; 3.2.1
KitControl's SlidingWindowDemandCalc component has been modified to correct a
problem calculating demand when the source for the currentPulseCount input was
a NumericPoint.

*** 48.1:9068  NightPurge component without enthalpy control did not work ***
  Record Type:  Enhancement
  Resolved In:  3.0.104; 3.1.28; 3.2.2
The NightPurge component (found in Energy folder of kitControl palette) has been
modified to correct a problem that was causing it to always call for free cooling 
if the UseEnthalpy property was set to false.

*** 48.1:9938  Sequence Linear does not function correctly when set in Rotation mode ***
  Record Type:  Bug
  Resolved In:  3.3.1; 3.2.15; 3.1.31
In earlier Niagara AX builds the sequenceLinear and SequenceBinary objects 
may not set the correct number of outputs "ON" if the input value is outside 
the range specified by the inMaximum and inMinimum properties. This has been 
fixed in builds 3.2.15 and 3.1.31 to have the correct number of outputs "ON"if 
the input is out of the range of inMaximum and inMinimum properties.


#########################################################################
49  kitPx
#########################################################################

=========================================================================
49.1  Fixed
=========================================================================

*** 49.1:8790  Image Buttons on Px page required page refresh to load image ***
  Record Type:  Bug
  Resolved In:  3.0.102; 3.1.24; 3.2.1
In some scenarios, images on buttons would fail to load until the PX page
was manually refreshed.  The issue was specific to images loaded from
the file system used with an ImageButton (for example, an ActionButton or
an IncrementSetPointButton).  This was fixed to correctly "lazily-loaded" 
images without a manual refresh.

*** 49.1:8937  Action binding with argument ignores "confirm required" flag on action ***
  Record Type:  Bug
  Resolved In:  3.2.2
When adding a widget with an action binding, for example an ActionButton,
and binding it to an action slot with its "Confirm Required" config flag set,
user confirmation was *not* presented if the action binding's Action Arg is
pre-defined ("Prompt User" is deselected).  Instead, the action with argument
was immediately invoked.  Now, the confirmation dialog pops up, and if the user
confirms, only then is the pre-defined action invoked.

#########################################################################
50  ldap
#########################################################################

=========================================================================
50.1  Fixed
=========================================================================

*** 50.1:8196  Active Directory - Connection User eliminated to support rotating passwords. ***
  Record Type:  Enhancement
  Resolved In:  3.1.13
Connection User properties have been removed from the Active Directory User
Service, to support rotating passwords managed by their Active Directory. Now,
the credentials of the person attempting to login are used instead.  With this
change, a new property was added called Domain.  Often, it is necessary to 
specify the domain being logged into.

*** 50.1:8197  Default Prototype user added under User Prototypes. ***
  Record Type:  Enhancement
  Resolved In:  3.1.13
Previously, if a User Prototype couldn not be found for a user, the guest user
account was used instead. This did not provide a way to distinguish the
permissions of true guests versus users who authenticated against the LDAP
server. There is now a Default Prototype under User Prototypes.

#########################################################################
51  provisioning
#########################################################################

=========================================================================
51.1  Fixed
=========================================================================

*** 51.1:9765  Software list fails to show all modules from SW folder ***
  Record Type:  Bug
  Resolved In:  3.2.12
In all Niagara AX 3.1 and Niagara AX 3.2 builds 3.2.11 and earlier, the 
initialization of the provisioning service's software container will fail
if one or more of the files in the software database (!sw directory) is
corrupt.   This will cause the list of software to be incomplete in the 
supervisor software manager view, and in the dialog shown when adding an 
"install software" step to a provisioning job.

In build 3.2.12 the initialization has been changed so that it will continue
processing after attempting to import a corrupt file.

To work around this problem, customers should find and remove any corrupt 
files in the !sw directory on the supervisor.

#########################################################################
52  aapup
#########################################################################

=========================================================================
52.1  Fixed
=========================================================================

*** 52.1:7703  Added "Exts" column to Pup Device Manager ***
  Record Type:  Enhancement
  Resolved In:  3.2.2; 3.1.28; 3.0.104
An "Exts" column was added to the Pup Device Manager, similar as
found in other driver's device manager views.  This allows quick access
to the Points device extension for any Pup Device.

*** 52.1:8065  Not able to use alternate deviceTypes.xml in device/point learn ***
  Record Type:  Bug
  Resolved In:  3.0.101; 3.1.9
Fixed an issue where you could not specify an alternate deviceTypes.xml file
to use for learning devices and points. Now, a new property on the network 
is called deviceTypesFile, which is a BOrd to a file.  Initially, it defaults 
to the file in the aapup.jar file.

Now, whenever you choose a different file via the learn device or learn point 
dialog configs, this property is updated with the new BOrd.  Default access is 
given to the File Chooser, and you are constrained to choose a file local on the 
JACE, either the one in the aapup module, or a user-created file contained under
the station's directory.

*** 52.1:8335  Time sync broadcast address incorrect ***
  Record Type:  Bug
  Resolved In:  3.0.101; 3.1.15
Fixed a bug where the "Sync Time" action from the PupNetwork component
incorrectly used a fixed address of 7497, instead of the broadcast
address of 65535.

*** 52.1:8336  Spelling errors in deviceTypes.xml ***
  Record Type:  Bug
  Resolved In:  3.0.101; 3.1.15
The word "temperature" was misspelled in several places in deviceTypes.xml, and 
has now been corrected.  This would have manifested itself in misspellings in
the channel descriptions for points learned using the included deviceTypes file.

*** 52.1:8338  Additional device types added to deviceTypes.xml ***
  Record Type:  Enhancement
  Resolved In:  3.0.101; 3.1.15
The following device types from American Automatrix were added to the
deviceTypes.xml file.
FX            Controller Type=2
PX1           Controller Type=7
UX1           Controller Type=12
SOLOView      Controller Type=13
HC2           Controller Type=25
SBC-VAV-IAQ   Controller Type=110

*** 52.1:8446  No channels learned in GPC if any channel description is empty ***
  Record Type:  Bug
  Resolved In:  3.0.101; 3.1.18
Fixed bug where the point learn would fail while trying discover points
in a GPC series controller.  The point learn would fail if the attribute
"ON" of channel FF00 was set to an empty string.  This was fixed by
implementing the following rule:  For GPC controllers, if the length of the 
string in attribute "ON" is less than 2, then the channel description will
now default instead to the channel number.


*** 52.1:8459  Upload Regions if large SPL files does not complete ***
  Record Type:  Bug
  Resolved In:  3.0.101; 3.1.18
For large regions, the Upload Regions Job could time out while waiting for 
the controller to form a response which contained a large block of bytes.
This was noticed on the GPC line of controllers, but could possibly happen
on other controllers.

The timeout for responses to upload region commands has now been extented
to be 3x the "Response Timeout" property defined on the network property sheet.
This extension only applies to Upload Regions operations.

*** 52.1:8483  Error with download of large SPL files  ***
  Record Type:  Bug
  Resolved In:  3.0.101; 3.1.18
A download of a large SPL file into a controller could cause a timeout resulting
in the incomplete download of the file.  The timeout on download messages
has now been increased to 3x the configured timeout in the network property
page.  This allows the controller enough time to process the message and 
return a ack message, allowing the download process to complete normally.

*** 52.1:8676  Device ping may not work with old controllers ***
  Record Type:  Bug
  Resolved In:  3.0.102; 3.1.23
Old firmware controllers may not be able to interpret the message type used to 
ping the devices, resulting in persistent device down conditions.  A new 
property "pingMessageType" has been added to a PupDevice, to allow the fallback
to earlier supported message types for the ping mechanism.

The default value of pingMessageType is "ReportException message", which will
cause ping to behave exactly as before.

A second option is the "SayHello Message".  The "SayHello" selection causes 
the SayHello message to be sent for a ping.

A third option (which should only be used if the first two selections do
not work, is the "Read Channel FF00 Attribute ID".  This will cause the
ReadAttributeMessage to be sent to channel FF00, attribute "ID" in the 
controller.

NOTE: One useage caveat: If the selection is set to anything other than the 
default "ReportException Message", then all native alarms from the controller
will not be available. They can only be reported in a ReportException message
response.

*** 52.1:8878  String writable threw exception on write  ***
  Record Type:  Bug
  Resolved In:  3.1.25; 3.0.103; 3.2.1
Fixed a bug where a StringWritable proxy ext type would throw an error 
exception on writes if the attribute type was a text type.

*** 52.1:9087  Clear Token Snoop action added to Pup Network ***
  Record Type:  Enhancement
  Resolved In:  3.1.28; 3.2.2; 3.0.104
New action "Clear Token Snoop" was added to TokenPassConfig property of the
PupNetwork.  Invoking the action will clear all text from the token
snoop buffer.

#########################################################################
53  bacnet
#########################################################################

=========================================================================
53.1  Fixed
=========================================================================

*** 53.1:5925  Missing log-disabled entry when TrendLogExt disabled ***
  Record Type:  Bug
  Resolved In:  3.2.17; 3.3.4
The BACnet Trend Log Extension does not record a "log-disabled" entry in the
buffer when it is disabled by manually setting the enabled flag to false,
or by using the HistoryExtManager view.

However, the entry *is* properly recorded when the extension's stopLogging action is
invoked.  If this entry is absolutely necessary, make sure to use the action
instead of the other methods to disable the log.

*** 53.1:6144  Setting address within device manager yields error ***
  Record Type:  Bug
  Resolved In:  3.0.96
When attempting to set a device address from within the BacnetDeviceManager,
you may encounter an error, with the message "Cannot call set on unmounted
struct using transaction".  This error has been fixed in build 3.0.95.1.  
In builds prior to 3.0.95.1, you can edit the address from within the Property
Sheet.  If you encounter the error in the property sheet, click OK a second 
time and the value should be saved.

*** 53.1:6169  TrendLogExt failed onExecute() errors ***
  Record Type:  Bug
  Resolved In:  3.0.84
When a history being generated by a BACnet Trend Log Extension was removed,
this caused an error because the reference to the history in the extension was
not cleared.  This has been fixed.  When the history is removed, the extension
handles this situation and re-creates the history the next time a record is
stored.

*** 53.1:6729  BACnet proxy points write priority array to AVs that have no priority array ***
  Record Type:  Bug
  Resolved In:  3.0.83
Value type BACnet objects may optionally include a priority array for 
commandable operation.  There is no way to tell whether a particular object 
uses a priority scheme, except to check for the presence of the priority array 
(for example, by attempting to read it).  This had been accomplished during 
polling in versions prior to build 83.  But the nature of the point was not stored, so it
had to be re-discovered after each restart.  If the point was not polled for 
some reason (not permanently subscribed & not being viewed), it would try to 
write its value on start, but might not know the correct way to do this.

The mechanism has been fixed in build 83 so that new points automatically discover whether
they are prioritized or not on startup, and this flag is persisted in the
deviceFacets property.  The prioritization is also discovered during the learn
process, so the proper point is created in the point manager.

*** 53.1:6880  Bacnet MSTP trunks need to be separately licensed ***
  Record Type:  Enhancement
  Resolved In:  3.0.96
As of Build 3.0.95.3, a valid license will be required to use the BACnet/MSTP
driver.  MSTP Network ports will require a valid MSTP license in order to
function properly.  If you have the part number DR-MSTP-AX in your license,
you will have a feature called "mstp".  This feature will have a property
called "port.limit".  The property will have an integer value, which is the
number of ports for which you are licensed, which will be equal to the number
of DR-MSTP-AX parts which are purchased for this host.  This is the maximum
number of MSTP ports that you can successfully add to the station.  All
Network ports now have a status property, which will reflect the fault status
and enabled/disabled status of the port, and a faultCause property, which can
help diagnose the reason why a network port is in fault.

If you have been using a BACnet/MSTP port, and your license does not contain
the "mstp" feature, contact Tridium to have your license upgraded.

*** 53.1:6984  Station startup error about missing target agent, kitControl:LoopPoint ***
  Record Type:  Bug
  Resolved In:  3.0.49
If a station with a BacnetNetwork is running on a JACE without the kitControl
module installed, upon startup an ERROR is seen similar to:

 "[sys.registry] Cannot find agent target type "kitControl:LoopPoint" for 
   "bacnet:BacnetLoopDescriptor"
   
This error occurs only if the kitControl module is not installed on the JACE.
However, it does not cause any other runtime problems.

This error is expected to be rare, as it is very difficult to do any processing
of point values (outside of point extensions) without kitControl. Further, you
cannot expose a LoopPoint to Bacnet without the kitControl module installed,
as the LoopPoint itself is a kitControl component.  

*** 53.1:6991  Poll message timeouts cause nuisance device downs ***
  Record Type:  Bug
  Resolved In:  3.0.88
If a transaction timeout was encountered trying to poll a point or object in a
BacnetDevice, a ping failure was registered, and the device was marked "down."
Starting in build 3.0.88, this was changed such that the device is simply pinged.
This should prevent "nuisance" device down errors for certain types of devices
(possibly MSTP devices) that may fail to respond to a particular request, but do 
respond to the network's Monitor ping message (directed at the device's Device 
object).

The important thing is to (at the BacnetNetwork level) leave the Monitor (Ping
Monitor) enabled, so that a down device can be brought back up in a timely fashion.

*** 53.1:6992  Segmented message sent to devices not supporting segmentation ***
  Record Type:  Bug
  Resolved In:  3.0.96
In certain instances, earlier versions of NiagaraAX may attempt to send a
segmented message to a device that does not support any segmentation.
Beginning in Build 3.0.96, this has been fixed.  Niagara now checks the
device's segmentation capability and internally falls back to a more robust
mechanism if the original attempt would require segmentation, and we know that
segmentation is not supported by the remote device.

*** 53.1:6994  No way to reset group polling of BacnetDevice ***
  Record Type:  Bug
  Resolved In:  3.0.88
The BacnetDevice attempts to perform polling of multiple points with a single
ReadPropertyMultiple request.  The number of points that are put into a single
request is controlled by the dynamic property "maxDevicePollSize".  This is
determined and set when the device is learned or created, from the device's
maxAPDULengthAccepted property.  If multiple point polling fails for some
reason, Niagara automatically falls back to individual point polling.

Prior to build 3.0.88, there was no way to reset group polling except to restart
the station.  This was fixed in build 3.0.88 such that adjusting the property
"maxDevicePollSize" causes a reset of group polling.

In general, it is best to leave the value calculated for maxDevicePollSize alone.
However, in some circumstances, you may need to decrease the value to allow group 
polling to work.  This may occur if you are polling points that have larger, or
unbounded data types, such as string, octet-string, or a constructed data type.
Please note that there is virtually no reason to increase maxDevicePollSize beyond
the calculated value, as the most likely result will be that the device will fail
at group polling and fall back to the less efficient individual point polling
mechanism.

*** 53.1:7026  Difficult to detect export faults due to point configuration ***
  Record Type:  Bug
  Resolved In:  3.0.89
When an exported point was in fault - meaning the BacnetExportObject mapping 
the point to BACnet was showing a status of fault - it was not always easy to 
determine the cause of the fault.  For some cases, such as licensing and 
parentage issues, the faultCause field did correctly reflect the reason.  
However, if a point configuration problem (such as having a multistate with a 
bad range), the faultCause field did not provide this reason.  
Starting in 3.0.89 this was fixed, and these export faults are now expressed.  
In addition, the faultCause field is now available in the ExportManager table, 
although it defaults to being unseen.

*** 53.1:7027  Invalid presentValue not disallowed or faulted ***
  Record Type:  Bug
  Resolved In:  3.0.89
Certain values for a Niagara Control Point are not valid for a BACnet Object.
For example, an Enum Point may have any value, regardless of whether the facets
map this value to a tag or not. However, a BACnet MultiState point may ONLY
have a value that is defined within the stateText property (this must be 1-N).
Values outside of this range are disallowed. Also, a writable point may have a
null value, if all of the in slots and the fallback slot are all null. This is
disallowed for BACnet objects, as the non-prioritized objects must have a
distinct value for Present_Value, and the prioritized ones must have a distinct
value for Relinquish_Default, which drives Present_Value in the absence of any
entries in the Priority_Array.

When a Niagara point exposed to BACnet takes on a value that is illegal for the
exposed BACnet object type, the server (export) descriptor component (e.g.
BacnetMultistateInputDescriptor) now goes into fault status, with a reliability
of "UNRELIABLE_OTHER". You see status for export descriptors in the Export
Manager view of the Export Table under the Bacnet Local Device. This was fixed
starting in build 3.0.89.

*** 53.1:7031  Invalid device id in BacnetDevice caused exception on startup ***
  Record Type:  Bug
  Resolved In:  3.0.89
A BacnetDevice with an invalid device objectId no longer causes an exception
to be thrown on station startup.  Starting in 3.0.89, if the device objectId is
invalid, the address is not checked with the Who-Is mechanism.

*** 53.1:7053  Indication that writable proxy point is at "relinquish_default" priority ***
  Record Type:  Enhancement
  Resolved In:  3.0.90
In build 3.0.90, the status information for BACnet proxy points was changed to
reflect the point's priority level in the remote device, even when the point is
at the "relinquish default" level. In earlier builds the default priority was
not shown. Now, when Niagara is not commanding the point, and the device is
also not commanding the point, i.e., it is at its Relinquish_Default level, the
status information for the point shows "bac=def", to indicate that the BACnet
priority is default. This is in contrast to when the point is commanded at a
priority level, when the status information shows "bac=X", where X is the
active priority level.

*** 53.1:7097  Support the DM-BR-B BIBB (for Backup and Restore) ***
  Record Type:  Function
  Resolved In:  3.2.4
The NiagaraAX BACnet driver supports the BACnet Backup and Restore procedures
defined in the specification as of 3.2.4.  This conformance is identified by
the DM-BR-B BIBB claimed in the NiagaraAX PICS.

The items that are backed up during this procedure are:
* station database - config.bog
* alarm history database
* history databases
* module metadata - information about which version of each module is loaded

Note that the modules themselves are NOT backed up.


*** 53.1:7100  Points go into fault when clearing fallback value ***
  Record Type:  Bug
  Resolved In:  3.0.90
Prior to build 91, when a writable proxy point had its fallback value set, this
value was written to the device with no priority level when the Niagara point 
was at the fallback level (all inXx slots are null).  The "no-priority" write is
interpreted by the server device as a write with priority 16 (as per the BACnet
Specification).  When the Niagara client point was subsequently set to some value
at one of its input slots, the new value was written at the new level, and the
old value was cleared at the old level.  But the clear of the old level was 
written to level 17 - the fallback enumeration value, which is an invalid
priority level in BACnet.  This caused the point to take on the new value, but 
also go into fault because of the failed write on the clearing of the old value,
and the old value persisted in slot 16 of the server point's priority array.

In build 91, this has been fixed.  The old value is cleared with no priority, 
which gets interpreted as a clear at level 16, just like the original write.

*** 53.1:7130  Proxy Points don't process tuning policy changes ***
  Record Type:  Bug
  Resolved In:  3.0.91
Prior to build 3.0.91, BACnet proxy points did not properly process changes to
their tuning policy name. If their tuning policy name was changed so that they
were using a different policy, this change would not be reflected in the
point's behavior (for example, whether the point used COV or not). However,
changes to the currently used policy were still reflected. This issue has been
fixed in build 91, so that if the point is changed to use a different tuning
policy, this change is immediately reflected - the point subscribes for COV
notifications, or cancels its subscription and begins polling, as appropriate.

As a workaround for builds prior to 3.0.91, once a point's tuning policy name
is changed, the station must be restarted. When engineering a station where you
are making tuning policy changes, simply make all your desired changes during
one pass, and then restart the station so they will all be processed.

*** 53.1:7137  Enabling a second BACnet/IP port on same UDP port spews exceptions ***
  Record Type:  Bug
  Resolved In:  3.0.96
If you tried enabling a second BACnet/IP port with the same UDP port 
designation as a currently active BACnet/IP port, you got SocketException 
thread dumps spewing constantly in standard out.  This was fixed in build 3.0.96.

It is important to make sure that only one BACnet/IP port uses a given UDP port
designation.  If you attempt to enable a second BACnet/IP port on the same UDP
port, you now receive a single exception in the station output.

*** 53.1:7153  I-Am-Router-To-Network sent even if routing is disabled. ***
  Record Type:  Bug
  Resolved In:  3.0.91
When the BACnet Network is disabled from routing BACnet packets, builds prior
to 91 would still perform some routing functionality, which could potentially
cause problems with an installation.  The station would still send
I-Am-Router-To-Network messages at startup, when enabling a network port, or
in response to a Who-Is-Router-To-Network.  In addition, received
I-Am-Router-To-Network, Router-Busy-To-Network, and Router-Available-To-Network
messages would be forward to the other network ports.

In build 91, this has been fixed.  When the routingEnabled flag is FALSE,
Niagara no longer performs any routing functions.


*** 53.1:7287  Unchecking network in "Who-Has" throws exception ***
  Record Type:  Bug
  Resolved In:  3.0.92
In builds prior to 3.0.92, the Who-Has button provided a dialog allowing
configuration of the networks to be targeted with the Who-Has request.  However,
there were no network choices, as there are for device discovery.  In addition,
unchecking the "All Networks" checkbox caused an exception to be thrown when
you tried to execute the request.  This was fixed in build 3.0.92.  

Now, networks known to the station are used to populate the choices for networks.
Unchecking all of the boxes, including the "All Networks" box, no longer
causes an exception.  If no networks are selected, no request is sent.

*** 53.1:7303  Last dialog box popped up whenever you opened Device Manager ***
  Record Type:  Bug
  Resolved In:  3.0.96
When you left the Bacnet Device Manager screen and returned, the last dialog 
box that was open would re-display on the screen.  This did not mean that the
previous action was re-executed--it was a cosmetic issue only.  This was fixed
starting in build 3.0.95.1.  As a workaround in earlier builds, simply click 
either the Cancel or the OK buttons, and the popup dialog will disappear, with 
no new actions being initiated.


*** 53.1:7327  File Export Descriptors do not show up in File Export Manager ***
  Record Type:  Bug
  Resolved In:  3.0.92
In builds prior to 3.0.92, BacnetFileDescriptors placed in the Export Table, 
or in Export Folders, would not be viewable by the File Export Manager.  This 
was fixed in build 3.0.92, where file exports can now be viewed normally.

*** 53.1:7328  Log and History Descriptors not shown in Log Export Manager ***
  Record Type:  Bug
  Resolved In:  3.0.92
Prior to build 3.0.92, BacnetNiagaraHistoryDescriptors and BacnetTrendLogDescriptors
placed in the Export Table, or in Export Folders, would not be displayed in the
Bacnet Log Export Manager.  This was fixed in build 3.0.92, and now these export
descriptors can now be viewed normally.

*** 53.1:7338  Exported Object_List not properly indexed or populated ***
  Record Type:  Bug
  Resolved In:  3.0.92
Prior to build 3.0.92, the Object_List would not properly report the last two
objects in the list.  In build 3.0.92, the Object_List exposed by the
LocalBacnetDevice has been fixed.  It now properly reports the objects at all
indices in the list.

*** 53.1:7382  Poll counts inaccurate in Bacnet Poll Service ***
  Record Type:  Bug
  Resolved In:  3.0.93
In builds prior to 3.0.93, the count of polled points, devices, and objects 
in the Bacnet Poll scheduler (Poll Service) was frequently incorrect.  This 
seemed particularly likely to occur when the device switched between 
device-level and point-level polling.  In addition, the count of fast, normal,
and slow objects was incorrect.

The poll counting was fixed starting in build 3.0.93.  Switching between 
point-level and device-level polling is now properly handled in the counts.  
Whenever a change is made to the polled items, the poll count is updated at 
the next statistics update.  The interpretation of each count is as follows:

Object Count - the number of BACnet Config Objects (including
               BacnetDeviceObjects) currently being polled
Point Count  - the number of BACnet Proxy Points currently being polled, both
               individually and through device-level polling
Device Count - the number of BACnet Devices currently being polled using
               device-level polling
Fast Count   - the number of pollable items in the fast bucket.  Devices being
               polled with device-level polling are counted equal to the number
               of times they are polled to fully retrieve their data.
Normal Count - the number of pollable items in the normal bucket.  Devices being
               polled with device-level polling are counted equal to the number
               of times they are polled to fully retrieve their data.
Slow Count   - the number of pollable items in the slow bucket.  Devices being
               polled with device-level polling are counted equal to the number
               of times they are polled to fully retrieve their data.

For example, a device being device-polled, with 10 points, and a maxDevicePollSize
of 3, would be included in the Normal Count 4 times - 3 polls of 3 points each,
and 1 poll of a single point.

Whenever device-level polling fails, the maxDevicePollSize is decreased by one.
If device-level polling continues to fail, further decreases are made, until the
maxDevicePollSize reaches 1.  After this, point level polling is used.

*** 53.1:7383  Device Object polling overwhelms the Poll Service ***
  Record Type:  Bug
  Resolved In:  3.0.93
In build 3.0.93, the polling of Bacnet Config Device Objects has been modified,
to reduce the poll bandwidth usage of polling these objects.  The device objects
are subscribed, and thus polled, whenever the BacnetDeviceManager is viewed, in
order to retrieve the relevant data for the database table.  In earlier builds,
the polling of these objects would overwhelm the bandwidth available for polling,
which prevented efficient data retrieval of proxy point information.  The device
object typically contains very little important real-time information.  In light
of this, the following changes were made:

1. The Device Object no longer polls all of its properties.  Only the properties
   that might realistically change real-time are polled--this is only between 
   1-4 properties, depending on whether the device has a clock. Items like 
   Active_COV_Subscriptions may change, but are not polled.  They may be refreshed
   through the Upload action.

2. When the device is subscribed, the Device Object is only leased for a short 
   while.  This minimizes the impact to the Poll Service.

3. Other objects that have properties which don't need to be polled are allowed
   to abbreviate their polled properties list as well.  For instance, the 
   Log_Buffer of a Trend Log object is inaccessible except through ReadRange, 
   and is not polled.

This significantly reduces poll bandwidth usage for device objects.


*** 53.1:7391  Client schedule exports cannot handle read-only schedule properties ***
  Record Type:  Enhancement
  Resolved In:  3.0.93
While some BACnet devices may allow writes to any of their Schedule's properties,
other devices may hold certain properties as read-only.  If Niagara is used to
control such a schedule, it would be best to not attempt writes to the
properties that would fail, but still allow writes to the writable properties,
without causing the Schedule Export to go into fault.

In build 3.0.93, a "skipWrites" property was added to the BacnetScheduleExport.
This property is of type Facets, and its facets are the names of the properties
that can be skipped when the schedule export is writing its values.  Setting a
facet to TRUE will cause the property with that name to be *skipped* when writing
the schedule export, without causing a fault.  If a property is written, and
the write fails, this will still cause a fault, because it is desirable to know
when a write fails that was expected to be successful.


*** 53.1:7455  Default choice for adding unknown object type was device object ***
  Record Type:  Bug
  Resolved In:  3.0.96
In earlier builds, the default choice when adding a new Config BacnetObject
that was not already in the known list of object types was BacnetDeviceObject.
This was not useful, because there can only be one BacnetDeviceObject in the 
device, and this is already present as a frozen slot.  In build 3.0.95.1, this
was fixed to modify the object choice.  BacnetObject is now the default and only
choice for new objects of unknown type.

*** 53.1:7456  Default stopTime for (alarm) BacnetDestination should be 23:59:59 ***
  Record Type:  Bug
  Resolved In:  3.0.95
The default time range for the stopTime element of the timeRange parameter for 
BacnetDestination was 00:00:00.  When sent to a BACnet device with a startTime 
of 00:00:00, this implied that the range is 12:00 AM to 12:00 AM, which some 
devices will interpret as a zero-length range.  In build 3.0.95, the default 
stopTime was changed to 23:59:59.

*** 53.1:7457  Server schedules did not accept write of Out_Of_Service property ***
  Record Type:  Bug
  Resolved In:  3.0.95
In build 3.0.95, the mapping of Niagara schedules to BACnet was fixed such that
Niagara schedules exposed as BACnet schedules will now accept a write of the
Out_Of_Service property.  In prior builds, a write to this property was not
accepted.

*** 53.1:7458  The BacnetDateTime editor reset the fields when all date fields were specified ***
  Record Type:  Bug
  Resolved In:  3.0.96
The BacnetDate in BacnetDateTime, BacnetDateRange, and any other complex data
structure does not behave properly in builds prior to 3.0.96.  You can set
any three of the fields, but if you attempt to set the fourth field, the date
reverts back to the default value of all wildcards.  This is due to a bug in
the equality check for BacnetDate.  There may also be some other effects of
this bug, such as failed comparisons wherever BacnetDate is used.  This has
been fixed in 3.0.96.


*** 53.1:7459  Cannot export Niagara schedule to BACnet if it contains reference to local calendar ***
  Record Type:  Bug
  Resolved In:  3.0.98
If the source Niagara schedule for a client-side BACnet schedule export contains
a reference in its special events schedule to a calendar object local to the
Niagara station, this schedule cannot be exported completely to the remote
BACnet device.  The device will not, in general, contain the calendar that
the reference refers to.  The error that appears (in the station output) does
not clearly identify this problem.

To use a calendar reference in the special events of a Niagara schedule and
use this schedule to source scheduling data to the remote BACnet device, you
must make sure that the calendar reference refers to a calendar contained in
the remote device.  This is done by using only calendars imported from the
BACnet device.  Only CalendarSchedules contained in the same device, that
contain a BacnetScheduleImportExt with a calendar objectId are valid targets
for a calendar reference in a Niagara schedule that is sourcing data to the
remote BACnet device.

In Build 3.0.98, this has been improved.  If a schedule cannot be written to
BACnet via client-side export because the calendar reference is not in the
remote device, this message is displayed in the faultCause property.


*** 53.1:7460  Manually created device is not initialized for polling by device ***
  Record Type:  Bug
  Resolved In:  3.0.96
In prior builds, manually created BacnetDevices that were not created with a 
valid deviceId/address combination would not be properly initialized for polling
by device.  This was fixed in build 3.0.95.1.  The poll by device initialization
is accomplished regardless of the configuration status of the device, so if
the device becomes properly configured in the future, it will be able to poll
by device.

*** 53.1:7462  Manually created device doesn't upload on startup ***
  Record Type:  Bug
  Resolved In:  3.0.96
Occasionally the need arises to manually add a device.  One such scenario is
when the target device is an MS/TP slave, which cannot be discovered through 
the normal Dynamic Device Binding services (Who-Is/I-Am).  In earlier builds, 
manually added devices would not be uploaded, and so would not have their
device properties available, including segmentation support, maximum APDU
length accepted, etc.  

In Build 3.0.96 this was fixed, and a device will upload itself whenever 
critical access parameters such as objectId and address are changed, as well as
when it is subscribed.  This ensures that the properties that govern how Niagara
will communicate with this device are available when they are needed.


*** 53.1:7464  IP and Ethernet poll services need to be multi-threaded ***
  Record Type:  Enhancement
  Resolved In:  3.0.101; 3.1.6
The MSTP poll service has always been multithreaded, to allow the data link
layer to send multiple requests before giving up the token.  But the IP and
Ethernet poll services have always been single threaded, because IP and
Ethernet devices are typically much faster in responding to requests.  

However, problems can result if the device that Niagara is communicating with 
is an MSTP device that we connect to through a BACnet Router.  In this case, 
the device is polled using an IP or Ethernet poll service, but the communication
is eventually MSTP.  This can lead to significant bottlenecks when communicating
through a router to a trunk of MSTP devices.

Beginning in 3.0.100.1 and 3.1.6, the IP and Ethernet poll services are multi-threaded.  This
allows better performance, particularly in the case of a router to a separate
MSTP trunk.  Related to this, the property sheet of the Poll Service under an 
IpPort or EthernetPort now has a read-only "Number Of Threads" property.

*** 53.1:7523  Cannot create Bacnet proxy points for proprietary object types using New button ***
  Record Type:  Bug
  Resolved In:  3.0.96
In earlier builds, Bacnet proxy points could not be created with a proprietary 
object type in the objectId.  In build 3.0.95.1, the object type editor has been
modified, and the user may now select one of the Niagara-known types from the
Object Id drop-down list (analogInput, binaryValue, etc), or instead they may 
type in the numeric value of the object type into the field to select a 
proprietary object type.

*** 53.1:7524  Cannot create Bacnet Config objects for proprietary object types ***
  Record Type:  Bug
  Resolved In:  3.0.96
Config objects could not be created with a proprietary object type in builds
up to 3.0.95.  In 3.0.95.1, the object type selector was improved to allow 
entry of proprietary object types for the Object Id.


*** 53.1:7527  UDP port change not reflected in router table ***
  Record Type:  Bug
  Resolved In:  3.0.96
In builds up through 3.0.95, a change to the UDP port being used by a BACnet/IP
network port was not reflected in the router table.  This meant that the Bacnet
Network no longer had a properly configured connection to the BACnet/IP
network.  In build 3.0.95.1, changing the UDP port causes the network port to 
be disabled and then re-enabled, updating the router table, and allowing 
BACnet/IP communications to continue uninterrupted.

*** 53.1:7528  Calendar write error left export "in progress" ***
  Record Type:  Bug
  Resolved In:  3.0.96
Prior to build 3.0.95.1, a failure in writing Calendar data to a BACnet Calendar
object would leave the ScheduleExport that managed the calendar in the "In
Progress" state, preventing future updates (unless the station was restarted).
This was fixed in build 3.0.95.1, and a calendar failure is simply noted, and
the export is marked in fault, but is left in the Idle state, ready for another
attempt.

*** 53.1:7534  Import of schedule time values with unspecified values was incorrect ***
  Record Type:  Bug
  Resolved In:  3.0.96
When importing Schedule data (weekly schedule, exception schedule) from a device, the imported
time-value pairs can be incorrectly interpreted if the times contain unspecified values.  This
may happen if the device only has a clock accurate to the minute, and thus uses unspecified
values for seconds and hundredths.

This was fixed in build 3.0.95.1.  The Times are properly processed into
Niagara TimeSchedules.

*** 53.1:7544  Cannot learn point if MultiState has invalid State_Text ***
  Record Type:  Bug
  Resolved In:  3.0.96
If a discovered MultiState object has entries in the State_Text property that
are duplicates of other entries, an attempt to Add the proxy point in the
BacnetPointManager will fail, with a Details message indicating "duplicate tag".
There is no BACnet requirement that the State_Text array elements be unique, or
contain only characters that are valid for Baja enum tags.  In build 3.0.96, 
duplicate tag names are suffixed with a dot character ('.') to ensure uniqueness.

In all builds, characters that are invalid in Baja enum tags are replaced by the
escaped version of the character, ensuring a valid enum for the facets defined
by the State_Text property.

*** 53.1:7545  Point painting is slow after discovery on large device ***
  Record Type:  Enhancement
  Resolved In:  3.0.96
In builds up through 3.0.95, point discovery did not provide sufficient visual
feedback when discovering points in a device with a large object count.  When
the discovery job completed, there was a period of time where everything appeared
as it did before clicking the Discover button, meaning the points did not appear.
This can be misleading, as it may appear the job failed, and you may think you
need to click Discover again (DON'T CLICK AGAIN -- the points do eventually appear). 
Note that if you *do* click Discover again, this simply starts another discovery.

In build 3.0.96, when the discovery job completes, points now begin being
displayed immediately.  A portion of the discovered points are initially
displayed, and the others get displayed as they are brought into the Workbench.
You can observe the point count in the upper right corner of the discovery
table to see how many points have been included.  When this number stops
increasing, the discovery points have all been brought in.

*** 53.1:7548  Clear All/Select All buttons in writable slots editor ***
  Record Type:  Enhancement
  Resolved In:  3.0.96
In build 3.0.96, buttons are provided to clear and select all of the slots of the
writable points to allow BACnet writes.  This eliminates the need to carefully
click within each of the boxes to clear or select all of the slots.

*** 53.1:7550  COV Subscriptions fail under time change ***
  Record Type:  Bug
  Resolved In:  3.0.96
Prior to 3.0.96, BACnet COV subscriptions would report an incorrect time
remaining for the subscription whenever the time was changed in the station.
This could lead to a client believing it has a longer subscription lifetime
than it actually does, and potentially missing data updates.  Also, if the
time was changed beyond the subscription end time, no more notifications
would be received.  This has been fixed in build 3.0.96.  COV subscriptions 
are now independent of changes to system time.

*** 53.1:7572  BACnet priority shown for nonprioritized points ***
  Record Type:  Bug
  Resolved In:  3.0.96
In some builds, non-prioritized points such as Analog Input proxy points will
report the "active BACnet priority level", using the "bac=def" notation in the
PointManager.  This means nothing, as those points have no prioritization.
This bug has been fixed, and the active priority level only shows up for
prioritized points in Build 3.0.96 and higher.

*** 53.1:7574  MSTP points took long time to display values  ***
  Record Type:  Bug
  Resolved In:  3.0.100
When polling a large number of points using group polling, the initial data
values could take a long time to get populated.  Often, a group of points were
polled immediately, but the rest of the points could take the full poll cycle
to be updated.

This occurred because the dibs stack was not used properly to update all of 
the newly-subscribed points.  Beginning in 3.0.100 and 3.1.6, this has been 
fixed.  Whenever a point is newly subscribed, it is added individually to the
dibs stack, so it will be polled via the dibs first.  It is also added to the
regular poll list through its containing device's subscription.

*** 53.1:7621  Poll Service statistics seemed to be off ***
  Record Type:  Bug
  Resolved In:  3.0.101; 3.1.7
Beginning in 3.0.100.1 and 3.1.6.2, the poll cycle time for a multi-threaded Poll Service is
more accurate.  Prior to this build, the number of threads servicing the poll
list was not accounted for, leading to a cycle time that was off by a factor
equal to the number of threads.  Note that an MstpPort's Poll Service has
always been multi-threaded, and beginning in 3.1.6, the Poll Service for an
IpPort and EthernetPort is also multi-threaded (see issue #7464).

*** 53.1:7626  MultiState server points would not accept BACnet writes ***
  Record Type:  Bug
  Resolved In:  3.0.98
If you are using Build 3.0.89 to Build 3.0.97, points exported to BACnet as
MultiState points will not properly accept writes from BACnet.  Since Build
3.0.89, the incoming write is inspected to see if it is within the range of
valid ordinals for the point.  There is an error in the range calculation,
which results in all values being labelled "out of range".  This error has
been fixed in Build 3.0.98.

*** 53.1:7634  Cannot add proxy points for analog objects with proprietary units ***
  Record Type:  Bug
  Resolved In:  3.0.98
In builds prior to 3.0.98, proxy points for objects with engineering units 
that were in the proprietary range of the BACnetEngineeringUnits enumeration 
could not be added from the point Discovery window.  An exception would be 
displayed in the output window if an Add was attempted.  This has been fixed 
in build 3.0.98.  If the units are a proprietary extension, or are otherwise 
unrepresented in the Niagara unit database, the units are simply not added 
to that point, and the point can be added without units.

*** 53.1:7704  Router Table entries are removed erroneously ***
  Record Type:  Bug
  Resolved In:  3.0.100
When Niagara is communicating through BACnet Routers to devices on other
networks, entries will begin being removed and re-added after 24 hours of
operation.  This does not cause any direct problem, other than decreasing the
overall performance of the station, as resources are used to perform a lot of
unnecessary changes to the router table.

Beginning in 3.0.100 and 3.1.6, the router table entries have been stabilized.

*** 53.1:7708  Transport Layer did not handle queue overruns well ***
  Record Type:  Bug
  Resolved In:  3.0.100
Beginning in 3.0.100 and 3.1.6, several improvements have been made to the
Transport Layer of the BACnet driver.  The changes are all transparent to the
user, but should provide better performance in certain situations with high
packet volumes.

*** 53.1:7846  BacnetDate should handle odd_months, even_months, and last_day_of_month ***
  Record Type:  Bug
  Resolved In:  3.0.100
Beginning in 3.0.100 and 3.1.6, the BacnetDate datatype now supports the recent
additions to the BACnet specification for Dates.  The value 13 in the month
field indicates that the date includes all odd months (January, March, May,
etc.).  The value 14 indicates all even months (February, April, etc.).  The
value 32 in the dayOfMonth field indicates the last day of the month.

These numeric values do not appear in a property sheet when using the Date
(property) selector--instead, in the "month field" selections "Odd" or "Evn" 
appear for odd or even months, respectively (changeable via the lexicon, up 
to three characters).  In the "date field" the selection "LD" appears for the
last day of the month (also changeable, up to two characters).

*** 53.1:7900  CPU Usage high with large number of points exported ***
  Record Type:  Bug
  Resolved In:  3.0.100; 3.1.6
In builds prior to 3.0.99.5 and 3.1.6, the CPU usage of a station with many
objects exported to BACnet could become very high when another BACnet client
was attempting to access the station's objects.  Symptoms of this problem are
the same as for any other problem where the CPU usage is too high.  The station
becomes unable to properly handle other activities, which may lead to it not
responding to BACnet requests, or becoming unable to perform other station
activities in a timely manner.  It may also lead to spontaneous rebooting, if
the engine watchdog timer is unable to run often enough.

In general, this should only become a problem for stations with many (>100)
objects exported to BACnet.  But milder versions of the symptoms will be
displayed by stations with any number of objects exported to BACnet.

In Build 3.0.99.5, a change was made to the internal management of objects
exported to BACnet.  The access of these points was significantly improved,
leading to drastically better CPU usage by the BACnet server process.

*** 53.1:7961  Segmented packets were too long ***
  Record Type:  Bug
  Resolved In:  3.0.100; 3.1.6
When Niagara uses segmentation to break up packets that are too large for the
other device to handle, the APDU portion of the packets it sends is too large.
This can can be a problem for devices that have buffers that are exactly equal
to the maximum APDU size, and cannot hold any larger packets.

Beginning in 3.0.100 and 3.1.6, this behavior was fixed.  The packet size of
segmented messages is now within the required limits.

*** 53.1:7963  Autoing points to fallback level sends an extra write message ***
  Record Type:  Bug
  Resolved In:  3.0.100
When a BACnet proxy point is relinquished to fallback command, it may send an
extra write message.  If the point is mapping the present value of a
prioritized point (an output, or a value-type with priority), a write with a
value of null and no priority is sent immediately prior to the correct write
with a value of null and the relinquished priority level.

In many cases, this will not be a problem, because nothing else is actively
commanding at priority level 16.  If another entity has a command in the
priority array at level 16, it will be removed when Niagara autos the point.

Beginning in 3.0.100 and 3.1.6, this behavior has been fixed.  Relinquishing
the manual control of the proxy point only releases that level, and does not
affect any other levels.

*** 53.1:7971  BACnet File improvements ***
  Record Type:  Enhancement
  Resolved In:  3.0.100
Beginning in 3.0.100 and 3.1.6, several improvements were made to the BACnet
File API, used for client-side access and manipulation of File objects in
other BACnet devices:
  * Exceptions encountered while reading or writing file contents are handled
    more cleanly than before.
  * The file data can now be presented in a hex view available on the File
    object, without specifying a local file location for the data.
  * The API for programmatic read/write access to the file data has been
    improved to allow easier access.

*** 53.1:7972  Client support for Program object type ***
  Record Type:  Enhancement
  Resolved In:  3.0.100
Beginning in 3.0.100 and 3.1.6, a client representation of the BACnet Program
object is available.  This provides access to the BACnet-visible properties of
BACnet Program objects in other devices.  

*** 53.1:7989  Server-side COV subscriptions not properly registered ***
  Record Type:  Bug
  Resolved In:  3.0.101; 3.1.7
When a COV client attempted to subscribe with the Local Bacnet Device for COV
notifications on a point, in some cases the subscription was lost.  The specific
behavior was that the subscription was created, and then quickly removed, so it
did not get seen on the property sheet.

This was due to a problem in calculating the time remaining for the
subscription, and has been fixed beginning in builds 3.0.100.1 and 3.1.7.

*** 53.1:8008  MSTP COM port change requires disable/enable to effect change ***
  Record Type:  Enhancement
  Resolved In:  3.0.101; 3.1.7
Beginning in builds 3.0.100.1 and 3.1.6.2 of the BACnet driver, changes to the 
COM port being used by the MSTP link layer are automatically processed without
requiring that the MSTP port first be disabled and then re-enabled.

*** 53.1:8211  HistoryImport objectId had defaultOnClone for some properties ***
  Record Type:  Bug
  Resolved In:  3.0.101; 3.1.15
In the original release, BacnetHistoryImport components had the defaultOnClone
flag set for the objectId and localHistoryName fields.  This meant that any
time a BacnetHistoryImport was copied, these fields would return to default
values and need to be reconfigured, making the duplication or copying of a
device into a multi-step process.

Beginnning in 3.0.101 and 3.1.13, this has been changed.  BacnetHistoryImport
components now maintain their value across copy/paste, so you can efficiently
copy devices without having to configure the history object ids.


*** 53.1:8212  Local name for imported history needed to be BFormat ***
  Record Type:  Enhancement
  Resolved In:  3.0.101; 3.1.15
When importing BACnet logs, to allow easier configuration of local history
locations, a new property localHistoryNameFormat was added, that uses the
BFormat data type.  The History Import Manager was also modified to allow
you to specify this format, using the default "%device.name%-%name%", to 
index by the device and then the log name.

To allow schema (upgrade) compatibility, the old property localHistoryName 
was made read-only.

*** 53.1:8213  Automatic Trend Log Retrieval usually did not work ***
  Record Type:  Bug
  Resolved In:  3.0.101; 3.1.15
In the original release, Niagara was sometimes not able to retrieve trend log
records from BACnet devices.  The initial request from Niagara was for a
number of records equal to the maximum integer value.  While Niagara is not
actually expecting this number of records, it was simply that we did not know
how many records existed to retrieve, and we would let the device simply send
them all to us.

Field testing has revealed that some devices are unable to respond properly
to this request, and will return a response with no log items, even though
records do exist in the buffer.

In addition, if the last sequence number processed by Niagara did not match up
with the sequence numbers in the log buffer, Niagara would often have
difficulty in getting the records.  This could happen, for instance, if the
device had been reconfigured and the logs restarted, or if Niagara had not
retrieved records in a long time, so the log buffer in the device "rolled
over" and lost records.

Beginning in 3.0.101 and 3.1.13, the record retrieval has been improved.  The
BacnetHistoryImport imports a smaller number of records at a time.  And if no
records are retrieved for the original parameters, they are automatically
modified to give a better chance of getting the Niagara history synchronized
to the BACnet trend log.

*** 53.1:8214  History Import could get stuck in pending state ***
  Record Type:  Bug
  Resolved In:  3.0.101; 3.1.15
When retrieving BACnet trend log records using a BacnetHistoryImport, the
process can get stuck in an infinite loop if the import is not able to retrieve
any records.  The main symptom of this is a continual flow of ReadRange requests
to the device, where the responses continue to have an item count of zero, and
no item data.

This has been fixed in Build 3.0.101, and Build 3.1.13.  When the history import
retrieves no data, it calculates the first expected sequence number in the log,
and uses this as a new starting point.  If it continues to be unable to find any
data, it will then quit instead of continuously looping.

*** 53.1:8215  ScheduleImportExt and ScheduleExport could get stuck "pending" ***
  Record Type:  Bug
  Resolved In:  3.0.101; 3.1.15
In Builds 3.0.101 and 3.1.13, a fix was made to ensure that the state of
BacnetHistoryImport, BacnetScheduleImportExt, and BacnetScheduleExport
descriptors is set back to Idle after execution, regardless of what might
happen during the execution.  In some circumstances, the execution could get
hung up, and the descriptor would be left in a "Pending" state.  This has
now been fixed.

*** 53.1:8216  Alarms from multiple points all displayed on same line ***
  Record Type:  Bug
  Resolved In:  3.0.101; 3.1.15
Beginning in Builds 3.0.101 and 3.1.13, the alarm console will report alarms
from mapped proxy points with individual lines.  Prior to these builds, all
alarms from a particular device would be reported on the same line, and you
would need to drill down into the alarm to find out what alarms had been sent
by that device.

In Builds 3.0.101 and 3.1.13 and later, a mapped point will have its own line
in the alarm console.  Alarms from non-mapped objects will continue to be
reported on the same line, as there is no component to handle the alarm.

*** 53.1:8217  Schedule import - undetermined type was forced to String Schedule ***
  Record Type:  Bug
  Resolved In:  3.0.101; 3.1.15
When Niagara was unable to determine the type of an schedule for import, you
could be stuck with only the StringSchedule as the choice.  This is unlikely
to be the proper choice of schedule data type.  It was not possible to change
the type, either during the add, or after adding to the database.

Beginning in 3.0.101 and 3.1.13, if Niagara is unable to determine the data
type of a schedule, you are allowed to choose from any of the four schedule
types (BooleanSchedule, EnumSchedule, NumericSchedule, StringSchedule).

*** 53.1:8267  Week N Day editor needs to be more user-friendly ***
  Record Type:  Enhancement
  Resolved In:  3.0.101; 3.1.14
Beginning in 3.0.101 and 3.1.14, you can now edit BACnet WeekNDay fields with
a more convenient field editor.  Instead of having to enter hex bytes, you can
select the appropriate choices and let Niagara fill in the correct bytes.

*** 53.1:8286  Extraneous exception when exporting misconfigured MultiState point ***
  Record Type:  Bug
  Resolved In:  3.1.15
When exporting an EnumPoint or EnumWritable as a BACnet MultiState object in 
builds prior to 3.1.15, you may get an exception saying 'Could not invoke the
command "Add".', although the point is actually successfully added to the
export table.  This generally will happen because the Enum Point contains a
Facets range that includes a defined value for zero, or is non-contiguous.
                                                                                              
If the Enum Point is properly configured, with a Facets range defined for 1-N,
this error does not appear.

If you see this error, simply click the OK button to continue.  Make sure to
go to the target Enum Point and correct its range definition to start at 1,
and to contain only contiguous enumeration values up to the maximum value.  If
you had attempted to configure this point as writable by BACnet, this will not
have been successful.  Once you have corrected the configuration of the Enum
Point, it will be successfully exported to BACnet, at which time you can go
back and reconfigure its writability.

Beginning in Build 3.1.15, the exception no longer appears.  You will still
see the added export descriptor (for the Enum Point) in fault, as that point is 
misconfigured. Once you reconfigure the Facets range of the source Enum Point
correctly (range 1-N, contiguous), it will be exported correctly--however, you
still need to reconfigure its BACnet writability in its export descriptor.

*** 53.1:8316  Writable proxy points (prioritized) writing Fallback changes ***
  Record Type:  Bug
  Resolved In:  3.0.101; 3.1.17
Writable Bacnet proxy points mapping a prioritized value such as the Present_Value
property of an Analog Output did not properly track certain behaviors when the
Fallback property value changed (for example, using the point's "Set" action).

Specifically:
  * When the fallback was changed from null to a non-null value, the value was 
    written, with no priority, to the presentValue of the point.  Based on the 
    rules defined by the BACnet specification, this is interpreted by the server
    as a write to level 16 of the priority array.
  * When the fallback was changed from non-null to null, a NULL was written, with
    no priority, to the presentValue of the point.  Again, this is interpreted as
    an Auto of level 16 of the priority array.
  * When the fallback was changed from one non-null value to another non-null 
    value, nothing at all was written to the point.

This has been changed, and now the fallback is fully incorporated into the point's
state machine.  If the fallback value is non-null, it is written to the point with
no priority when it is the active value.  If the fallback value is null, and the 
priority array becomes all null, then the point is allowed to go to the value 
specified by the Relinquish_Default property.


*** 53.1:8357  Exporting points doesn't calculate next instance number correctly ***
  Record Type:  Bug
  Resolved In:  3.1.15
When exporting points to BACnet, the instance number is supposed to be automatically calculated for you,
so you don't have to figure out what instance numbers are valid, and what instance numbers have already
been used.

This works properly in some situations, but can fail if there are other folders containing points of the
same type as the points you are exporting.  If you have not yet loaded the export descriptors for the
other points into the Workbench VM by causing a subscription on these components, their objectIds will
not be properly loaded, and the resulting "next instance number" for the points you are trying to export
will be zero.

You can still enter in whatever value you wish for the instance number, but you must manually determine
an unused number in order to properly export the point, as the automatic calculation fails.

Beginning in Build 3.1.15, the instance number calculation has been fixed.  Note that this calculation
takes into account existing export descriptors that may be in fault and thus not actually exporting their
points (see issue 8286 for an example). This allows you to perform the export, and then go back and fix 
any point configuration problems without having to re-export the points with different instance numbers.


*** 53.1:8504  BacnetDate should not lexiconize in bog file ***
  Record Type:  Bug
  Resolved In:  3.0.101; 3.1.19
The BacnetDate data type was serialized (saved to the config.bog file) using
the current lexicon to define the string names of the days of the week.  So
the database would look different depending on whether the station was running
with an American lexicon or a Spanish lexicon.  This is incorrect; the station
database should be independent of any lexiconizatin.

This has now been fixed.  The serialization and deserialization of the
BacnetDate data type now always uses the same (American) weekday names.  If
you are using a different lexicon, this change is made in the presentation of
the data type to you.


*** 53.1:8616  Router Table entries removed on network misconfiguration ***
  Record Type:  Bug
  Resolved In:  3.0.102; 3.1.22
When the BACnet network is misconfigured by having multiple routers to a single
network segment, this causes floods of network traffic as each router forwards
messages to the segment, including messages that the other router(s) have
already forwarded to them.  In order to help minimize the pain associated with
this, Niagara disables its routing and disables the appropriate network port
when it detects a misconfiguration scenario.  In some circumstances, you may
want Niagara to continue to act as a router despite this misconfiguration.  For
this case, you can set the maintainRoutingEnabled flag to true.  Find this
property under Config, Drivers, BacnetNetwork, Bacnet Comm, Network.

However, this did not completely maintain the routing properties.  In
particular, the router table entries were always removed.  In addition, you may
see a message indicating that routing has been disabled, even though it is
being maintained in the enabled state.  The removal of router table entries
can cause problems for subsequent device discovery, and proper reporting of
our router table to network queries by other devices.

This has been fixed.  Now, if the maintainRoutingEnabled flag is true, the
router table entries are no longer removed.  The message indicating a network
misconfiguration is still displayed, but the message indicating that routing
has been disabled is only displayed if it actually has been disabled.

*** 53.1:8618  Removing router sometimes produces exception ***
  Record Type:  Bug
  Resolved In:  3.0.102; 3.1.22
When an entry is removed from the BACnet Network Layer Router Table, you will
sometimes see an exception.  If the entry was removed automatically, you will
see a stack trace in the output window.  If you removed the entry manually by
invoking the "removeRouter" action, you will see an error dialog box.  This
does not stop the removal of the router table entry, but it is confusing and 
may suggest something is wrong.

This has been fixed.  Now, an error message does not display unless there 
actually is a problem removing the router table entry.

*** 53.1:8620  Need to return error for read/write of non-array property with array index ***
  Record Type:  Enhancement
  Resolved In:  3.1.22; 3.2.1
If Niagara received a read or write request for a non-array property that contains an array index, it
simply ignored the array index and provided the value that the client most likely wanted.  This may be
a more forgiving way to handle the situation, but it was not compliant with the BTL (BACnet Testing 
Labs).  Niagara needs to return an appropriate error in this situation in order to achieve BTL 
certification.

Beginning in 3.1.22 and 3.2.1, all incoming reads and writes are checked to see if an array index has
been provided.  If one is provided for a property that is not an array, an appropriate error is
returned.  Sorry, sloppy clients!


*** 53.1:8621  File_Size needs to be writable for files that allow it ***
  Record Type:  Enhancement
  Resolved In:  3.1.22; 3.2.1
The File_Size property must be writable for files that allow their size to be changed by writing a
different size array through the AtomicWriteFile service.

Beginning in 3.1.22 and 3.2.1, writes to File_Size now change the file size, if the file is
writable, and the size is changeable.


*** 53.1:8622  Exported MultiState (Enum) points with alarming must have Fault_Values property ***
  Record Type:  Enhancement
  Resolved In:  3.1.22; 3.2.1
If a MultiState point supports intrinsic alarming, it must have the Fault_Values property.  Niagara
currently has a fault algorithm, but it is defined in the opposite sense from BACnet (Niagara defines
the valid values, and BACnet defines the invalid values).

Beginning in 3.1.22 and 3.2.1, Multistate (Enum) points now expose the Fault_Values property.  This 
is calculated by taking the range from the point facets, and comparing against the defined validValues.  
Values that are part of the range, but not part of validValues are included in Fault_Values.

Note that because the point can still be commanded by Niagara sources to a value outside of the range
defined by the facets, the point can still be in fault with a value not contained in Fault_Values.


*** 53.1:8635  Must support ReadRange on properties besides Log_Buffer ***
  Record Type:  Enhancement
  Resolved In:  3.1.24; 3.2.1
The ReadRange service is used to retrieve log entries from the Log_Buffer property of a BACnet trend
log.  Niagara BacnetTrendLogExts support this for the Log_Buffer property.  However, no export
descriptors support this service for any other property.  This service needs to be supported for all
properties that are lists, or arrays of lists.

Beginning in 3.1.24 and 3.2.1, this service is now fully supported.  All relevant properties will
return appropriate values for the service.  Properties that are not appropriate for the service will
return appropriate error codes.


*** 53.1:8667  Allow devices to manage usage of BACnet service requests ***
  Record Type:  Enhancement
  Resolved In:  3.2.1
(Developers Release Note)
Beginning in 3.2.1, developers subclassing the BACnet driver for their own
purposes (such as OEM extensions, or proprietary value-add solutions) can
individually manage whether Niagara will use certain BACnet services to interact
with BACnet devices.  This is ordinarily determined by the BACnet Device object
property Protocol_Services_Supported.  But in some cases, the value of this
bit string reported by the device may not match up with what services the
device actually supports.  Developers now have an override point with which
you can control this behavior.


*** 53.1:8668  Private Transfer framework support added ***
  Record Type:  Enhancement
  Resolved In:  3.2.1
(Developers Release Note)
Although BACnet is an open protocol, a framework exists within BACnet for vendor-proprietary data payloads
inside BACnet messages.  This is the Private Transfer message system.

Beginning in 3.2.1, a Private Transfer framework is available for developers building applications that
extend the Niagara BACnet driver framework.  If you have a need for Niagara to either send or receive BACnet
Private Transfer messages (confirmed or unconfirmed), you can use this framework to register with the
Niagara comm stack to receive any private transfer messages by vendorId.  You can also send Private Transfer
messages using new APIs available on the comm stack.


*** 53.1:8675  Provide an API for applications to use the BACnet stack ***
  Record Type:  Enhancement
  Resolved In:  3.2.7
Beginning in 3.2.7, applications can use the bacnet API to send and receive BACnet messages
using the communications stack that is part of the Niagara BACnet driver.  The API in
javax.baja.bacnet.io.BBacnetComm provides methods for all commonly used BACnet service
requests.

As of 3.2.7, the following rarely used services are not included:

* authenticate, requestKey
* vtOpen, vtClose, vtDate
* readPropertyConditional
* confirmedTextMessage, unconfirmedTextMessage
* lifeSafetyOperation


*** 53.1:8718  Timestamp not accepted properly in alarm ack from BACnet client ***
  Record Type:  Bug
  Resolved In:  3.1.24; 3.2.1
In certain cases, Niagara would not accept a BACnet client's acknowledgement of an
event notification that had previously been sent to the client.  This involves
a Niagara control point that has been exported to BACnet, and that has an
alarm extension on it to generate Niagara alarms.  The BACnet client is
configured in the Alarm Service as a BacnetDestination, linked to one or more
Alarm Classes, which are themselves exported to BACnet as Notification Classes.
The point in Niagara transitions to offnormal, and then back to normal.  The
BACnet client acknowledges first the alarm, and then the to-normal transition.
The acknowledgement of the to-normal sometimes fails with an INVALID_TIME_STAMP
error being sent back to the client, despite a correct timestamp having been
provided by the client.

In 3.1.24 and 3.2.1, this behavior has been fixed.  Alarm acknowledgements are
now handled properly.


*** 53.1:8734  Include down status in the fault status bit of exported objects ***
  Record Type:  Enhancement
  Resolved In:  3.1.24; 3.2.1
When points from a driver network are exported to BACnet, there is no way to communicate the "down"
status of the points to a BACnet client, because there is no down bit in BACnetStatusFlags.  Therefore,
it would be helpful if the down status could be included in the determination of the "fault" bit, as
this bit is a union of multiple conditions that can generate a fault.

Beginning in 3.1.24 and 3.2.1, this enhancement has been implemented.  When a Niagara control point is
exported to BACnet, the point's down status is merged into the FAULT bit of the BACnet Status_Flags
reported for that point.  The down status is typically set by a device driver under which this point
is a proxy point.

*** 53.1:8748  Cannot make object exported to BACnet writable after move ***
  Record Type:  Bug
  Resolved In:  3.2.4
When a control point is exported to BACnet with write capability, it has links to each input slot
that is configured for writability.  If the point is then moved, the export descriptor is removed
from the export table.  But the links are left in place, so when the point is then re-exported in
its new location, you cannot make it writable without first removing (cleaning up) the old links.

This has been fixed in 3.2.4.  When an exported control point is moved, its export descriptor is
still removed, but the links are also cleaned up, so when it is re-exported, you can make it
writable.


*** 53.1:8749  Could not view multiple alarms from BACnet sources ***
  Record Type:  Bug
  Resolved In:  3.1.24; 3.2.1
When multiple alarms came in from the same BACnet source, these could not be 
viewed in the console or the Alarm DB Maintenance view.  The newer alarms 
replaced the old alarms.  Only one line per source would appear in the database
maintenance view.

Beginning with the alarm improvements of 3.1.24 and 3.2.1, this has been 
improved.  Incoming event notifications with a toState of offnormal (or any 
specific offnormal state) or fault will create a new Niagara alarm record. 
Incoming event notifications with a toState of normal will check the buffer 
appropriate for their original toState.

*** 53.1:8750  BacnetDestination did not resolve address form of recipient ***
  Record Type:  Bug
  Resolved In:  3.0.102; 3.1.24; 3.2.1
The recipient portion of the BacnetDestination can be either a deviceId or a BACnetAddress.  If the
deviceId form is used, this needs to be resolved to an address in order to send the request to that
destination.  So Niagara does a Who-Is to get the address from the resulting I-Am.  But in the case
of event notifications, the maximum APDU size acceptable is also needed.  This is retrieved from
the I-Am in the deviceId case, but it is also needed for the address case.  So a Who-Is needs to be
sent in either case.

Beginning in 3.0.102, 3.1.24, and 3.2.1, Niagara sends a Who-Is to fully resolve BacnetDestination
information for all cases.


*** 53.1:8754  Points exported by slotpath did not display writability correctly ***
  Record Type:  Bug
  Resolved In:  3.0.102; 3.1.24; 3.2.1
When points are exported to BACnet using the slot path ord instead of the 
handle ord, the configuration of the writability has no effect on the actual 
writability of the point.  However, points exported using the slot path method
could not appear writable with the selected "in" slots. 

Beginning in 3.0.102, 3.1.24, and 3.2.1, this has been fixed.  The slot path ord
is now handled correctly, and the writability of exported points is managed 
with either slot path or handle choice for the export ord.

*** 53.1:8779  Poll thread spins if Poll Service rate is 0 seconds ***
  Record Type:  Bug
  Resolved In:  3.1.24; 3.2.1
If the Poll Service for any NetworkPort under the Bacnet Comm has its Fast Rate, 
Normal Rate, or Slow Rate configured to 0 seconds, and there are no points 
subscribed to poll, its poll thread will spin.  Note that the typical defaults
for these rates are non-zero values.  A separate but related issue (8553) applies
to the single Poll Service used in other driver networks.

Beginning in 3.1.24 and 3.2.1, a check was inserted to prevent this behavior.  
As a workaround in 3.0, avoid this problem by ensuring that the poll rates are
always greater than zero.

*** 53.1:8805  Gray out (dim) Add button on export manager when appropriate ***
  Record Type:  Bug
  Resolved In:  3.2.4
If a component does not have an export object registered as an agent, it appears grayed out
(dimmed) in the discovery table.  The Add button is grayed out unless there is at least one 
object selected in the discovery table that is exportable.


*** 53.1:8806  Choosing histories to export causes strange behavior in export manager ***
  Record Type:  Bug
  Resolved In:  3.2.12
If you select Histories as the root for a discovery from the
BacnetExportManager view (the regular one, not the history export manager),
the slot path and type will constantly flash with data, and not stop until you
perform a new discovery with the correct root.  The Bacnet Export Manager is
only for exporting components out of the station database.  To export logs or
histories, use the Bacnet Niagara Log Export Manager.

Beginning in 3.2.4, selecting an inappropriate root for the export manager
discovery will have the same effect as simply canceling the discovery, without
causing any unusual behavior in the discovery table.

*** 53.1:8808  Need to respond to ReadProperty request for wildcard deviceId ***
  Record Type:  Enhancement
  Resolved In:  3.1.24; 3.2.1
The BACnet specification requires that a device respond to read requests for an object identifier with
the device object type, and the wildcard instance number of 4194303.  This would allow a client to
learn our deviceId without a Who-Is.

Beginning in 3.1.24 and 3.2.1, Niagara will now respond to read requests with the wildcard instance
number for the device object.


*** 53.1:8809  Ack Notification sent even if alarm ack failed ***
  Record Type:  Bug
  Resolved In:  3.1.24; 3.2.1
If an AcknowledgeAlarm request is received for an outstanding alarm, the ack
notification should only be sent to recipients if the acknowledgement
succeeded.  If the ack failed for some reason (e.g., an invalid time stamp),
no ack notification should be sent to recipients.

This has been fixed in 3.1.24 and 3.2.1.  The processing of events and
acknowledgements has been improved too comply more fully with the BACnet
specification.

*** 53.1:8816  Event_Time_Stamps not reported correctly ***
  Record Type:  Bug
  Resolved In:  3.1.24; 3.2.1
There are some problems with the calculation of the Event_Time_Stamps property elements for BACnet
export descriptors:

1.  The TO-NORMAL element of the Event_Time_Stamps property must retain the time of the last to-normal
    transition.  When a Niagara alarm source ext experiences a new to-fault or to-offnormal transition,
    it clears the to-normal time, which is reflected in the BACnet export descriptor.

2.  Any time that is not initialized needs to use the wildcard values x'FF' in all fields.  The Niagara
    value for an uninitialized BAbsTime is 1/1/1970 00:00:00, or 12/31/1969 19:00:00 for EST.

Beginning with the alarm improvements of 3.1.24 and 3.2.1, this behavior has been fixed.  The TO-NORMAL
element of the array is the later of the last fault-to-normal time and the last offnormal-to-normal time.
Uninitialized BAbsTime values will use wildcards when encoded to BACnetTime.


*** 53.1:8820  Alarm not sent to second recipient if first one fails ***
  Record Type:  Bug
  Resolved In:  3.1.24; 3.2.1
If an alarm class is configured with multiple BacnetDestination recipients, and an alarm cannot be sent
to the first recipient, the alarm is not sent to the second recipient.  This means that no BACnet
clients would receive the alarm.

In 3.1.24 and 3.2.1, this has been fixed.  The timing problem has been resolved and Niagara will now
attempt to send BACnet event notifications to all configured recipients, even if the attempt for a
previous recipient failed.


*** 53.1:8831  AcknowledgeAlarm needs to check for invalid acks ***
  Record Type:  Bug
  Resolved In:  3.2.1
When an AcknowledgeAlarm request is received for an outstanding alarm that has been sent to BACnet, we
need to check all of the following conditions before validating the alarm and sending the Result(+) and
ack notification:
  1 timestamp in ack must match alarm record timestamp to .01 sec
  2 event object id in ack must match object id in alarm record
  3 event state acknowledged in ack must match the alarm record's alarmState
  4 acknowledgingProcessId in ack must match the processId to which we sent the alarm

Originally only the timestamp, and the object id were checked.  Beginning in 3.2.1, all 4 requirements
are verified before the alarm is acknowledged.  Also, when the point in Niagara has already transitioned
to normal at the time the acknowledgement of the offnormal event is received, both transitions had
been removed.  This has also been fixed, so that the normal transition remains outstanding, if its
transition type requires an acknowledgement.


*** 53.1:8838  Bnworker thread high CPU usage when using client-side COV ***
  Record Type:  Bug
  Resolved In:  3.0.102; 3.1.24; 3.2.1
When Niagara was using client-side COV subscriptions to update data from other 
devices, the Bnworker thread (usually the second one, there are two) could consume
large quantities of CPU time, especially if the server devices were sending 
frequent COV notifications.  This was due to an inefficiency in the management 
of the devices and points.

Beginning in builds 3.0.102, 3.1.24, and 3.2.1, the management mechanism has
been improved, and the related CPU usage has been drastically reduced. 


*** 53.1:8839  COV notifications sent for Boolean points without changes ***
  Record Type:  Bug
  Resolved In:  3.0.102; 3.1.24; 3.2.1
When a Boolean control point is exported to BACnet, and the BACnet export has a COV subscription, a
COV notification is sent whenever the point's value is set, even if the value is not a change.  This
occurs when the exported point may be from another driver, and the normal data update mechanism for
the driver sets the value with the same value as before.  The problem also exists for Numeric and Enum
control points.  One of the typical reasons for the change is when the active level changes from one
level to another.  The status hasn't changed, and the value hasn't changed, but the change in the
facets associated with the status drives a COV notification.

This has been fixed beginning in 3.0.102, 3.1.24, and 3.2.1.  A Niagara station serving data via COV
to a COV client will no longer produce the extraneous COV notifications.


*** 53.1:8883  Need better tracking of Time Synch requests ***
  Record Type:  Enhancement
  Resolved In:  3.0.104; 3.1.25; 3.2.1
Beginning in 3.0.104, 3.1.25, and 3.2.1, TimeSynchronization requests received
by Niagara from BACnet clients are now better managed and controlled.  In 3.0,
there is a check for the boolean property "timeSynchAllowed".  If this (dynamic)
property exists and is true, the time synchronization is allowed and the host
clock is modified by the requested amount.  If the property exists and is false,
the request is ignored.  If the property does not exist, then the request is
allowed.  In 3.1 and 3.2, this is a frozen slot, so it always exists, and it
governs the acceptance of the requests as above.  Any time a time synch request
modifies the host clock, an entry is added to the Audit Log containing the old
and new times, as well as the source address of the time synch request.

*** 53.1:8929  Calendar references not handled properly in some imported schedules ***
  Record Type:  Bug
  Resolved In:  3.1.30; 3.2.5
When a remote schedule is learned, and the schedule contains references to calendar objects, these
objects are not properly learned by Niagara, and can lead to exceptions in the output.  In addition,
the remote schedule is not fully represented in Niagara, which could lead to confusion and incorrect
behavior.

In 3.1.30 and 3.2.5, this has been fixed, and calendar references are now correctly handled in
Niagara.  If a schedule special event references a calendar that is not currently either imported
into Niagara or exported by Niagara, a new calendar import is created and read in so that Niagara
will be able to resolve the reference.

*** 53.1:8930  Cannot determine Trend Log Type if Trend Log object has no records ***
  Record Type:  Enhancement
  Resolved In:  3.2.2
When a trend log in a remote device does not contain any records, Niagara cannot determine the log
type to use.  A type must be chosen, because Niagara logs are typed, rather than generic.  So, when
you attempt to add the log, your are forced to pick something, and you've got a 1 in 4 chance of
guessing the correct type.

This has been improved.  Now Niagara checks the Log_DeviceObjectProperty of the log, which gives
the BACnet objectId, propertyId, and optionally an array index, or a device objectId.  Using this
information, the log type can often be inferred, even when the log buffer contains no records.

Note that if the log object is completely unconfigured, you will need to use the Config Device Ext
to create a client Trend Log object for the log, and configure it with the desired parameters,
before you will be able to import it successfully using the Log Import Manager.


*** 53.1:9003  COV subscription failures were not handled properly ***
  Record Type:  Bug
  Resolved In:  3.0.105; 3.1.30; 3.2.8
When Niagara is using COV to acquire point data, and a failure is experienced
in trying to subscribe for COV notifications with a BACnet server device,
this can cause the point to be improperly added to the poll service multiple
times.  The result is the poll point count increments continuously, despite
a constant number of polled points.  This eventually leads to the station
needing to be restarted, or restarting itself due to CPU watchdog timeouts.

This behavior has been fixed.  COV failures now simply fall back to polling,
adding the point a single time to the poll service.  An interim solution, for
stations experiencing the rapidly incrementing point count, but which have not
yet been upgraded to the necessary build, is to set the BACnet tuning policies
to always poll for point data.

*** 53.1:9006  BUFFER_READY algorithm needs to use DeviceObjectPropertyReference ***
  Record Type:  Bug
  Resolved In:  3.1.26; 3.2.2
Beginning in 3.1.26 and 3.2.2, a bug has been fixed in the handling of the
BACnet BUFFER_READY event algorithm, that in certain circumstances could
prevent Niagara from properly processing a BACnet event notification that a
remote device's Trend Log object had reached its notification threshold and
needed archiving.


*** 53.1:9008  Polling needs to fall back to ReadProperty when ReadPropertyMultiple fails ***
  Record Type:  Bug
  Resolved In:  3.0.104; 3.1.26; 3.2.2
When polling fails in using ReadPropertyMultiple, the poll mechanism did not
fall back to using ReadProperty, if the device claimed to support using
ReadPropertyMultiple.  This prevented polling from working correctly when a
device could not handle the message the way Niagara sent it, or if the device
claimed to support ReadPropertyMultiple, but in fact did not.

This has been fixed as of 3.0.104, 3.1.26, and 3.2.2, and the usage of
ReadPropertyMultiple is dynamically adjusted by the driver.  If you find that
the driver has fallen back to using ReadProperty, a manual upload of the device
will fix this, if the device claims support for ReadPropertyMultiple.

*** 53.1:9011  Log_Interval did not accept writes properly ***
  Record Type:  Bug
  Resolved In:  3.1.26; 3.2.2
The writing of the Log_Interval property was not implemented properly.  This
results in acking the write, but the actual log interval was not changing.

This has been fixed in Build 3.1.26 and 3.2.2, and the log interval is now
modified when a write for the Log_Interval property is received.

*** 53.1:9012  Could not add recipient using WriteProperty ***
  Record Type:  Bug
  Resolved In:  3.2.2
When Niagara is unable to use AddListElement to add a BACnetDestination to the 
Recipient_List of a Notification Class object in a remote device, the intent is to fall
back to reading the Recipient_List property using ReadProperty, and then using
WriteProperty to write a new list, which contains the original list plus the desired
addition.  However, due to a bug, the WriteProperty mechanism would not even be
attempted.  Beginning in 3.2.2, this behavior has been fixed and the ReadProperty/
WriteProperty two-step process will be used when AddListElement fails, or unavailable
due to lack of support by the remote device.

*** 53.1:9013  Stop device upload after timeouts ***
  Record Type:  Enhancement
  Resolved In:  3.0.104; 3.1.26; 3.2.2
When uploading a device that is not available, the upload simply goes on to the next property when a
property request times out.  This holds up the worker thread by uploading properties individually, and
it is often difficult to tell why these requests for device properties continue to be sent by Niagara,
even after the object has been removed from the station.

Beginning in 3.0.104, 3.1.26, and 3.2.2, timeouts during an upload failure will first fall back to trying
to read the properties individually, but if a timeout is encountered during this phase, the upload stops,
and the device is pinged to verify its status.  The biggest change you will see is in the device manager,
when there are one or more devices down.  The failure of one device should not hold up processing for the
other devices any longer.


*** 53.1:9067  Writable Bacnet proxy points can get stuck, unable to write ***
  Record Type:  Bug
  Resolved In:  3.0.104; 3.1.28; 3.2.2
BACnet Writable Proxy Points can get stuck in a mode where they will not write their value.  This
situation can occur when there are large numbers of writable proxy points in the station, all set to
write their value on startup (configured in the points' tuning policies).  Thus, at station startup a
large number of writes flood the network, and this may cause an overflow of the network's write queue.
Any point that does not get its write posted due to a queue overflow will get stuck.

To determine if a point is stuck, go to the Property Sheet of the control point and right-click on the
proxyExt, and select Views > Spy Remote.  At the top of the spy page are several fields related to the
reading and writing of the proxy point's value.  The writePending flag indicates if the point thinks it
is currently "in the middle" of performing a write.  This should only be true momentarily until the
write is completed.  If the writePending flag is true on a point, it usually means the point is "stuck".

Steps for a temporary workaround for versions prior to 3.0.104:
* if the point is stuck with writePending=true, invoking the forceWrite action
  on the proxyExt will clear this state and issue a write of the current
  writeValue.
* only use Writable proxy points when the point will actually need to be written - probably a good
  practice anyways.
* make sure that the writeOnStart flag is set to false in all tuning policies.
* increase the queue size of the network writeWorker.


*** 53.1:9088  API support added for CreateObject & DeleteObject initiation ***
  Record Type:  Enhancement
  Resolved In:  3.2.2
(Developer Release Note)
As of 3.2.3, the NiagaraAX BACnet comm stack provides an API for applications
to send the BACnet CreateObject and DeleteObject service requests.  At this 
time, the NiagaraAX BACnet driver does not use these requests.

*** 53.1:9165  Exports go into fault after connecting with Workbench with missing module ***
  Record Type:  Bug
  Resolved In:  3.1.29; 3.2.3
If you connect to a station with BACnet exports that source from a module that you do not have in your
local Workbench, it sets the export descriptors into fault, with the fault cause "Cannot find the exported
point".  The point is not actually misconfigured, but because your local Workbench (with the missing
module) got an exception trying to load the point, it drives the point into fault.  This can only be
cleared by re-exporting the point or restarting the station.  Other Workbench connections that have
the correct module will see the point go into fault, as the change is actually made in the station
database.

As of 3.1.29 and 3.2.3, this has been fixed.  A Workbench that does not contain the needed module
will still not be able to view the component, and the output will show up as "Invalid Ord!".  However, the
station's database is no longer affected, and other Workbench connections (that have the module) will be 
fine.  The solution is to simply install the missing module and restart Workbench.

*** 53.1:9299  Bacnet History Import cannot handle unsigned log records ***
  Record Type:  Bug
  Resolved In:  3.0.105; 3.1.30; 3.2.5
If the remote Trend Log contains records of type Unsigned, the history import cannot import the logs,
and it generates a ClassCastException trying to initialize the trend log record.

This has been fixed in 3.0.105, 3.1.30, and 3.2.5.  Unsigned records are now handled properly.

*** 53.1:9300  History names get changed on upgrade from 99 to 101 or greater ***
  Record Type:  Bug
  Resolved In:  3.0.105; 3.1.30; 3.2.5
If you created a BacnetHistoryImport in a station running 3.0.99 or earlier, and then upgrade the
station to any of the 3.0.101 through 3.0.104, the name of the local history will be changed.  This
is probably not the desired behavior.  In 3.0.105, 3.1.30, and 3.2.5, this has been fixed.  History
names will remain the same on upgrade.

*** 53.1:9368  BBMD does not forward messages from Foreign Device ***
  Record Type:  Bug
  Resolved In:  3.0.106; 3.1.30; 3.2.5
When Niagara is acting as a BBMD and has a foreign device (FD) in its table, and the FD sends a 
Distribute-Broadcast-To-Network message to Niagara, it does not forward the message to the local 
subnet.  The message is forwarded to any BBMDs and FDs in the respective tables.

This has been fixed in 3.0.106, 3.1.30, and 3.2.5.  Distribute-Broadcast-To-Network messages 
result in Niagara forwarding the message to all intended recipients.

*** 53.1:9788  Cannot read non-primitive data in proxy points ***
  Record Type:  Bug
  Resolved In:  3.0.107; 3.1.31; 3.2.12
Although all the properties of BACnet objects are shown in the discovery pane of the Point Manager,
non-primitive data cannot be simply mapped into a String proxy point.  Note that all data is normalized
in Niagara into Numeric (double), Boolean, Enum, or String points.  So, anything that does not fit
into one of the first three types is represented with a String point.  So compound data, such as a
BACnetDateTime, would need to be represented with a String proxy point.  Unfortunately, this does not
work, because the decoding of compound ASN data in a String proxy point is incorrect.  A String proxy
point created on this type of property will go into fault, with a Read Status indicating an ASN
error.

This has been fixed in 3.0.107, 3.1.31, and 3.2.12.  Compound data can now be read into String
proxy points.  If you wish to interact with compound data in a higher fidelity fashion, you may want
to use Bacnet Config objects.


*** 53.1:10334  Invalid network number 0 should cause fault ***
  Record Type:  Bug
  Resolved In:  3.2.17; 3.3.5
The value of 0 is invalid for the networkNumber property of a BNetworkPort 
(IpPort, EthernetPort, or MstpPort). The valid range is is from 1 to 65534.
If a networkNumber is set to 0, the NetworkPort now will indicate this invalid
configuration by going into a status of {fault}.

*** 53.1:10620  Messages with HopCount=0 incorrectly forwarded ***
  Record Type:  Bug
  Resolved In:  3.2.17; 3.3.5
In compliance with the BACnet specification, incoming messages with a Hop Count
of zero are no longer forwarded.

*** 53.1:10621  Router messages processed when not a router ***
  Record Type:  Bug
  Resolved In:  3.2.17; 3.3.5
When Niagara is not acting as a BACnet Router, it now will ignore all messages
directed toward a routing entity.  This includes Initialize-Routing-Table,
Establish-Connection-To-Network, and Disconnect-Connection-To-Network.

*** 53.1:10713  Handling of unknown network layer message types ***
  Record Type:  Bug
  Resolved In:  3.2.17; 3.3.7
When Niagara receives an unknown network layer message type, it now will
respond with a Reject-Message-To-Network NPDU, in compliance with the BACnet
specification.  However, if the Niagara station is not the eventual destination
of the packet, it is simply routed to the next router on the way without being
rejected, also in compliance with the specification.

*** 53.1:10762  GetEnrollmentSummary returns ABORT ***
  Record Type:  Bug
  Resolved In:  3.2.17; 3.3.8
The BACnet server previously did not handle GetEnrollmentSummary requests when
the enrollmentFilter option was used.  When this error occurred, you would see
an ArrayIndexOutOfBoundsException appear on the station output, and the BACnet
response would be an Abort-PDU.  This has been corrected, and is now handled
properly.

*** 53.1:10763  Exported Schedule writes value instead of null ***
  Record Type:  Bug
  Resolved In:  3.2.17; 3.3.8
When you export a Niagara schedule as a BACnet schedule, and configure it to
write to an external BACnetDeviceObjectPropertyReference, the value written
will be the value of the output property, regardless of the status bit.  In
cases where the output of the schedule is null, the value written to the BACnet
target should be NULL.  This has been corrected and is now written correctly.

*** 53.1:10782  Trend Log sequence number skipped in some cases ***
  Record Type:  Bug
  Resolved In:  3.2.17; 3.3.8
When the Log_Buffer of a BacnetBooleanIntervalTrendLogExt is cleared shortly 
before a new record is collected to the log, the next regularly scheduled collection
does not occur.  However, the sequence number still increments, resulting in a gap in
the sequence numbers of the collected records.  In addition to being a violation
of the BACnet specification, this also causes incorrect responses to subsequent
ReadRange attempts to access the Log_Buffer.  Requests to read the buffer may
potentially get handled improperly, and the response will be only a single
record, even though multiple records that match the request may exist in the
history.

This has been corrected, and the sequence number rules are now correctly
followed.


*** 53.1:10787  Event_Time_Stamps shown for exported point when event has not occurred ***
  Record Type:  Bug
  Resolved In:  3.2.17; 3.3.8
When an exported point has not yet undergone a particular alarm transition, the
corresponding entry in the BACnet Event_Time_Stamps array should contain all wildcards,
but instead, it contained the default value for Niagara BAbsTime.  This has been
corrected.

*** 53.1:10801  Exported Schedule writes with incorrect datatype ***
  Record Type:  Bug
  Resolved In:  3.2.17; 3.3.9
Niagara schedules that are exported to BACnet can be configured to write their
output to external BACnet objects in the List_OfObjectPropertyReferences.
Previously, Enum schedules always wrote with an ASN data type of ENUMERATED, and
Boolean schedules always wrote with a data type of BOOLEAN.  These types did
not really work for most realistic situations, since Niagara Boolean schedules
usually would be used to configure BACnet Binary-type objects, which use a
Present_Value of type ENUMERATED.  And Enum schedules often controlled Multistate
objects, which use a data type of Unsigned, although they may potentially also
control ENUMERATED type objects.

This has been changed.  When an exported schedule is writing its value to a BACnet
object, it uses the data type of the property to identify what ASN data type to use.
Enum schedules can write to BOOLEAN, Unsigned, or ENUMERATED data types, and
Boolean schedules can write to BOOLEAN or ENUMERATED data types.


*** 53.1:10885  BacnetDate year conversion problems ***
  Record Type:  Bug
  Resolved In:  3.2.18; 3.3.12
BACnetDate objects were not displayed properly if the year was greater than
2028.  This has now been corrected.

=========================================================================
53.2  Open
=========================================================================

*** 53.2:6234  Improperly adding a new router produces error messages ***
  Record Type:  Bug
  Resolved In:  
When adding a BACnet Router to the network layer router table, you must enter
a value for all fields, or you will receive an error dialog.

*** 53.2:6378  BACnet Ip Port Link editor does not show adapters ***
  Record Type:  Bug
  Resolved In:  
In some situations, the field for selecting the TCP/IP adapter to use for
BACnet/IP communications shows simply "none", with no drop-down selection,
even though there are adapters available for use.  In this case, the selection
can be made by selecting the field, and pressing the down arrow to bring up
the list of available adapters.

*** 53.2:6604  Point learn does not expect properties from different protocol revisions ***
  Record Type:  Bug
  Resolved In:  
When learning points in a BACnet device, Niagara will expect the properties
to exist that are required as of Protocol Revision 4 of the BACnet
specification.  Certain properties that were either newly created or made
required as of this protocol revision may not be present in older devices.  In
this case, Niagara will simply display an error when it attempts to read this
property.


*** 53.2:7445  Export table object remains if source's parent is deleted ***
  Record Type:  Bug
  Resolved In:  
If an object that is exported to BACnet is explicitly removed, the BACnet
export descriptor that maps it to BACnet is automatically deleted.  However, if
the object is indirectly removed because its parent was removed, the export
descriptor remains in the table.  The export table shows "Invalid Ord!" for the
Target Name and Value columns.  The export descriptor may be removed directly
from the table by using the Delete button or right-click option.

This behavior may be improved in a future release.

*** 53.2:9005  Improved handling of BACnet object upload failures ***
  Record Type:  Bug
  Resolved In:  
When Niagara receives an error attempting to upload a BacnetObject, the handling
of the errors needs improvement.

When a timeout occurs in attempting the upload using ReadPropertyMultiple,
Niagara will attempt to upload the properties individually.  Then if additional
timeouts occur (which is a likely scenario), the full timeout period is taken for
each property.  This can tie up the asynchronous request worker for a long time,
and lead to confusing results while observing the DeviceManager, for example.

When an error is returned trying to upload an array property, the property
needs to be read in groups, or at least individually if this is possible.

When a Reject or Error is received from the BACnet device, Niagara needs to fall
back to ReadProperty, just as it does when an Abort is received.

When the device does not support ReadPropertyMultiple at all, or it is completely
unsuccessful, there needs to be a way to retrieve any optional properties that
may exist on objects in the device.

This situation will be addressed fully in a later build.  As of 3.1.26 and 3.2.2,
some improvements have been made.  Timeouts during the upload will now stop the
upload, which should prevent the asynchronous worker thread from being tied up
when the DeviceManager screen is opened, and a particular device is offline.

#########################################################################
54  bacnetws
#########################################################################

=========================================================================
54.1  Fixed
=========================================================================

*** 54.1:7098  BACnet Workstation ***
  Record Type:  Function
  Resolved In:  3.1.6
Beginning in 3.1.6, a PC station can be configured as a BACnet Workstation, 
using a "bacnetws" module, in addition to the bacnet module.  The host PC must
be licensed for both features: bacnet and bacnetws.  This provides functionality
corresponding with the BACnet Specification Operator Workstation (B-OWS) Device
Profile. As such, this station can be used in integrating an entire site of 
BACnet devices. Note that limits for number of devices, proxy points, schedules,
histories, and so on are defined in the "bacnet" feature of the PC's license.

The relevant module is the "bacnetws", which contains a BacnetWsNetwork used in
place of the BacnetNetwork.  The BacnetWsNetwork allows either BacnetWsDevices, 
or the standard BacnetDevices. To make use of WS-specific features, devices 
must be mapped as BacnetWsDevices. The device manager for the BacnetWsNetwork 
provides advanced functionality for BacnetWsDevices, including actions to "Get 
Event Information", "Get Enrollment Summary", "Comm Control", and "Reinitialize
Device".

One area that is not yet available is the Backup and Restore procedure.
Once the SSPC finalizes the improvements to this feature that will allow full
interoperability, this functionality will be added.

*** 54.1:8218  One-shot time sync broadcast to BACnet network added ***
  Record Type:  Enhancement
  Resolved In:  3.0.101
Beginning in 3.0.101 and 3.1.13, the Bacnet Workstation module has the
capability to send the time to the BACnet network.  This is available as a
button on the menu bar and tool bar of the BacnetWsDeviceManager.  When you
click this button, you are asked to choose between a broadcast of the current
time in the local time zone, or UTC.  The time is then sent as a one-time
broadcast to the BACnet network.

*** 54.1:8908  ReinitializeDevice action on BacnetWsDevice fails silently ***
  Record Type:  Bug
  Resolved In:  3.0.103; 3.1.25; 3.2.1
When the ReinitializeDevice action is invoked on a BacnetWsDevice, and the command fails (improper or
missing password, service not supported, etc.), the failure mode is silent.  A message is displayed in
the station output, but users are not generally looking at this to see the failure message.

This has been fixed in 3.0.103, 3.1.25, and 3.2.1.  When the action fails, a dialog is presented to
the user indicating the failure reason.  This has also been fixed for Device Communication Control.

*** 54.1:9000  BACnet Supervisor can send time synch globally or just to local network ***
  Record Type:  Enhancement
  Resolved In:  3.1.28; 3.2.3
The manual Time Synch command allows for a local/UTC choice for the type of time synch request to be
sent.  Beginning in 3.1.28 and 3.2.3, there is also a choice of whether the request will be sent only
to the local network, or with network headers indicating to forward it globally to all connected
networks.

#########################################################################
55  basicdriver
#########################################################################

=========================================================================
55.1  Fixed
=========================================================================

*** 55.1:7599  queueFullException causes points to never write ***
  Record Type:  Bug
  Resolved In:  3.0.96
Drivers with proxy points having proxyExts extending from BBasicProxyExt class
(most serial-based drivers) were found to have a possible write failure issue,
where a point's proxyExt could be left in a write pending state.  Although
rare, this could occur if an extremely large number of points attempted to write
at the same time. In this case, the driver's write worker queue would fill, the
point's write request would fail to post, and its proxyExt would be left
in the write pending state.  In build 3.0.96, this was fixed such that failed
write request posts do not leave the proxyExt in this state.

Drivers *not* affected by this include bacnet, lonworks, ndio, opc, and snmp.
Some drivers that *are* affected include: andover, everex, flexSerial, 
hotellink, modbus, omronhostlink, php, slimline, x10.

*** 55.1:7617  Generate log message for point write failures in legacy drivers ***
  Record Type:  Bug
  Resolved In:  3.0.98; 3.1.1
This change, starting in 3.0.98, affects mostly legacy (serial based) drivers.
It applies to any proxy point with a ProxyExt extended from BBasicProxyExt 
class (from Basic Driver). 

If an unsuccessful attempt is made to write the value of a point in a field 
device, a log message is sent to the appropriate driver's network log, where 
it appears in the station's LogHistory.
                      
Before build 98, if a failed write was ever followed by a successful write
to a field point, then there was no record of the failed attempt.  Although 
the control point's status would have been set to "down", the subsequent 
successful write to the field point would have cleared the "down" status.

*** 55.1:7843  Write coalescing was faulty (used first in, not last in) ***
  Record Type:  Bug
  Resolved In:  3.0.100; 3.1.6
The coalescing of multiple writes to the same point was faulty for any driver 
using the default implementation for write requests (subclassed from 
BBasicProxyExt, applicable to most serial-based drivers).  If multiple writes 
to the same point in a device occur quickly (before the first write can 
actually be transmitted to the device), the goal is that the multiple write 
requests be coalesced, such that the *last* write request submitted would win.
However, prior to this fix (in builds 3.0.100 and 3.1.6), the first write 
request would win.  With this fix, the last write request is the one processed.

#########################################################################
56  devDriver
#########################################################################

=========================================================================
56.1  Fixed
=========================================================================

*** 56.1:11051  Need to allow same request for reading and/or writing datapoints. ***
  Record Type:  Bug
  Resolved In:  3.3.16; 3.2.18
There was a minor bug in the Developer Driver Framework that would have required developers to take an extra step in the event that a driver was being developed that featured a protocol that used the same field-bus request for both reading (polling) and writing driver data control points. This has been fixed. Now the Developer Driver Framework fully supports the scenario where a request is both a BIDdfReadRequest and a BIDdfWriteRequest. This was the intended use scenario all along.

#########################################################################
57  dust
#########################################################################

=========================================================================
57.1  Fixed
=========================================================================

*** 57.1:7392  ReadWriteMode of Digital Points is wrong. ***
  Record Type:  Bug
  Resolved In:  3.0.93
Point discovery was listing the mode of digital points backwards.  Read-only points were
marked at write-only and vice versa.

*** 57.1:7393  Actuate digital points ***
  Record Type:  Enhancement
  Resolved In:  3.0.93
It is now possible to write to digital (boolean) points.

*** 57.1:7690  Alarm device support ***
  Record Type:  Enhancement
  Resolved In:  3.1.5; 3.0.100
The Dust driver now has an Alarms device extension, automatically created
when a SmartMeshClient (parent device) is added.  The following Dust events 
are supported:

? notifications/event/netMoteJoin
? notifications/event/netMoteLive
? notifications/event/netMoteUnknown
? notifications/event/alarmOpen
? notifications/event/alarmClose


#########################################################################
58  eibnetIp
#########################################################################

=========================================================================
58.1  Fixed
=========================================================================

*** 58.1:10069  Socket exception on startup kills receive thread ***
  Record Type:  Bug
  Resolved In:  3.2.17; 3.3.1
Fixed bug which could cause premature death of datagram socket receive
thread before any datagram packets could be received.  

*** 58.1:10260  Added poll-once properties ***
  Record Type:  Enhancement
  Resolved In:  3.1.31; 3.2.17; 3.3.1
The following properties have been added to the KnxProxyExt class to allow for finer
granular control of polling behavior:
    pollOnceOnSubscribed:boolean, defaults to false.
      Used to send a single a poll to the first group address off the GroupAddresses
      property, whenever the point enters a subscribed state, such
      as when a user views it on a point list.  If enabled, the resulting poll
      is independent, and will occur despite any other poll setting (for instance,
      it will occur even if pollEnabled is false, or PollScheduler rate is 0
      or disabled.) Behavior can be modifed by the "pollUntilAnswerReceivedOnPollOnce"
      property defined below.
    pollOnceOnOperational:boolean, defaults to false.
      Used to send a single poll whenever the point status changes from disabled to 
      enabled, or down to up, or fault to noFault. If enabled, the resulting poll
      is independent, and will occur despite any other poll setting (for instance,
      it will occur even if pollEnabled is false, or PollScheduler rate is 0
      or disabled. Behavior can be modifed by the "pollUntilAnswerReceivedOnPollOnce"
      property defined below.
    pollUntilAnswerReceivedOnPollOnce:boolean, defaults to false.
      If pollOnceOnSubscribed or pollOnceOnOperational are set to true,
      if this value is also set to true, then the poll once behavior
      is modified to "poll until one valid value is received" instead
      of "poll once and forget".  This has the effect of subscribing the 
      point to the poll scheduler until such time as the proxy point receives
      a LDataInd message addressed to the first group address in the list,
      and the a value is a valid value for this point type.  When these
      conditions are satified, the point is unregistered from the poll
      scheduler.
    pollAfterWrite:boolean, defaults to false
      Independent of pollEnable and properties described above.  Used to enable or disable
      a poll for value after a write.


#########################################################################
59  kitLon
#########################################################################

=========================================================================
59.1  Fixed
=========================================================================

*** 59.1:7667  Need a way to implement TODEVENT ***
  Record Type:  Enhancement
  Resolved In:  3.1.9
A new object, LonTodEvent, has been added to kitLon module to provide a 
SNVT_tod_event signal to a LON controller. LonTodEvent would can be connected
to a BooleanSchedule to provide time of day schedules to a controller. 

To implement make the following links from a BooleanSchedule to LonTodEvent:

BooleanSchedule.out --> LonTodEvent.currentState
BooleanSchedule.nextValue --> LonTodEvent.nextState
BooleanSchedule.nextTime --> LonTodEvent.nextTime

 

*** 59.1:8331  LonTodEvent will not allow viewing of wiresheet when linked ***
  Record Type:  Bug
  Resolved In:  3.1.15
The LonTodEvent component found in the kitLon module (first introduced in 3.1.9,
see issue 7667) was incorrectly handling the update of enums currentState
and nextState.  This caused exceptions to be thrown when it was viewed in a 
wire sheet.  This was fixed in 3.1.15.

NOTE: Currently, the kitLon module contains only two components in its palette:

 LonTodEvent - Can take inputs from BooleanSchedule outputs (Out, Next Value),
               and be linked to SnvtTimeStamp.

 LonTime -     Uses system time and can be linked to SnvtTimeStamp.

*** 59.1:8592  Help reference for kitLon components pointed to docUser ***
  Record Type:  Bug
  Resolved In:  3.1.22
The kitLon module available in AX-3.1 now uses docLonworks (Lonworks Guide)
for its context-sensitive "Views > Guide Help".

*** 59.1:9602  Need to limit timeToNextState ***
  Record Type:  Enhancement
  Resolved In:  3.2.10; 3.1.31
Added maxTimeToNextState property to BLonTodEvent object to limit the 
value of the timeToNextState calculated by the object.  This change 
will be in 3.1.31 and 3.2.10.

#########################################################################
60  lontunnel
#########################################################################

=========================================================================
60.1  Fixed
=========================================================================

*** 60.1:8660  LonTunnel not supporting Lonworks FTP operations ***
  Record Type:  Bug
  Resolved In:  3.1.22
Lon tunneling was not correctly handling certain messages, which made it
impossible to tunnel operations that requred reading files from a controller
using LonWorks FTP.  This was fixed in lonTunnel build 3.1.22, which also
requires the use of lonworks build 3.1.22.

#########################################################################
61  lonworks
#########################################################################

=========================================================================
61.1  Fixed
=========================================================================

*** 61.1:7047  Problems commissioning and binding Raptor LON node ***
  Record Type:  Bug
  Resolved In:  3.0.88
The Niagara station's LonNetwork must be modified from the default 
configuration in order to reliably configure the network management database 
for Staefa LON nodes. The following sections provide descriptions of the 
properties and recommended settings.

Timer Settings

The repeatTimer specifies the time interval between repetitions of outgoing 
messages when the repeated service is used. The receiveTimer is set to the 
time interval specified by this field when a multicast message is received. 
If a message with the same transaction ID is received before the receive 
timer expires, the message is considered to be a retry of the previous message. 

The transmitTimer field specifies the time interval between retries when 
acknowledged or request/response service is used. The transmitTimer is restarted
when each attempt is made and when any acknowledgement or response is received.
The property retries specifies the number of retries for acknowledged, 
request/response or repeated service. The maximum number of messages sent is 
one more than this number.

1. LonComm timers are used for all network management messages, all poll 
messages and unbound NV update messages from the stations. 
From Config, drivers, LonNetwork, property sheet, Lon Comm Config, make the 
following property modifications:
repeatTimer = mSec128
receiveTimer = mSec1024
transmitTimer = mSec128
retries = 4

2. Descriptors are timers applied to the address table of nodes during the 
bind process and are used for all implicit addressing. From Config, drivers, 
LonNetwork, property sheet, Lon Netmgnt, Link Descriptors, make the following 
property modifications:
linkDescriptors
 critical
  repeatTimer = mSec128
  retries = 3
  receiveTimer = mSec1024
  transmitTimer = mSec128
 reliable
  repeatTimer = mSec128
  retries = 3
  receiveTimer = mSec1024
  transmitTimer = mSec128
 standard
  repeatTimer = mSec128
  retries = 3
  receiveTimer = mSec1024
  transmitTimer = mSec128
 authenticate
  repeatTimer = mSec128
  retries = 3
  receiveTimer = mSec1024
  transmitTimer = mSec128

General configuration notes:
When utilizing Staefa Predator controllers, please observe the following 
guidelines:
Commissioning
1. Commission all devices from the LonDeviceManager.
2. Go to the LonUtilitiesManager. Select reports from the command menu and 
verify from the sub-command menu then execute.
3. If any mismatches occur execute a replace command from the LonDeviceManager
on the offending node.
4. Repeat steps 2 and 3 until all nodes report no errors in the verify report.
Binding
1. From the LonLinkManager execute the bind command.
2. Go to the LonUtilitiesManager. Select reports from the command menu and 
verify from the sub-command menu, then execute.
3. If any mismatches occur execute a replace command from the LonDeviceManager
on the offending node.
4. Repeat steps 2 and 3 until all nodes report no errors in the verify report.

Special considerations for bindings to Steafa Raptor controllers:
Some Raptor controllers installed in the field may reset when a large 
number of bound connections are created. To reduce the network load on the 
Raptor it is recommended that all connections from the Raptor (Raptor NVOs) 
to the JACE be set to the status of poll_only.  However, if the output of the
Raptor is fanned to multiple nodes, which include the JACE, the link should 
be bound. All inputs to the Raptor should be bound. 


*** 61.1:7105  Enum Proxy Points cause nv values to display only ordinals. ***
  Record Type:  Bug
  Resolved In:  3.0.90
When an enumerated Lon proxy point was added to an enumerated data element in 
a LonComponent (nv,nci,cp), and the value of the proxy point was changed, the
LonComponent data element would lose all enumeration data.  The value would 
be displayed as the integer ordinal value, instead of the string tag value. 
Also, the enumeration pull-down list would no longer contain any choices.
This was fixed starting in build 3.0.90.

*** 61.1:7259  LocalNvs not correctly sending updates to bound Lon nodes ***
  Record Type:  Bug
  Resolved In:  3.0.91
When a station was set up as a "Lonworks device" with localNvs added to the 
LocalLonDevice (using the Local Lon Nv Manager, also the Points extension under
the LocalLonDevice), externally bound output nvs (nvos) were not sending
nv updates when the Out value of the associated writable proxy point changed.

This was fixed in build 3.0.91.  Note this Niagara Lon configuration is atypical,
as in this case the station is NOT acting as the Lon network management tool.

*** 61.1:7260  Changes made by an external network manager lost on station restart. ***
  Record Type:  Bug
  Resolved In:  3.0.91
When a station was used as a "Lonworks device" with network management handled 
externally, the changes made to the local interfaces were not being saved in 
the station database. At station startup, the local interface was reinitialized
with the data in the database, causing the external setup to be lost. This
was fixed in build 3.0.91.

Now, when the LocalLonDevice/External Config property is set to true, the 
domain and address table information will be read during a device ping action.
This action is invoked periodicallly by the LonNetwork/Ping Monitor.

*** 61.1:7261  Commissioning of device with nv using SNVT_config_src did not occur correctly. ***
  Record Type:  Bug
  Resolved In:  3.0.91
A LonDevice may have an nv or nci of type SNVT_config_src which can be set to
CFG_LOCAL or CFG_EXTERNAL.  When the device is commissioned by Niagara this
nv, if present, should be set to CFG_EXTERNAL.  This was not being done.
This was fixed starting in build 3.0.91.

*** 61.1:7262  Could link polled output nv to non-polled input nv. ***
  Record Type:  Bug
  Resolved In:  3.0.91
A polled output nv will not send an nvUpdate except in response to poll.
Polled input nvs are nvs which will send a poll message when bound.
Link validation should not allow linking a polled output nv to a
non polled input nv.  This check was not being made.
This was fixed starting in build 3.0.91.

*** 61.1:7277  Add ability to delete local nv from the Nv Manager ***
  Record Type:  Enhancement
  Resolved In:  3.0.92
Reworked Local LonDevice Nv manager view to be more consistent with other
manager views.  New view allows deletion of selected items.

*** 61.1:7278  Add nci to local device ***
  Record Type:  Enhancement
  Resolved In:  3.0.92
Reworked Local LonDevice Nv manager view to be more consistent with other
manager views.  Added nv/nci selection on add popup.

*** 61.1:7290  Unable to rename Snvts through Lon Local NV Manager ***
  Record Type:  Bug
  Resolved In:  3.0.92
Reworked Local LonDevice Nv manager view to be more consistent with other
manager views. Can now edit name of selected items.

*** 61.1:7344  Link Manager did not display large number of links ***
  Record Type:  Bug
  Resolved In:  3.0.92
With large numbers of links, the Link Manager table was found to take increasingly
longer times to display the complete list of links.  This could take several minutes
for hundreds of links, or if thousands, never fully complete.  This problem was most
pronounced with QNX-based JACEs.  This issue was fixed starting in build 3.0.92. 

*** 61.1:7365  Upload of device failed with error "unable to open files" ***
  Record Type:  Bug
  Resolved In:  3.0.93
Some Lon devices would fail on upload or download actions, producing an error
exception saying "unable to open files."  Such a device stored config properties
in a file structure and used a seperate file for read only properties, and 
also used a File Transfer mechanism to read those files. This read only file
was not being correctly accessed.  This problem was fixed starting in build 3.0.93.

*** 61.1:7442  Database Channel ID not used on Match in Lon Device Manager ***
  Record Type:  Bug
  Resolved In:  3.0.95
When performing a "Match" in the LonDeviceManger with the 'use DB subnet/node' 
flag set, the database ChannelId was not being used. This could contradict the 
user expectation of creating a coherent network and could leave channel 
conflicts.  This was fixed in build 3.0.95.

*** 61.1:7444  LonStateEnum was incorrect ***
  Record Type:  Bug
  Resolved In:  3.0.95
lonworks:LonStateEnum had the ordinal value of ON and OFF reversed. 
This was fixed in build 3.0.95, where it now appears correctly as:
Ordinal  Tag    Display
 0       stOff  St Off
 1       stOn   St On
 255     StNul  St Nul

This only affected program objects that used LonStateEnum as a variable.  
In device representations the value of enums in SNVTs are obtained through 
standard.lnml which was auto generated from Echelon resource files.

*** 61.1:7514  Aliases not correctly allocated ***
  Record Type:  Bug
  Resolved In:  3.0.95
In complex connections with multiple hubs and multiple targets in the same device
(as is often incountered with lighting control systems) a bug was discovered in the
allocation of alias nvs.  This  could resulted in one or more links returning
to "new" status after a bind and refresh.

*** 61.1:7516  Provided support for differential temperature ***
  Record Type:  Enhancement
  Resolved In:  3.0.95
Some devices with nvs having absolute temperature units (such as SnvtTempP, 
SnvtTemp, SnvtTempF) are intended to represent offset or differential 
temperatures.  This causes problems during unit conversion as an offset is
used in converting absolute temperatures, but not for differential temperatures.  

In build 3.0.95, two features were added to deal with this. 
 1) For affected proxy points, it is now possible to set the point's facets 
    (Engineering units) to "temperature differential" units in the PointManager.
    For example, instead of "fahrenheit", use "fahrenheit degrees".
 2) The SNVT type can be modified in the *.lnml file. 
    For the affected nv/nci add a "+diff" to the snvtType attribute as shown:
       from : <snvtType v="TempP"/>  
       to   : <snvtType v="TempP+diff"/>

These features and other notes about unit conversion are described in the
latest (Oct. 3 2005) NiagaraAX Lonworks Guide.

*** 61.1:7526  Offline added devices (unknown state) consumed all CPU ***
  Record Type:  Bug
  Resolved In:  3.0.96
It was observed that a significant amount of processor time could be consumed
processing nvs that were registered with the poll scheduler, yet no read was 
being executed in the poll callback. This was initially found when programming
offline (adding DynamicDevices, then importing Lon Xml files). Duplication of
such devices were found to completely consume JACE processing.

In 3.0.95.2 (patch 2), mechanisms were reworked such that nvs are only 
registered with the poll scheduler when the poll will result in an actual read.

*** 61.1:7566  Disable Learn Nv command on DynamicDevice if LNML file not null ***
  Record Type:  Enhancement
  Resolved In:  3.0.97
In previous builds it has been possible for users to inadvertently execute 
a learnNv command on the DynamicDevice which was originally populated by 
importing an LMNL (Lon Xml) file. The command appears as "Learn Nv" on the 
(right-click) Actions menu for most Lon device components
(DynamicDevice components).

A learnNv completely repopulates the device component from the information 
available in the device's self documentation.  This results in manufacturer 
defined datatypes being reduced to byte arrays, and the deletion of any 
proxy points that previously attached to these.

Starting in build 3.0.97, LearnNv has been modified to throw an exception if 
the the DynamicDevice's "Xml File" property is not 'null'.  A popup message
appears which reads:
 "LearnNv blocked if XmlFile is not null.
  Operation will override imported properties.
  Must clear XmlFile and retry."
  
If the user desires to execute the learnNv command and overwrite a previous
LNML import, then he must clear the Xml File property and excute the learnNv
command again.
 


*** 61.1:7573  Proxy forcing rewrite if device value changed ***
  Record Type:  Bug
  Resolved In:  3.0.96
A writeable proxy point on a LonComponent (nv, nci, cp) would reassert its 
writeValue if the device's value was changed by some other means, and this was 
detected by a poll. This was found to be a problem if another tool was used to 
override the value that the station was writing.

In build 3.0.96, this behavior was changed such that a writeable proxy point 
will only update its target lonComponent when the control point is commanded to
a new value, or when (in the case of an nv) a write is initiated because the 
maxSendTime was exceeded.

*** 61.1:7580  Lon Xml Create not handling deleted folder ***
  Record Type:  Bug
  Resolved In:  3.0.96
The Lon Xml Create tool was not correctly handling the display of previous 
entries if these contained deleted or renamed directories (since last time
tool was used). An exception occurred, and you could not re-edit the entries.

This is fixed in 3.0.95.4.  The Directory and File Choosers will now default to 
the first valid level in the previously entered file path.

*** 61.1:7598  Facets overridden for points sometimes revert to device facet values ***
  Record Type:  Bug
  Resolved In:  3.0.98; 3.1.1
When a Lon Numeric proxy point is created, and the data element in the device
(e.g. SNVT) has specified min, max values and engineering units, these are 
applied to the new proxy point.  Initially, point facets = device facets, 
including the units and defined min and max values.

Previously, the min and max point facets were modified to reflect changes made
to units, with the side effect that it was not possible to add further min/max 
constraints to the proxy point's value.  In build 3.0.98, this behavior was 
changed such that min and max in the point's facets will only be forced to stay
within the device-imposed limits.  No modification beyond that will be made when
units change.

The point facet min will be forced to be greater than or equal to the device min,
and the point facet max will be forced to be less than or equal to the device max.

For example, you have a NumericWritable proxy point for an "nviSetptOffset", which
is implemented in the device using SNVT_temp_diff_p.  Device facets will have a
min of -327.68 and max of +327.66, using units deg C. If you change the point's 
facets to deg F, the accompanying min and max will remain at -327.68 and +327.66.
(Formerly, they would change to degF equivalents, namely -557.82 and 621.79).
You change the point's facets min and max values to -2.0 and +2.0, respectively.
This limits the change that a user can enter from a manual (right-click) action.
Now, (with this new fix) these min and max values will remain as entered, even
if you changed the point's facet units again (no conversion attempt).

*** 61.1:7611  LonLinkManager entry selection incorrectly highlighted other connections  ***
  Record Type:  Bug
  Resolved In:  3.0.98; 3.1.0
The LinkManager view allows entries to be highlighted for setting service type 
and selective binds.  When a table entry is selected, all members of that 
connection should highlight.  However, the LinkManager view was incorrectly 
selecting additional connections, for example if they shared a local connection 
using the same srcNv.  This happened when proxy points were created for nvs of 
same name in different devices.  This issue was fixed in build 3.0.98.

*** 61.1:7638  Proxy filters in Lon Link Manager would be useful ***
  Record Type:  Enhancement
  Resolved In:  3.1.9; 3.0.100
Starting in build 3.1.9, two new checkboxes were added in the left bottom 
corner of Lon Link Manager view, to allow the user to filter the view contents.
The user can select "Hide Proxy Links" to hide links from or to proxy points,
or select "Hide Net Links" to hide links between controllers.  

NOTE: This only affects the display of links.  A bind operation will still bind
all links, even though they the link is not displayed.

*** 61.1:7639  Trim action added to LonDevice to remove LonComponent slots for unused NVs ***
  Record Type:  Enhancement
  Resolved In:  3.1.9
Most LON devices have large numbers of NVs (network variables), each of which
is represented by a LonComponent slot (for every possible data field) as 
children under the parent LonDevice.  Often, only a few NVs are of interest in
the station, while the rest just consume station resources.

Starting in 3.1.9, each LonDevice has an available "Trim" action, which you can
use to remove its LonComponent nvi and nvo slots that do not have an associated
Lon proxy point, or that are not linked or have a Px bind.  This conserves 
station memory and allows support for more devices.

*** 61.1:7646  Lon proxy points did not appear in Point Manager in all cases ***
  Record Type:  Bug
  Resolved In:  3.0.98
Prior to build 3.0.98, you were incorrectly allowed to copy point folders 
from other drivers to be under the Points extension of a LonDevice. For
example, a NiagaraPointFolder (instead of the correct LonPointFolder).  It
was found that Lon proxy points copied into these folders would not display
in the Lon Point Manager.

In 3.0.98, parentage checks now prevent you from using point folders from 
other drivers.

However, after upgrading a JACE to lonworks 3.0.98 or later that had a 
station engineered this way (point folders from other drivers under a 
LonDevice's Points extension), exceptions are thrown upon station startup,
and the station will fail.
Example exception:
javax.baja.sys.IllegalChildException: 
  Illegal child "niagaraDriver:NiagaraPointFolder" for parent "lonworks:LonPointDeviceExt".

As a workaround, you must edit the station's config.bog file to change the
type of the alien point folder to a LonPointFolder.
Example modification to bog file: 
 search for any LonDevice.Points entries [n="points" t="l:LonPointDeviceExt"] and change
 the type of any child folder which is not already of type "LonPointFolder"
   from:   t="xx:XxxPointFolder"
   to:     t="l:LonPointFolder"

You can do this in Workbench by doing the following steps:
1. Copy the station to your local PC (platform tool Station Copier).
2. In the Nav tree, expand your host: My File System, stations, <targetStation>
3. Right-click the config.bog and select 'Views > Text File Editor'.
4. Use the Find (F5) and Find Next (Ctrl+F) features to find: LonPointDeviceExt
   Look for any child entries with incorrect attribute:  t="xx:XxxPointFolder"
5. Change the attribute to:  t="l:LonPointFolder"
6. Save the edited config.bog
7. Install the station back into the JACE (platform tool Station Copier).

*** 61.1:7647  Poll errors after deleting Lon devices ***
  Record Type:  Bug
  Resolved In:  3.1.7; 3.0.100
It was found that if a Lon device with polled NVs was deleted from the station,
that polling would continue, producing poll errors.  A station restart was
necessary to fix the problem.  This was fixed in 3.1.7, where NVs registered
with the poll scheduler are now unregistered upon deletion of a Lon device.

*** 61.1:7696  Link debug should be controlled by spy logging ***
  Record Type:  Enhancement
  Resolved In:  3.1.7; 3.0.100
Previously, to observe Lon link debug messages in the station's standard output,
you had to set the "Link Debug" property (under a LonNetwork's LonCommConfig 
container) to true. Starting in 3.1.100 and 3.1.7, link debug messages are sent
to standard output whenever you set the log level to Trace on a Lon network
(e.g. right-click station > Spy > logSetup), enable trace on "lon1").

*** 61.1:7711  Modify flags function reviewed on writes to NCIs and CPs ***
  Record Type:  Function
  Resolved In:  3.1.2; 3.0.100
When perfoming write operations on NCIs and CPs it is necessary to observe the
constraints imposed by the modify flags.  This was not being properly handled
in all cases. In 3.0.100 and 3.1.2 this was reworked to fully comply with all 
modify flags.

*** 61.1:7721  Support added for default values in config properties (NCIs, CPs) ***
  Record Type:  Function
  Resolved In:  3.1.7; 3.0.100
Added support for declaring initial values in .lnml files for NCIs and CPs and 
for applying this data during an import of the lnml.  This information is 
available in a device's .xif file (if xif version 4.0 or later), but was not 
previously being processed into the lnml or the runtime device model.

*** 61.1:7735  Path column added to LonDeviceManager to help set up routed network ***
  Record Type:  Enhancement
  Resolved In:  3.1.10
When setting up a routed network, it is necessary to assign all the devices on
a network channel to the same channelId and subnet.  It is typical to group the
devices in LonDeviceFolders that reflect the network topology. The LonDeviceManager
is the view typically used to do the address assignment, however, it did not 
reflect the folder (container) grouping of devices.  

In 3.1.10, an available "Path" column  was added to the LonDeviceManager, which
you can enable and use to do a sort, in order to group together devices in the 
same container. This allows you to select all devices in a container to do one 
operation, for example to set their subnet and channelId as needed.

*** 61.1:7994  Lockup occurs if LonNetwork is added a second time ***
  Record Type:  Bug
  Resolved In:  3.1.29; 3.2.3
On any QNX-based JACE (JACE-2, -4, -5), if the LonNetwork was deleted and then
a new LonNetwork added, it might not start properly.  The LonNetwork could be
in fault, or its LocalLonDevice might have had a neuron ID of all zeros.
Previously, the JACE had to be rebooted to fix this problem

*** 61.1:8030  Unable to set some links to poll only ***
  Record Type:  Bug
  Resolved In:  3.0.101; 3.1.7
In the LinkManager it is possible to set the service type on lon links. The same
mechanism is used to set links to poll only. The service type cannot be changed
if the serviceTypeConfigurable flag is false.  However, this flag was also incorrectly
preventing setting links to pollOnly.  This was corrected in 3.0.100.2 and 3.1.8.


*** 61.1:8049  LonDevice Discover bar did not go away on failure ***
  Record Type:  Bug
  Resolved In:  3.1.9
In some cases, a Lon device discovery job would fail because of a "failed
response exception", and the job progress bar at the top of the Lon Device
Manager would not go away or state a failure.  In 3.1.9, LonDevice discovery
was fixed such that certain exceptions could no longer abort the job 
without terminating the job in the JobService, and indicating that an
exception had occurred.

*** 61.1:8062  Link filter failed to start ***
  Record Type:  Bug
  Resolved In:  3.1.8; 3.0.100
The LinkFilter object, when copied from the lonworks palette into a LonNetwork,
would fail to start.  No records would collect in its Link Filter View table.
This was fixed in lonworks builds 3.0.100.2 and 3.1.8.

NOTE: This is a debug-type object, to be documented at a later date.

*** 61.1:8100  Long delay before link window becomes active ***
  Record Type:  Bug
  Resolved In:  3.1.10; 3.0.100
When establishing a bind between LonDevices, where you have the Link editor
open and select an NV, a long delay could occur before the editor became active
again (especially if it was the first time you had linked to the node). 
In 3.1.10, a change was made in the mechanism used to load device data needed 
during link validation.  This greatly reduces time the Link editor is locked up 
while this data is loaded.

*** 61.1:8148  Lon Xml Tool crashed parsing Circon value file ***
  Record Type:  Bug
  Resolved In:  3.1.15; 3.0.101
In a few cases, the Lon Xml Tool was found to crash during execution and
throw a NullPointException.  In 3.0.101 and 3.1.5, additional range checks
were added to avoid null pointers and array out-of-bound exceptions.

*** 61.1:8289  Device facets not being copied with device ***
  Record Type:  Bug
  Resolved In:  3.1.15; 3.0.101
It was found that device facets were not copied when a LonDevice was copied.
In 3.0.101 and 3.1.15, storage for deviceFacets was changed from the slot Facets 
on the device itself to a new property "Facets" under the device's DeviceData.
If a LonDevice had the slot Facets prior to this change, they will be copied to
the new location.

*** 61.1:8408  SNVT_temp was not converted correctly. ***
  Record Type:  Bug
  Resolved In:  3.0.101; 3.1.17
An error was found in the conversion of SNVT_temp values from/to the raw value
stored in the device. This would cause output nvs to read incorrectly, and input
nvs to write incorrectly.  This was corrected in 3.1.17 and 3.0.101.
 
Note this problem did *not* affect nvs using SNVT_temp_p or SNVT_temp_f. 

Devices using SNVT_temp which were learned in previous builds can be fixed by
executing either:
 ImportXml - if the device's nvs were added from an lnml file, or 
 the LearnNv action - if the device's nvs were added by that method. 
 
It is also possible to manually edit the facets on the temp slot of a SnvtTemp nv. 
The offset facet should be changed from -274 to 274. 
                      
       

*** 61.1:8410  ImportXml command would sometimes fail. ***
  Record Type:  Bug
  Resolved In:  3.0.101; 3.1.17
The ImportXml command on a LonDevice would fail if the device's Points folder
contained control points that were *not* Lon proxy points.  This was fixed in
3.1.17 and 3.0.101. 

*** 61.1:8578  Station as Lon node (vs Lon network manager) should be more straightforward ***
  Record Type:  Enhancement
  Resolved In:  3.1.22
When configuring a JACE station as a standalone LON node, and not the
(more typical) LON network manager, configuration was not straightforward, 
especially to operate in an LNS-managed network.  A recent Niagara
Central blog entry and subsequent updates to the "NiagarAX Lonworks
Guide" attempted to clarify the particular configurations needed.  In
addition, several invalid network-management operations remained available. 

Starting in build 3.1.22, operation as a (externally managed) LON node
was improved with the following changes:

- The "External Config" property of the LocalLonDevice is logic-linked to the
  LonNetMgmt "Enabled" property. As a result, if you set the LocalLonDevice's
  External Config property to "true" for "LON node only" operation, inappropriate
  netmgmt actions (Add, Match, Commission, Replace, Bind) are disabled in the
  various Lon manager views.

- The LocalLonDevice now has two frozen nv slots, as required by LNS:
    nviRequest
    nvoStatus
  Note that the default "Self Doc" string for both of these nvs is now digestable
  by LNS, as well as the "Self Doc" string for the parent LocalLonDevice.  Often, 
  you may need to augment the self documentation values, however, this serves as 
  a starting point.  Note that if you add additional nvs/ncis under the 
  LocalLonDevice, you should also enter "Self Doc" values for each one using the
  proper syntax for LNS compatibility.

NOTE: If upgrading an exisiting station running "as LON node only" and the two
required LocalLonDevice exist, but have names that do not match *exactly* to the
frozen nv slots (nviRequest, nvoStatus), *delete* those original two nvs.

*** 61.1:8656  Alias count of LonDevice was lost on copy ***
  Record Type:  Bug
  Resolved In:  3.1.22; 3.0.102
The alias count of a Lon device (on its property sheet: Device Data, Alias Table,
Alias Count) was not being preserved during a copy operation.  The incorrect
alias count did not affect the operation of the controller but did incorrectly,
limit the links which could be made to the device.  The bug was fixed in 3.1.22 
and 3.0.102.  

The Commission operation was modified to read the alias count from the device
and set this property of the Lon device component to the correct value.  
Therefore, you can perform a Commission to set the value correctly if it has 
been incorrectly changed from a copy.

*** 61.1:8658  EnumPoint setting nci to zero at station start ***
  Record Type:  Bug
  Resolved In:  3.0.102; 3.1.22
Read-only proxy points (e.g. EnumPoint, NumericPoint) mapped to NCIs in a Lon
device were found to overwrite the device's NCI values upon station startup, 
for example to a zero value.  The write happened before the NCI value was read 
from the device and then set in the proxy point.  This was corrected in builds 
3.0.102 and 3.1.23.

*** 61.1:8663  Upload of Lon device that used file transfer lost packet 0 ***
  Record Type:  Bug
  Resolved In:  3.0.102; 3.1.22
An bug in the handling of file transfer lost packet could result in the failure
of an Upload operation if the device used FTP (File Transfer Protocol).  This 
could have made it necessary to repeat the upload.  This was fixed in builds 
3.0.102 and 3.1.22.

*** 61.1:8744  Unable to parse resource file in Lon Xml Tool ***
  Record Type:  Bug
  Resolved In:  3.1.24; 3.0.102; 3.2.1
It was found that when using the Lon Xml Tool, that resource files that had
empty nv or cp type records would not parse correctly, so a Lon Xml (.lnml)
file could not be made using them.  This was fixed in builds 3.0.101 and 3.1.24.

*** 61.1:8814  Bind of alias nv reported "com error" ***
  Record Type:  Bug
  Resolved In:  3.0.102; 3.1.24; 3.2.1
Binding of links which required the use of alias nvs was incorrectly reporting
a status of "Com Error" when the link was first bound.  Alias nvs are used 
when available, and an output nv is connected to multiple input nvs on the same
controller.  This was fixed in builds 3.0.102 and 3.1.24.

*** 61.1:8877  File transfer Delayed Response produced exceptions ***
  Record Type:  Bug
  Resolved In:  3.2.1; 3.1.25; 3.0.103
An exception with the message "Unable to access lon file directory" was found
to occur when using the file transfer mechanism to access files in some devices.
To fix this, a check was added to accomodate "delayed responses" in file lookup
operations, starting in builds 3.0.10 and 3.1.25.

*** 61.1:8894  LocalLonDevice allowed nv/nci which were not local type ***
  Record Type:  Bug
  Resolved In:  3.0.103; 3.1.25; 3.2.1
The LocalLonDevice can contain LocalNvs and LocalNcis (only).  If standard 
nvs/nci objects were added to the LocalLonDevice, then a message similar to
below could display:

  INTERNAL ERROR: in SnvtInfo.getDescriptor(). 
  
A check was added to prevent adding standard nvs/ncis to the LocalLonDevice,
starting in builds 3.0.103 and 3.1.25.

If a station already has standard nvs/ncis added under its LocalLonDevice, then
the an "IllegalChildException" will be thrown upon startup.  To fix this, you
must edit the database offline and remove the offending objects.

*** 61.1:8911  LocalLonDevice neuronId not set correctly on station copy ***
  Record Type:  Bug
  Resolved In:  3.0.103; 3.1.25; 3.2.1
If a station database was copied to a new platform, the LocalLonDevice neuronId
would not get set to the value of the new hardware.  A check was added to verify
the neuronId is recorded correctly upon station startup, starting in builds 
3.0.102 and 3.1.25.

*** 61.1:8940  LonDeviceManager exception if view refreshed during a learn, Workbench restart needed ***
  Record Type:  Bug
  Resolved In:  3.1.25; 3.2.1
If the Lon Device Manager is refreshed while devices are being added during a 
learn, sometimes an "IllegalStateException" results.  In this case, subsequent 
attempts to access the Lon Device Manager result in "java.baja.naming.UnresolvedException"s,
and devices do not display.  This issue was resolved in build 3.1.25.


*** 61.1:8954  UnresolvedException during Quik Learn, other Lon Device Manager errors ***
  Record Type:  Bug
  Resolved In:  3.1.25; 3.2.1; 3.0.103
A number of LonDeviceManager functions were not functioning properly, including
Quik Learn. Various exceptions would be thrown, operations did not complete, and
data did not display correctly in the device view after adds and matches.

This problem was known to exist in build 3.1.24, and may exist in other builds.

*** 61.1:8975  Unable to learn message tags from Quik Learn. ***
  Record Type:  Bug
  Resolved In:  3.1.25; 3.2.1; 3.0.103
If a Lon network included linked message tags, a Lon Device Manager "Quik Learn"
(with the "Learn Links" option enabled) could fail, with the job log details 
indicating a java.lang.ArrayIndexOutOfBounds exception.  This was fixed
in builds 3.0.103 and 3.1.25.

*** 61.1:9018  Support added for LonMark 13.00 standard resource files ***
  Record Type:  Enhancement
  Resolved In:  3.0.104; 3.1.30; 3.2.4
Added support for new SNVT and SCPT types that were defined in LonMark 13.00
standard resource files in 3.0.104, 3.1.29.1, 3.2.4

*** 61.1:9041  Disabled writable Lon proxy points still write ***
  Record Type:  Bug
  Resolved In:  3.0.104; 3.1.27; 3.2.2
Disabling writable Lon proxy points did not prevent them from updating the
associated nvi of the Lon device.  This was fixed in 3.1.26 and 3.0.104.

*** 61.1:9042  Exception caused Quik Learn to hang ***
  Record Type:  Bug
  Resolved In:  3.0.104; 3.1.27; 3.2.2
Unhandled exceptions caused some network management jobs, including Quik Learn,
to complete without notifying the station's Job Service that the job was ended.
This made it appear that the job was "hung."  This was fixed in 3.0.104 and 3.1.27.

*** 61.1:9127  NullPointerException during Lonworks Quik Learn ***
  Record Type:  Bug
  Resolved In:  3.1.28; 3.2.3
If a Quik Learn was executed in the Lon Device Manager with the Discovery pane
open and already populated with discovered devices, the view would not correctly 
display all the devices in the Device pane when the job was completed.  Also,
NullPointerExceptions would be produced in the station's standard output.  To
fix the view's display, a refresh was required.

This problem was fixed in lonworks.3.1.28.1 and 3.2.3.

*** 61.1:9241  LonLinkManager limited number of proxy points for nv with critical service type ***
  Record Type:  Bug
  Resolved In:  3.0.104; 3.1.29.1; 3.2.4
The Lon Link Manager was incorrectly limiting the number of proxy points on a 
single nv if critical serviceType was used.  This was fixed in 3.0.104, 
3.1.29.1, and 3.2.4.

*** 61.1:9261  Bound connection with new service type stays new. ***
  Record Type:  Bug
  Resolved In:  3.0.104; 3.2.4; 3.1.30
An error in the address assignment could cause a connection with a new status
to show bound after a bind operation and return to the new status after a 
LonLinkManager refresh.  This was fixed in 3.0.104, 3.1.30, 3.2.4

*** 61.1:9286  Node links not showing up after quickLearn ***
  Record Type:  Bug
  Resolved In:  3.0.104.1
A quikLearn would not import link information for a device which did not have
an associated lnml file resident in the station.  This was fixed in 
3.0.104.1 and subsequent builds.

*** 61.1:9339  Learn request failed with IllegalStateException ***
  Record Type:  Bug
  Resolved In:  3.0.106; 3.1.30; 3.2.6
An IllegalState exception could be generated while learning links during a
LonDeviceManager 'Learn' action. This was fixed in AX builds 3.0.106, 3.1.30 and 3.2.6. 

*** 61.1:9345  Failed to learn nvs ***
  Record Type:  Bug
  Resolved In:  3.0.107; 3.1.30; 3.2.8
Errors in a device's 'selfdoc' could cause the learnNv action to fail. The Lonworks
driver has been changed so that it now posts a warning and continues with
the learnNv operation. 
This change has been added in builds 3.0.107, 3.1.30 and 3.2.8.

*** 61.1:9383  Automatic PING action after successful device commission ***
  Record Type:  Enhancement
  Resolved In:  3.0.106; 3.1.30; 3.2.6
A down device would remain in this state after a commission or replace operation
until serviced by the device monitor, unless it was manually pinged. The device 
will now be set to the up state automatically after a successful commission or 
replace action.  This change was made in 3.0.106, 3.1.30, and 3.2.6.

*** 61.1:9391  Proxy points on NCIs could have inappropriate "stale" status ***
  Record Type:  Bug
  Resolved In:  3.0.106; 3.1.30; 3.2.6
Proxy points on NCIs and CPs could get set to a 'stale' state if the parent
device was marked down before the NCIs or CPs had been written or read.
To clear the 'stale' state required a read, write, upload or download operation.
This has been fixed in AX builds '3.0.106', '3.1.30' and '3.2.6'. It should
no longer be possible for an NCI or CP proxy to enter into a 'stale' state.


*** 61.1:9398  Add support for Extended Network Management messages (CEA-709.1-B) ***
  Record Type:  Enhancement
  Resolved In:  3.2.7
Lonworks controllers which make use of Extended Network Management messages 
as defined in 'CEA-709.1-B' will not work with earlier versions of the lonworks
drivers.  Support for this specification was added in '3.2.6.1' and later builds.  
Support for dynamic nvs, also defined by the above specification, has not been 
added at this time.


*** 61.1:9466  Learn links ignores selector 0 ***
  Record Type:  Bug
  Resolved In:  3.0.107; 3.1.30; 3.2.8
When learning links on a network being managed with another network management
tool, any link with selector 0 would not have a graphical link added to the 
Niagara database. The link would show in the LinkManager table as obsolete.

This was fixed in 3.0.107, 3.1.30, 3.2.8.

*** 61.1:10081  LinkManager table will not display links ***
  Record Type:  Bug
  Resolved In:  3.2.17; 3.3.1; 3.1.31; 3.0.107; 3.2.16.3
A couple of bugs in the link table creation would cause LonLinkManager table would not 
display any links and a NullPointer exception would be thrown in the standard output.
This was fixed in builds 3.2.17, 3.1.31, 3.0.107.


*** 61.1:10091  Verify device reports error for bound alias ***
  Record Type:  Bug
  Resolved In:  3.2.17; 3.3.1; 3.2.16.3
LonUtilitiesManager incorrectly reports an error in devices with bound alias nvs.
This was fixed in 3.2.17.


*** 61.1:10152  Proxy set of same value rewrites to controller. ***
  Record Type:  Enhancement
  Resolved In:  3.3.1; 3.2.17
Previously a LonProxy point would ignore sets which did not change the points
value. Change the behaviour to force a write to the device if a point is set to its
current value.  This change is made in 3.2.16.6 and later builds.

#########################################################################
62  modbusAsync
#########################################################################

=========================================================================
62.1  Fixed
=========================================================================

*** 62.1:4789  Device polling uses excessive CPU ***
  Record Type:  Enhancement
  Resolved In:  3.1.5
It was a known issue that the Modbus device level polling feature caused
excessive CPU usage.  In the past, Modbus point level polling was the workaround
for this problem, however, this workaround didn't use the communication bandwidth
as effectively as device level polling.

Starting in build 3.1.5, the device polling feature was improved to solve the 
CPU usage problem.  The setup for device level polling is still the same, and 
point level polling remains unchanged, so you can choose to use either approach.  

There is only one important difference: the 'Poll Frequency' property on the 
Modbus device object is now obsolete after this change.  It will still appear 
in your properties sheet for backwards compatibility reasons, but it will not 
be used in this build and later.

Device level polling is still configured the same way (i.e. using the 
'Device Poll Config' property on the Modbus device object).  However, now the 
poll frequency is determined by the actual Modbus proxy points that are 
subscribed and polled by the device poll config entry.  It uses the fastest 
poll frequency of the applicable subscribed points.  For example, if you 
are using device level polling to poll five subscribed points (4 of them are 
configured for 'normal' poll frequency and one is using a 'fast' poll 
frequency), then all of them will be polled at the 'fast' frequency since this 
is the quickest rate in the poll group.

#########################################################################
63  modbusCore
#########################################################################

=========================================================================
63.1  Open
=========================================================================

*** 63.1:2997  Invalid characters can be entered in the Modbus address ***
  Record Type:  Bug
  Resolved In:  
It may be possible to enter invalid characters into the Modbus address
property fields.  In order to avoid configuration faults, please be sure
that when entering Modbus addresses, you check that both the address type
(Modbus, Hex, Decimal) and address value are appropriate for the point type.
For example, holding register addresses in Modbus format should be prefixed
with 40xxx, input register addresses in Modbus format should be prefixed with
30xxx, input status addresses in Modbus format should be prefixed with 10xxx,
and coil addresses in Modbus format should be prefixed with 00xxx.  Similarly,
the hex and decimal types should be addressed according to valid hex/decimal
values.  If an invalid address is entered, the absolute Modbus address used 
may not reflect the intended address.

It is also worth noting that if a duplicate absolute Modbus address is 
entered for multiple writable points, only the first (original) point will
use the address.  The duplicates will default to -1 (invalid address) and
require user interaction.  The reason this happens is to prevent multiple
writable points from attempting to write to the same point on the Modbus
device.

=========================================================================
63.2  Fixed
=========================================================================

*** 63.2:7633  Modbus Slave (server) points use excessive CPU time ***
  Record Type:  Bug
  Resolved In:  3.1.1; 3.0.98
Modbus Server proxy points (ModbusSlave, ModbusTcpSlave) were found to be using 
excessive CPU time.  In particular, the "Nre:Engine" thread of a station was 
using excessive processing time on these types of points.  The problem was that
these points were executing even if the polled value had not changed, and thus
unnecessary process time was being used for these points.  

This was fixed in build 3.0.97, so now the point's value is checked to verify 
that it has changed before executing the point.  This should improve performance
of stations using the ModbusSlave and/or ModbusTcpSlave drivers.

*** 63.2:9820  Exception error when using 'Add Range' action on ModbusRegisterRangeTable ***
  Record Type:  Bug
  Resolved In:  3.2.14; 3.1.31; 3.0.107
Previously, on a ModbusSlaveDevice or ModbusTcpSlaveDevice, when using the 
right-click action 'Add Range' on a Modbus Register Range Table property, 
after specifying the address offset and size in the popup dialog and 
clicking OK, an Error popup appeared, with details of 
javax.baja.sys.ActionInvokeException. The range entry was not added. However, 
you could manually add/duplicate range entries under any Modbus Register
Range Table.

This bug has now been fixed, so that the action works without error.


#########################################################################
64  modbusSlave
#########################################################################

=========================================================================
64.1  Fixed
=========================================================================

*** 64.1:7532  CRC/LRC checking for serial Modbus Slave not implemented ***
  Record Type:  Bug
  Resolved In:  3.0.96
The serial Modbus Slave driver was not checking the CRC (in RTU mode) or LRC 
(in ASCII mode) for received Modbus requests.  Thus it could potentially try
to process and respond to invalid Modbus requests.  This was fixed so that the
CRC (or LRC) is now checked when a Modbus request is received, and if there is
a problem with the CRC/LRC calculation, it will disregard the Modbus request
and not respond.

#########################################################################
65  modbusTcp
#########################################################################

=========================================================================
65.1  Open
=========================================================================

*** 65.1:5407  Improve ModbusTCP ping implementation ***
  Record Type:  Bug
  Resolved In:  
Currently, the ModbusTCP driver in NiagaraAX makes a Modbus request to ping
a physical ModbusTCP device.  If no response is received from this Modbus 
request, then the device is considered to have a "down" status.  This process 
works, however if the ModbusTCP device is unplugged from the network, it can 
cause slow performance because the Java socket used for the connection attempt 
can hang for a minute (or more) waiting for the response.

In the future, a better way to handle the ping process will be to use an ICMP 
ping call instead of trying to make a Modbus request using a Java socket (this
is the method currently used in the Niagara R2 ModbusTCP driver). 

#########################################################################
66  modbusTcpSlave
#########################################################################

=========================================================================
66.1  Fixed
=========================================================================

*** 66.1:9285  modbusTcpSlave not passing transaction id in response header ***
  Record Type:  Bug
  Resolved In:  3.2.5; 3.1.30
The ModbusTcpSlave driver message responses failed to include the transaction
id prior to build 3.1.30. The transaction id is now included in the response 
message.

#########################################################################
67  ndio
#########################################################################

=========================================================================
67.1  Fixed
=========================================================================

*** 67.1:7346  Ndio writable points miss writes on station startup ***
  Record Type:  Bug
  Resolved In:  3.0.92
With the addition of Ndio reboot logic starting in build 3.0.88, a small
window of time (10 seconds) was introduced at station startup, where 
writes could occur to Ndio writable proxy points, yet be ignored.  This bug
was fixed in build 3.0.92.
For more details about Ndio reboot logic, please see the latest Ndio Guide
section "Ndio Network monitor notes."

*** 67.1:7568  Ndio points don't copy from offline station ***
  Record Type:  Bug
  Resolved In:  3.1.5
When copying an NdioBoard from an offline station to another station, sometimes
the Ndio Points folder would be empty at the destination.  This was fixed 
starting in build 3.1.5.

Note as a workaround in a 3.0 system, you can copy and and paste Ndio points in
a separate operation.

*** 67.1:7570  Board IO port goes to default on copy ***
  Record Type:  Enhancement
  Resolved In:  3.1.5
In previous releases, when copying NdioBoards or Ndio points, the Io Port and
point address properties would be reset to default values. The port and address
properties are now copied correctly.

*** 67.1:8140  Installing a station with Ndio on a JACE without Ndio caused a reboot. ***
  Record Type:  Enhancement
  Resolved In:  3.0.101; 3.1.10
Historically, when installing a station with an NdioNetwork on a JACE without 
Ndio support (e.g. JACE-545), Ndio would cause a JACE reboot. This occurred
from the reboot logic in the Ndio driver. Since this was found annoying, 
the driver was changed such that it will not reboot the JACE unless it has 
successfully pinged the station's NdioNetwork at least one time.

#########################################################################
68  obixDriver
#########################################################################

=========================================================================
68.1  Fixed
=========================================================================

*** 68.1:8296  Point discovery in R2 JACE successful then shows it failed ***
  Record Type:  Bug
  Resolved In:  3.1.16
When discovering oBIX points in an R2 JACE-4/5, the discovery first appears
successful, then a failure is shown, as if two discoveries occurred, with the
last one failing.  This was fixed in the AX oBIX client driver in 3.1.16.

*** 68.1:8299  NiagaraAX oBIX write to R2 JACE fails ***
  Record Type:  Bug
  Resolved In:  3.1.16
A write fail exception would occur when attempting to use the set action on
an Obix proxy point representing an AO object in an R2 JACE. This happened
because of incorrectly normalizing the URI to the write operation, and was
fixed in 3.1.16.

*** 68.1:8500  Enum range facets do not update for ObixMultistateInput ***
  Record Type:  Bug
  Resolved In:  3.1.19
If the range facets of an ObixMultistateInput changed, the changes were not 
reflected in NiagaraAX until the point was rediscovered and re-added to the
database. This was fixed.  The NiagaraAX oBIX client now updates point facets
(units, ranges, min, max, etc) on the first read after the change on the server.

*** 68.1:8530  Wildcard in Href instead of R2 station name ***
  Record Type:  Enhancement
  Resolved In:  3.1.20
Hrefs of oBIX object were all absolute, which meant they included the lobby
address (and in case of R2 station server, its station name). This made it very
difficult to clone a database. Now, all Hrefs are relative to the lobby address.

*** 68.1:8640  Taking too long to expand the lobby during point discovery ***
  Record Type:  Bug
  Resolved In:  3.1.23
When expanding Obix points during discovery, sometimes it takes several seconds
to expand one point in the lobby (for example, 10 seconds for a NumericPoint).
In build 3.1.23, Obix discovery for points, histories, and alarms was optimized
to provide better performance.

*** 68.1:8680  Href change breaks subscriptions ***
  Record Type:  Bug
  Resolved In:  3.1.23
Points that were subscribed to the server will now resubscribe when the href
changes. Multiple points can no longer be subscribed to the same href and a
warning will print on the station director. However, points that try to
subscribe an already subscribed href will add themselves to the poll scheduler
and will manually read their value from the server.

*** 68.1:8724  Update Facets action added for ObixProxyExts, parent Points extension ***
  Record Type:  Enhancement
  Resolved In:  3.1.23
Facets for Obix points are automatically set at discovery time, but are not
updated afterwards (for instance at station startup, as this would dramatically
impact performance).  To allow for point facet changes since original creation,
an available action "Update Facets" was added to the ObixProxyExt in individual
Obix proxy points, as well as in the parent ObixPointDeviceExt (Points extension
of an ObixClient).  Invoking the action on a ProxyExt updates only that point,
whereas invoking the action on the Points device extension updates all points.

*** 68.1:8727  Extension failed onExecute() when Href property cleared ***
  Record Type:  Bug
  Resolved In:  3.1.24
After deleting an Href from an Obix point (say it was found to be a duplicate),
exceptions were generated saying "Extension failed onExecute()".  This happened
because the Obix proxy extensions were treating empty strings as valid hrefs,
causing the server's lobby object to be subscribed to by the Obix client driver
as a string object.  This was fixed--now an empty Href puts an Obix point into 
a fault status.

*** 68.1:8757  Constant NotRunningExceptions after deleting points ***
  Record Type:  Bug
  Resolved In:  3.1.24
Obix Points that had added themselves to the poll scheduler were not removing
themselves in the stopped callback (for example, when a point is deleted or
moved). Symptoms of this were NotRunningExceptions in the station director.
They now remove themselves.

*** 68.1:8763  Points show fault condition, but update fine. ***
  Record Type:  Bug
  Resolved In:  3.1.24
Some Obix proxy points would show a fault status, yet have values that updated
ok. Typically these were writable point types (BooleanWritable, NumericWritable,
StringWritable) created for objects that are read-only.

It is possible to create read-write points for objects that are read-only. In
that case, the point would go into write fault, and the fault state could not be
cleared by changing the point's Mode property to read-only.

The solution was to remove the Mode property in the ObixProxyExt altogether,
where the point type is now used to determine read-write mode. It is still 
possible to create writeable points that should not be, but the resolution is 
pretty clear - recreate the point correctly.

*** 68.1:8765  Constantly attempting subscription for points in fault ***
  Record Type:  Bug
  Resolved In:  3.1.24
If an Obix point subscription failed for some reason, for example when an Obix 
point was copied from one ObixClient to another ObixClient (that did not have 
the duplicate source object, i.e. the URI is bad), subscription re-attempts 
with that oBIX server would continuously occur.  This was inefficient on both 
sides.  Now, Obix points attempt to resubscribe only upon "device up" and 
Href property changes.


*** 68.1:8771  ObixClient shows attached when it is not ***
  Record Type:  Bug
  Resolved In:  3.1.24
When an ObixClient was not connected, but was given a Ping command, its State
property would (erroneously) change to "Attached" for some duration, then back 
to "Detached" if the ping attempt failed.  Now, while an ObixClient is in the
process of attaching, its State property shows "Attaching". If the ping is 
successful, the state will go to "Attached". Otherwise, it will go back to
"Detached".

*** 68.1:8772  Point status seems wrong when client goes down ***
  Record Type:  Bug
  Resolved In:  3.1.24
When a server went down, points that were subscribed to it immediately tried to
resubscribe. This resulted in one or more points with a "fault" status from a 
read fail, instead of the expected "down" status.  This situation would not fix 
itself until the next ping attempt by the client.  Now, point subscriptions that 
unexpectedly expire are treated as ping failures, showing a down status. 

*** 68.1:8773  Multiple ObixNetworks should not be allowed ***
  Record Type:  Bug
  Resolved In:  3.1.24
Only one ObixNetwork is supported in a station, yet multiple ObixNetworks could
previously be added without any apparent fault. A new check will allow only one
ObixNetwork to start up.

*** 68.1:8775  Imported history record had time zone showing NULL ***
  Record Type:  Bug
  Resolved In:  3.1.24
Histories imported from an ObixClient would show "NULL" for the time zone
in the Timestamp field.  The ObixHistoryImport descriptor was not handling
time zones correctly, and this issue was fixed.

*** 68.1:8833  Only control objects should be writable by default. ***
  Record Type:  Enhancement
  Resolved In:  3.1.24
Previously, any item that was writable on the oBIX server was by default
created as a writable point in the client.  This caused a model mismatch.
Now, the default behavior is to create a read-only point, unless the server
object is writable and a control object.  Note that you can still override 
the default client point type to select a writable type, if necessary.

*** 68.1:8874  oBIX operations should be actions on ControlPoint ***
  Record Type:  Enhancement
  Resolved In:  3.1.25
The AX oBIX client driver now adds simple oBIX operations as dynamic actions on
ControlPoints with oBIX proxy extensions. Simple operations are those that
require no, or primitive inputs.

*** 68.1:9035  Deleted imported histories still being polled ***
  Record Type:  Bug
  Resolved In:  3.1.28; 3.2.2
After deleting ObixHistoryImport descriptors from the NiagaraAX station
(which should have unsubscribed them), related polling was seen to continue 
in the target Niagara R2 oBIX server.  Now, the import descriptors set status
to down when cut, to stop this polling.

*** 68.1:9998  ObixNetwork's obixServer shows status ok when in license fault ***
  Record Type:  Bug
  Resolved In:  3.1.31; 3.2.16; 3.3.1
When using 3.1.30 or earlier on a host without the "export=true" attribute in the "obixDriver"
feature, on ObixNetwork's Server slot shows status "ok" when enabled, instead of fault.  The
fault cause still correctly reports "Server not licensed", and requests to the server will still
return an error response, but it might not be apparent that something is wrong because of the
misleading status.

This has been fixed, and the server is marked in fatal fault if the license does not contain the
required attribute.

*** 68.1:10288  AlarmClasses need to be exposed as oBIX AlarmSubjects ***
  Record Type:  Enhancement
  Resolved In:  3.1.31; 3.2.17; 3.3.1
Niagara AX alarm classes are now exposed by the oBIX server as oBIX
AlarmSubjects.  This makes processing of Niagara alarms more efficient
because you can control the routing of different types of alarms, and route
alarms to the appropriate destinations without sending alarms to recipients
that do not need to receive them.

*** 68.1:10581  Obix Export Manager non functional on JACE ***
  Record Type:  Bug
  Resolved In:  3.2.17; 3.3.10
The Obix Export Manager for exposing station points for continuous control by other
oBIX clients can be extremely slow if you are attempting to export points from
a large database.  The time taken appears to be related to the size of the
discovery table, which gets larger as you expand components and dig deeper
into the tree.

This has been fixed.  The Export Manager will now behave more appropriately.

#########################################################################
69  opc
#########################################################################

=========================================================================
69.1  Fixed
=========================================================================

*** 69.1:7396  Automatically update read-write mode. ***
  Record Type:  Enhancement
  Resolved In:  3.0.93
The read-write mode of points was previously only set at discovery time. If the
mode changes on the server, it will now be automatically updated when the
niagara point registers with the server. Also, the point manager screens
incorrectly allowed the editing of the read-write mode and they shouldn't have.

*** 69.1:7407  Support OPC 1.0 style of browsing. ***
  Record Type:  Enhancement
  Resolved In:  3.0.94
Discovery would not have worked on OPC vers. 1.0 servers.  Now discovery will
use browse_down style navigation if browse_to fails.

*** 69.1:7997  Discover in Opc Point Manager sometimes only found root objects ***
  Record Type:  Bug
  Resolved In:  3.1.7; 3.0.100
With certain OPC servers, a Discover in the Opc Point Manager would only find
root objects of the server.  When root groups where expanded, the same set of
root objects were returned as children of the group being expanded.

These issues were fixed in build 3.0.100 and 3.1.7, in two manners:
- The bug preventing discovery of "deep trees" on certain OPC servers was fixed.
- When/if nothing is found, root objects are no longer returned as a failsafe.

*** 69.1:8481  Add read and write delays ***
  Record Type:  Enhancement
  Resolved In:  3.1.18; 3.0.101
The OPC point device extension has two new properties which allow the user to
tune when the client begins reading and writing to the server.

Read Delay is the amount of time after device up before the client creates a
subscription and reads any values.

Write Delay is the amount of time after device up before the client attempts to
write any values to the server.

*** 69.1:8801  Writing boolean value "true" to server could fail. ***
  Record Type:  Bug
  Resolved In:  3.0.102; 3.1.24; 3.2.1
Formerly, the OPC specification to write -1 for true boolean values was not 
being followed.  In the only OPC server found that could not handle this error,
boolean write values of "true" from the Niagara client were treated as "false".
Niagara now follows this OPC specification.

#########################################################################
70  snmp
#########################################################################

=========================================================================
70.1  Fixed
=========================================================================

*** 70.1:7720  Missing support for certain ACCESS types for MIB objects ***
  Record Type:  Bug
  Resolved In:  3.0.100; 3.1.2
It was discovered that support was missing for the following ACCESS types for 
MIB objects:

 accessible-for-notify
 write-only (obsolete)
 read-create

This bug would have been discovered if you tried to load a MIB that contained
some objects with the missing ACCESS types above.  The MIB would fail to load.
Typically, MIBs do not contain these ACCESS types. Thus, this issue is expected
to be rarely encountered.

This was fixed in build 3.0.100, where support for the following ACCESS types 
were added to the types supported previously:

 not-accessible
 read-only
 read-write

This will allow loading a MIB that contains such objects.

*** 70.1:8396  TridiumR3-MIB.my file had errors ***
  Record Type:  Bug
  Resolved In:  3.0.101; 3.1.16
If you are using the NiagaraAX SNMP driver to expose a station to SNMP (i.e. the
station is an SNMP agent that responds to an outside manager), then you use
the TridiumR3-MIB.my file.  This is the MIB file that defines the structure of
data exposed to SNMP in a NiagaraAX station.  In doing some validation, we 
discovered that the TridiumR3-MIB.my file had some errors in it.  Those problems
have now been fixed.

Please note that the TridiumR3-MIB.my file is SMIv2 compliant (not SMIv1 
compliant) since it uses enumerated values starting with zero.  To clear up 
confusion, SMI stands for Structure of Management Information, and it defines 
the structure of MIB files (used by MIB compilers).  SMI is different than 
SNMPv1 and SNMPv2, which are the SNMP transport protocols (we support both 
SNMPv1 and SNMPv2).

*** 70.1:8720  DuplicateSlotException when walking MIB ***
  Record Type:  Bug
  Resolved In:  3.0.102; 3.1.23; 3.2.1
In rare cases when loading and walking a MIB during SNMP point discovery, if a 
table in the MIB caused Niagara to attempt to create a component with a 
duplicate name, an exception similar to the following would occur:

Failed [15:47:06 22-Aug-06] Job Failed
javax.baja.sys.DuplicateSlotException: Slot "MIB_ENTRY_1" already exists.
   at com.tridium.sys.schema.ComponentSlotMap.add(ComponentSlotMap.java:1629)
   at javax.baja.sys.BComponent.add(BComponent.java:728)
   at com.tridium.snmp.datatypes.BMibListTable.addEntry(BMibListTable.java:149)
   at com.tridium.snmp.datatypes.BMibCellListEntry.addChild(BMibCellListEntry.java:385)
   at com.tridium.snmp.util.BSnmpWalkMibJob.run(BSnmpWalkMibJob.java:150)
   at javax.baja.job.BSimpleJob$JobThread.run(BSimpleJob.java:83)

A simple check to ensure a unique name was added to fix this rare problem.

#########################################################################
71  tunnel
#########################################################################

=========================================================================
71.1  Fixed
=========================================================================

*** 71.1:8393  Tunnel clients disconnected with unexpected message error ***
  Record Type:  Bug
  Resolved In:  3.0.101; 3.1.16
The tunnel clients (Lon Tunnel client, Serial Tunnel client) could prematurely 
disconnect from a tunnel server with the following message - "Unexpected 
message from remote host."  It was found that tunnel framing was corrupted 
whenever a message was longer than 128 bytes.  This was fixed in the tunnel
clients in build 3.0.101 and 3.1.16.

*** 71.1:9332  IllegalArgumentException when serial tunnel is closed ***
  Record Type:  Bug
  Resolved In:  3.2.10; 3.1.31; 3.0.107
When shutting down a serial tunnel connection an IllegalArgumentException 
would display in the station output. The exception will no longer display 
in the station director starting in builds 3.0.107, 3.1.31, and 3.2.10. 

#########################################################################
72  weather
#########################################################################

=========================================================================
72.1  Fixed
=========================================================================

*** 72.1:7547  WeatherService forcast update failed, produced exceptions ***
  Record Type:  Bug
  Resolved In:  3.0.96
The WeatherService stopped functioning, creating an exception similar to:

java.lang.ArrayIndexOutOfBoundsException: Array index out of range: 0
 at com.tridium.weather.nws.NwsForecastReader.getForecast(Unknown Source)
 at com.tridium.weather.nws.BNwsWeatherProvider.updateReport(Unknown Source)
 at javax.baja.weather.BWeatherReport.doUpdateWeatherReport(Unknown Source)
 at auto.javax_baja_weather_BWeatherReport.invoke(Unknown Source)
 (etc.)

This was fixed in build 3.0.96 WeatherService code, by changing SOAP urls 
(Simple Object Access Protocol) used to access the NWS.

*** 72.1:7857  Weather Report did not display when first viewed ***
  Record Type:  Bug
  Resolved In:  3.1.16; 3.0.101
A WeatherReport (child of WeatherService) did not display current data when
first viewed--you had to refresh the CurrentWeatherView or Px page. This was
fixed in 3.1.16.

*** 72.1:9341  No icon for "Breezy Condition" ***
  Record Type:  Bug
  Resolved In:  3.2.5; 3.1.31
The WeatherService now recognizes "windy" conditions, and will
display the new windy icon whenever the condition string contains
any of the following words: "wind", "breez", "gust".

Ex: "breezes", "breezy", "windy", "gusty", "gusts"


#########################################################################
73  demo
#########################################################################

=========================================================================
73.1  Fixed
=========================================================================

*** 73.1:8916  AuditHistoryService and LogHistoryService missing in standard demo database ***
  Record Type:  Bug
  Resolved In:  3.1.25; 3.2.1
Added the AuditHistoryService and LogHistoryService to the standard demo 
station.  These are typical services used by most stations, so it was 
appropriate for the demo station as well.


#########################################################################
74  docBacnet
#########################################################################

=========================================================================
74.1  Fixed
=========================================================================

*** 74.1:6599  A new "Bacnet Quick Start" chapter was started ***
  Record Type:  Enhancement
  Resolved In:  3.0.79
A new "Bacnet Quick Start" chapter was started (still unfinished), which
provides basic procedures for using the bacnet driver's manager views to
discover BACnet devices and objects. This is *most* of the same info that was
in a separately available Word doc/pdf since sometime in 12/2004. In the
"Niagara Bacnet Concepts" chapter, a bit more info was added about BacnetDevice
component properties, and various other topics. Much more needs to be done
here.

*** 74.1:6600  Basic procedures to discover and add BACnet devices and objects ***
  Record Type:  Enhancement
  Resolved In:  3.0.80
Basic procedures were completed in the "Quick Start" chapter to discover and
add BACnet devices and objects. More details were added in the "Concepts"
chapter about the Bacnet Point Manager, including this view's Discovered and
Database tables.

*** 74.1:7828  Major changes and additions ***
  Record Type:  Enhancement
  Resolved In:  3.0.100; 3.1.4
Major changes and additions. Started a BACnet terms section in this Preface.
Reversed order of this change log to put newest changes at top.

Added new section Bacnet licensing considerations in Bacnet Driver Installation
section.

Updated various discussions and figures in the main section Niagara Bacnet
Client Concepts, including new subsections Bacnet Schedule Import Manager,
Bacnet Schedule Export Manager, Bacnet History Import Manager, and BACnet
Trend Log import notes.

Added new main section Niagara Bacnet Server Operation, with main subsections
Bacnet server configuration overview, Bacnet Export Manager, Bacnet File Export
Manager, Bacnet Niagara Log Export Manager, and Local Device notes.

Made numerous small changes in sections Bacnet Component Guides and Bacnet
Plugin Guides. Document title changed to BACnet Guide (was Bacnet Guide).


*** 74.1:8016  Added a Bacnet FAQs section to the Preface. ***
  Record Type:  Enhancement
  Resolved In:  3.0.101
Added a Bacnet FAQs section to the Preface.

#########################################################################
75  docIT
#########################################################################

=========================================================================
75.1  Fixed
=========================================================================

*** 75.1:9143  NiagaraAX Networking and IT Guide intital release ***
  Record Type:  Enhancement
  Resolved In:  3.0.104; 3.1.29; 3.2.3
A "NiagaraAX Networking and IT Guide" is now available as a PDF document
as well as in Workbench Help.

#########################################################################
76  docJaceNxStartup
#########################################################################

=========================================================================
76.1  Fixed
=========================================================================

*** 76.1:7579  Initial draft document ***
  Record Type:  Enhancement
  Resolved In:  3.0.96
Initial draft docJaceNxStartup document.


#########################################################################
77  docJaceNxsStartup
#########################################################################

=========================================================================
77.1  Fixed
=========================================================================

*** 77.1:8422  Initial draft document. ***
  Record Type:  Enhancement
  Resolved In:  3.0.101; 3.1.17
This is the initial draft of the JACE-NXS NiagaraAX Install and Startup Guide.

*** 77.1:9237  Various updates ***
  Record Type:  Enhancement
  Resolved In:  3.0.104; 3.1.30; 3.2.4
Revised licensing discussions to describe typical use of the licensing server,
versus emailed license files (sections Niagara and PC Requirements, Install
license, License Server). Updated some screen captures and made numerous minor
edits.

#########################################################################
78  docJaceStartup
#########################################################################

=========================================================================
78.1  Fixed
=========================================================================

*** 78.1:7518  Updates for JACE-2 ***
  Record Type:  Enhancement
  Resolved In:  3.0.95
Noted different factory default IP address for JACE-2 (different than
JACE-4 and -5 series). Added more references and notes about the JACE-2 in the
sections about TCP/IP configuration and System shell.

*** 78.1:9236  Various updates ***
  Record Type:  Enhancement
  Resolved In:  3.0.104; 3.1.30; 3.2.4
Reversed order of this log to put newest changes at top. Revised licensing
discussions to describe typical use of the licensing server, versus emailed
license files (sections Niagara and PC Requirements, Install license,
License Server). Updated many screen captures to reflect more current software.

#########################################################################
79  docKitControl
#########################################################################

=========================================================================
79.1  Fixed
=========================================================================

*** 79.1:7664  Minor changes ***
  Record Type:  Enhancement
  Resolved In:  3.0.99
Minor changes only. Added convenience links in Alphabetical list of kitControl
components, plus a link back to this page from online Help Guide on Target
for any kitControl component. Fixed several screencap figures and links.

*** 79.1:8717  Setup & details for LoopPoint & truth tables for Logic ***
  Record Type:  Enhancement
  Resolved In:  3.0.101; 3.1.23; 3.2.1
Provided setup and operation details for the LoopPoint, and truth tables for
Logic components And, Or, Not, and Xor. More details and examples are included
for components EnumSelect, NumericBitAnd, NumericBitOr, and NumericBitXor.

Reversed the order of this change log to list newest document changes at the
top.

#########################################################################
80  docLonworks
#########################################################################

=========================================================================
80.1  Fixed
=========================================================================

*** 80.1:7284  Updated Niagara Lonworks Concepts & others ***
  Record Type:  Enhancement
  Resolved In:  3.0.91
Added more information in the Niagara Lonworks Concepts section, including new
sections LonNetwork status and monitor notes, Lon Comm Config notes,
Network variable (nv) poll/update rules, Link descriptor notes, Lon device
overview, DeviceData, Lon device actions, About LonComponents (with
subsections), and Lon proxy point type selection. Made various other minor
edits, plus updates to screen captures. Moved copyright and trademark
information to front of document and used new (PDF) cover design.

*** 80.1:7351  Added many new sections ***
  Record Type:  Enhancement
  Resolved In:  3.0.92
Added new procedures in Lonworks Quick Start section under Bind Lon proxy
points. Added more information in the Niagara Lonworks Concepts section,
including many new sections under Lon Link Manager, Lon Utilities Manager, and
Lon Router Manager. Made various other minor edits, plus updates to screen
captures.

*** 80.1:7414  Added new subsections ***
  Record Type:  Enhancement
  Resolved In:  3.0.94
Reordered several areas in the Niagara Lonworks Concepts section, adding new
main subsections Understanding network management scenarios, Notes on unit
conversion, Notes when configuring as Lon node. Made various other minor edits,
plus updates to screen captures.

*** 80.1:7525  Added new appendix Workbench Tools ***
  Record Type:  Enhancement
  Resolved In:  3.0.96
Added new appendix Workbench Tools, with sections on Lon Xml Tool and Lonworks
Service. Made various other minor content edits, plus updates to screen
captures.

*** 80.1:7642  Added new appendix and sections ***
  Record Type:  Enhancement
  Resolved In:  3.0.98
Added new appendix Lon tunneling, with sections Lon tunnel overview, Client
side (PC application), Station side (TunnelService), and Lon tunneling usage
notes.

Added new section About the LonNetwork wire sheet, along with a related
section Misuse of Lon proxy points. Made various other minor edits.

*** 80.1:8607  Updates to Lonworks Guide ***
  Record Type:  Enhancement
  Resolved In:  3.0.101; 3.1.22
Various edits and additional notes related to new functions, including some
introduced in AX-3.1. Sections affected are About lonworks palette components,
"Lon Comm Config notes", "Affects of tuning policy, by LonComponents",
"LocalLonDevice External Config", Lon Device Manager, "NetworkVariableLinks"
(tab of Lon Link Manager), new section about Lon device "ImportXml command",
new section about the (AX-3.1 only) Lon device action "Trim", and various
subsections under Notes when configuring as Lon node, especially "Local Nvs
required by LNS". A few other components and plugins (view) summary
descriptions were added (LonTime, LonTodEvent, LinkFilter, LinkFilterView,
LonXmlCreate).

Updated some sections of the Lon Xml Tool section of the Workbench Tools appendix.

Reversed order of this change log to put newest changes at top.


#########################################################################
81  docNdio
#########################################################################

=========================================================================
81.1  Fixed
=========================================================================

*** 81.1:7361  Added Ndio Network monitor notes ***
  Record Type:  Enhancement
  Resolved In:  3.0.93
Added new section Ndio Network monitor notes, explaining the Ndio reboot
logic added to the Ndio monitor ping (see Figure 3). Moved copyright and
trademark information to front of document and used new (PDF) cover design.

#########################################################################
82  docOpc
#########################################################################

=========================================================================
82.1  Fixed
=========================================================================

*** 82.1:8848  Added more details throughout ***
  Record Type:  Enhancement
  Resolved In:  3.0.102; 3.1.24; 3.2.1
Reworked as a single-source document, replacing the previous docOpc in
NiagaraAX Help and the PDF-only NiagaraAX Opc User Guide. Includes more details
throughout, as well as various screencaps in the Niagara Opc Concepts section.

#########################################################################
83  docPlatform
#########################################################################

=========================================================================
83.1  Fixed
=========================================================================

*** 83.1:7283  Updated Change Date/Time & cover/copyright ***
  Record Type:  Enhancement
  Resolved In:  3.0.91
Made a minor change to the Platform Administration section Change Date/Time,
noting different popup dialog in rare case if Win32 host does not support a
Java time zone (see Figure 53). Moved copyright and trademark information to
front of document and used new (PDF) cover design.

*** 83.1:7339  Addition of dialog about restoring TCP/IP settings ***
  Record Type:  Enhancement
  Resolved In:  3.0.92
Made changes to the Distribution File Installer section Restoring a backup,
noting recent addition of dialog about restoring TCP/IP settings. 
Also added brief note about this in the Backup section under Platform
Administration section.

*** 83.1:7385  Updated Software Manager and Dialup ***
  Record Type:  Enhancement
  Resolved In:  3.0.93
Added section Import vs. copy into modules, under Software Manager section
software database, which explains options when copying newly-received software
modules on a Workbench PC. Updated screenshots and property descriptions in all
sections under the Dialup Configuration section, to reflect dialup changes
since original document.

*** 83.1:7433  Enhanced Operations from a change in module content level ***
  Record Type:  Enhancement
  Resolved In:  3.0.94
Added more details in Set Module Filter section. Operations from a change in
module content level.

*** 83.1:7606  Edited various sections in PlatformServices ***
  Record Type:  Enhancement
  Resolved In:  3.0.96
Edited various sections in PlatformServices, including new section actions and
various items related to JACENX hardware monitoring.

*** 83.1:8381  Updated for changes in NiagaraAX-3.1 ***
  Record Type:  Enhancement
  Resolved In:  3.0.101; 3.1.16
Updated for changes in NiagaraAX-3.1 (typically noted as AX-3.1), and
reversed the order of this change log to list most recent document versions at
top. New sections include Ddns Configuration, platform connection, and Models
of platforms. Various other changes/additions were also made in the sections
About platform differences , PlatformServices and Platform Component Guides,
largely to describe new properties and components, often related to new
platform types.

*** 83.1:8445  Removed eliminated components ***
  Record Type:  Enhancement
  Resolved In:  3.0.101; 3.1.18
Removed platform "part" components and the parent "RemoteDaemonPlatform"
(Platform Snapshot) component from the Platform Component Guides section - these
provisioning-related items were eliminated.

*** 83.1:9238  Various updates ***
  Record Type:  Enhancement
  Resolved In:  3.0.104; 3.1.30; 3.2.4
Revised the descriptions and screen captures in the License Manager section to
better describe online functions with the licensing server. Added new
"PlatformServices binding and link caveats" section to describe known
limitations. Made several other minor edits.

#########################################################################
84  docProvisioning
#########################################################################

=========================================================================
84.1  Fixed
=========================================================================

*** 84.1:8222  New NiagaraAX Provisioning Guide ***
  Record Type:  Enhancement
  Resolved In:  3.1.13; 3.0.101
New NiagaraAX Provisioning Guide

*** 84.1:8444  Minor edits ***
  Record Type:  Enhancement
  Resolved In:  3.0.101; 3.1.18
Minor edits from another content review, including changes in the Provisioning
Installation section, the quick-start procedure "Configure the NiagaraDevice
extensions" and the Provisioning overview. Removed sections about the Software
station extension's "platform snapshot" (as a component), along with its
"Daemon Platform View". This reflects changes in the provisioning module (these
items were removed from a station's component space).

*** 84.1:11158  Reference 3.3 Features in Provisioning for Niagara Networks ***
  Record Type:  Enhancement
  Resolved In:  3.1.31; 3.2.18; 3.3.18
Added several notes in this Preface referring to a different Provisioning for
Niagara Networks document about the changed provisioning model starting in
AX-3.3, noting that this document is specific to provisioning in AX-3.1 and
AX-3.2. Related to this is a new section Provisioning Service Conversion. An
About this document section was also added to this Preface.

#########################################################################
85  docProvisioningNiagara
#########################################################################

=========================================================================
85.1  Fixed
=========================================================================

*** 85.1:11162  Provisioning Guide Enhanced for R3.3 ***
  Record Type:  Enhancement
  Resolved In:  3.1.31; 3.2.18; 3.3.18
docProvisioningNiagara is the equivalent document to the previous NiagaraAX
Provisioning Guide, which applied only to an AxSupervisor running prior
releases AX-3.1 or AX-3.2. Although there are many similarities between Niagara
provisioning in AX-3.1 and AX-3.3, including the basic organization of this
document, enough changed such that a separate document was warranted. 

#########################################################################
86  docSnmp
#########################################################################

=========================================================================
86.1  Fixed
=========================================================================

*** 86.1:8041  Added Getting Started and SNMP Concepts Chapters ***
  Record Type:  Enhancement
  Resolved In:  3.0.101; 3.1.7
Added Getting Started and SNMP Concepts Chapters.

#########################################################################
87  docSoftJace
#########################################################################

=========================================================================
87.1  Fixed
=========================================================================

*** 87.1:7839  New docSoftJace Module ***
  Record Type:  Enhancement
  Resolved In:  3.0.100; 3.1.4
This is documentation for the AX SoftJACE (Java Application Control Engine). 
It is NiagaraAX Framework software that runs on a user-supplied PC, providing
many of the same benefits as a JACE controller.

*** 87.1:9187  Many Enhancements ***
  Record Type:  Enhancement
  Resolved In:  3.0.104; 3.1.30; 3.2.4
In the "SoftJACE Windows security notes" section, added a new section "Platform
daemon port". Reworked the section Install the SoftJACE software to reflect the
improved AX-3.1 SoftJACE installation wizard, which asks fewer questions and
automatically installs and starts the needed NiagaraAX platform daemon. In the
various step sections under Run the Commissioning Wizard, made numerous small
changes and removed notes about the SoftJACE rebooting if a station is
installed (this was fixed). Updated the majority of screen captures used in the
document.

*** 87.1:9319  Many Enhancements ***
  Record Type:  Enhancement
  Resolved In:  3.0.105; 3.1.30; 3.2.5
Modified licensing discussions to explain the online submission for a license
request. In the "About the SoftJACE license" section, added a new section
"Submitting a license request", and changed another section to "Manually
checking host ID and submitting license request". Also separated procedures
under the "Install license" step under the Run the Commissioning Wizard
section. Added one additional FAQ in the AX SoftJACE FAQs section, to state
that SoftJACE installation from CD should happen only once.

#########################################################################
88  docUser
#########################################################################

=========================================================================
88.1  Fixed
=========================================================================

*** 88.1:7285  Many new sections & updates ***
  Record Type:  Enhancement
  Resolved In:  3.0.91
Added new sections: About schemes, Types of schemes, Table controls and
options, Chart controls and options, About the History Ext Manager menu,
About the history extension manager popupu menu items, About the history
extension manager toolbar icons, Niagara shell commands, nre (station)
commands, wb (Workbench) commands, plat (platform) commands.

Edited sections About alarms and About Histories to replace redundant text with
references to single description location. Added or corrected missing or
incorrect property descriptions. Edited Plugin Guides, Component Guides,
References to augment references, correct missing or inaccurate descriptions
and update links.

*** 88.1:7352  Edited & Added sections ***
  Record Type:  Enhancement
  Resolved In:  3.0.92
Added new sections to Customizing the Workbench environment.

Edited and added sections to Types of Workbench tools.


*** 88.1:7362  Edited & Added sections ***
  Record Type:  Enhancement
  Resolved In:  3.0.93
Added Types of files section to the About ORDs section.

Edited and added content to Types of Workbench tools section.

Added new procedures to Using the palette side bar section.

Added content to sections in the Customizing the Workbench environment section.


*** 88.1:7398  Edited & Added sections ***
  Record Type:  Enhancement
  Resolved In:  3.0.93
Edited, added content, and renamed sections in About Workbench tools.

Added Batch editing (or batch processing) section.

Added About the Todo list popupu menu items section to Types of popup menu items.

Added About the Todo list toolbar icons section to Types of toolbar icons.


*** 88.1:7435  Edited and corrected broken links ***
  Record Type:  Enhancement
  Resolved In:  3.0.94
Edited and corrected broken links to online help, including links in About
Workbench tools, About Security, and Component Guides.

*** 88.1:7517  Many updates ***
  Record Type:  Enhancement
  Resolved In:  3.0.95
Edited graphics and callouts to standardize resolution, size, & layout in About
NiagaraAX Framework, About Workbench.

Edited links in Component Guides and Glossary

Added information about the Jobs palette to About Workbench and to
References.Edited About the Window menu and About the locator barsections.

Added section About the point manager popup menu items.


*** 88.1:7607  Edited & Added sections ***
  Record Type:  Enhancement
  Resolved In:  3.0.96
Removed obsolete references to Raster Editor in Component Guides, and Plugin
Guides.

Added procedures in Performing Workbench tasks sections Using the palette side
bar (to create and edit palettes) and Working with modules (to create a
module).

Edited section New module wizard in the About Workbench tools section.

Edited description of property Time Delay in the About alarm extension
properties section to note this property does not apply to status transitions
to (or from) Fault.

*** 88.1:7731  Correct image in "About Workbench window controls" ***
  Record Type:  Bug
  Resolved In:  3.0.100
The incorrect image was in "About Workbench window controls".

*** 88.1:8558  Various new components and views ***
  Record Type:  Enhancement
  Resolved In:  3.0.101; 3.1.20
Various new components and views added in the Component Guides and Plugin
Guides sections, mostly related to the driver module containing the
FileNetwork. Other minor edits and notes related to NiagaraNetwork provisioning
(see NiagaraStation component notes).

*** 88.1:11163  docUser R3.3 Enhancements ***
  Record Type:  Enhancement
  Resolved In:  3.1.31; 3.2.18; 3.3.19
 Added the NiagaraAX-3.3-applicable section About ScheduleSelector components to
the About Scheduling section, including topics describing ScheduleSelector
components, properties, and examples of how to use them.

 Edited Component Guides to add component descriptions of the following
NiagaraAX-3.3-applicable components: BooleanScheduleSelector,
NumericScheduleSelector, StringScheduleSelector, EnumScheduleSelector,
HistoryPointList, HistoryPointListItem.

 Edited About Histories to add NiagaraAX-3.3-applicable section About the Live
History Chart View and edit Types of history views. 

#########################################################################
89  docWeather
#########################################################################

=========================================================================
89.1  Fixed
=========================================================================

*** 89.1:7340  Many additions ***
  Record Type:  Enhancement
  Resolved In:  3.0.92
Added more screen captures, and fixed Px usage information in a few component
descriptions. More information added about available actions and properties.
Moved copyright information to front of document.

*** 89.1:8236  Expanding "Doc Weather" in Help disabled scroll bar ***
  Record Type:  Bug
  Resolved In:  3.0.101; 3.1.13
Previously, in the Table of Contents of the Niagara Help dialog, when you
expanded the "Doc Weather" entry the scroll bar would become stuck and an
exception was generated.  It was found that toc.xml in docWeather contained 
an illegal character (a0); this was removed beginning in build 3.0.101 and
3.1.13.

#########################################################################
90  eas
#########################################################################

=========================================================================
90.1  Fixed
=========================================================================

*** 90.1:7967  Meter creation could fail on duplicate index ***
  Record Type:  Bug
  Resolved In:  3.1.31
It was discovered that creating a new meter could fail in the case of a 
duplicate index (ID) being generated (this happens transparent to the user and
is used by VES to uniquely identify a meter).  When a meter is created, a 
random number generator is used to assign an integer ID (index) to the meter.  
This gets stored with the rest of the meter information in the "METER" 
relational db table (part of the configuration).  We noticed that the
code for the meter creation didn't correctly account for the case where the 
random ID generated matches one that already exists in the "METER" table.  In 
such a (rare) case, this could cause the meter creation to fail.

In build 3.1.6, the code has now been fixed so that it tries up to 10 times in
the case of a duplicate meter ID.  This follows the convention of the other 
configuration components that get stored with an ID (i.e. sites, datapoints, etc.).


*** 90.1:8064  Split value/percent into separate table columns ***
  Record Type:  Enhancement
  Resolved In:  3.1.9
It was reported that customers were trying to export and use the relative contribution report's
data table in an application outside of VES (i.e. Excel).  However, the "data", "rawdata", and "normalized" 
columns of the exported data table included both the value and percent (in parenthesis).  Users were 
finding it very difficult to use this exported table data in Excel because they needed to split the value 
and percentage into separate columns.  Some users built special Excel macros to go through each row and
in an effort to split the value and percentage fields.

In build 3.1.9, value and percentage were split into separate columns in the relative contribution report's 
data table.  This issue also applies to the bill reconciliation report in the cost breakdown analysis pie chart
table.  Now, if you export either of these tables to csv, they will have separate columns for value and percentage.

*** 90.1:8097  All colors default to grey when first open Spectrum report ***
  Record Type:  Bug
  Resolved In:  3.1.9
Some users noticed that when they first loaded the Spectrum Summary report, the 
default colors would all be grey.  So if a spectrum report was run with these 
defaults all set to grey, then the result would be a completely grey screen.  
The default colors should be blue, white, and red.  This bug was fixed in 
build 3.1.9, so that the default grey colors are no longer used--instead the
proper blue, white, and red settings are used.

Note this problem was intermittent, and did not occur for all users.

*** 90.1:8130  If create new database fails, "Sql Server Create New Database" property should not reset ***
  Record Type:  Bug
  Resolved In:  3.1.10
Previously, if you had the "Sql Server Create New Database" property set to
true (means it will first attempt to create a new Sql Server database when 
the open database command is invoked), and if the open database action fails, 
the "Sql Server Create New Database" property would get reset to false, no 
matter what.  If a failure occured in creating the new database, it should not
reset this property.  In build 3.1.10 this was changed, such that this property
will not reset on a failure to create the new database.

*** 90.1:8147  Licensing enhanced to support ability to license per report ***
  Record Type:  Enhancement
  Resolved In:  3.1.11
The licensing for VES was improved to allow for individual report licensing.
For any existing users prior to this change, they will need to obtain a new 
license when they upgrade.


*** 90.1:8334  Get Details chart failed from Exceptions report ***
  Record Type:  Bug
  Resolved In:  3.1.15
In the Exceptions report, if you tried to use the "Use Baseline & Percentage"
comparison option, after running the report, it would fail to allow you to 
click to 'Get Details' for any results.  The following exception would also 
occur in the Java Plugin's console.  This bug has now been fixed.

Exception in thread "AWT-EventQueue-2" java.lang.NullPointerException
 at com.tridium.eas.ui.chart.PopulationTimeSeries.getMin(PopulationTimeSeries.java:214)
 at com.tridium.eas.ui.chart.PercentTimeSeries.getMin(PercentTimeSeries.java:84)
 ...<many more>...
 at java.awt.EventDispatchThread.run(Unknown Source)


*** 90.1:8412  New Normalizer assignment by data point ***
  Record Type:  Function
  Resolved In:  3.1.17
The VES E2 Profiler reports, as well as two of the Cost Profiler reports (Cost Ranking
and Cost Contribution), now support a new normalization feature: normalization by a
production unit data point.  This basically allows you to normalize a report input by
another data point.  When a report is run, it goes through each timestamped value of 
the report input's history, and it divides the value by the corresponding timestamped 
value in the history for the designated normalizing data point.

In order to assign a data point in VES as the normalizing data point for a report input,
the user should be able to copy and 'Paste As Normalizer' onto a report input.  Another
option for assigning a normalizing data point is to select the 'Configure' option from
the right-click pop-up on a report input, and from the Configure dialog window, you can
select a data point to use as the normalizing data point.

*** 90.1:8413  When a VES report first loaded, it temporarily appeared incomplete and locked up ***
  Record Type:  Bug
  Resolved In:  3.1.17
Previously, when a VES report was first loaded (especially if you were loading 
a saved report with auto run set to true), then when the report first appeared, 
it temporarily appeared locked up, and some of the report components looked 
incorrect.  For example, the tree at the far left displayed "food, sports, 
colors..." instead of the proper site selection tree.  This happened because 
the applet was trying to initialize on the same thread that the report 
initialization occurred.  This caused the applet window's painting/validation 
to be held up by the running report.  A simple fix was applied to offload the 
report initialization (auto run) onto another thread.

*** 90.1:8414  Better support for histories collected at irregular intervals ***
  Record Type:  Enhancement
  Resolved In:  3.1.20
This issue has become more important with the addition of the new product 
normalization feature.  Users will probably import their production unit 
histories from some outside format (i.e. CSV, RDB, etc).  These logs
will probably not be collected at an interval that meets our expectation in 
VES (i.e. 15 min, 20 min, 30 min, 1 hr).  It will probably more likely come in 
the form of 1 day or 1 month intervals.

VES does not handle data collected at these 'unrecognized' intervals very well.
So, it has been improved to try to estimate (find an average) of the collection
interval to use for these irregular intervals, and then "rollup" the values as 
appropriate.  Please note that it is still highly recommended that the collection
interval of your histories is one of the expected intervals (i.e. 15 minutes).
Irregular intervals can cause unexpected results.

*** 90.1:8415  Very small negative numbers displayed as "-0" in VES reports ***
  Record Type:  Bug
  Resolved In:  3.1.17
This bug was discovered in the Exceptions report, however, it may also apply 
to some of the other VES reports.  Previously, if the results included a very 
small negative number (between -1 and 0), then the display would always 
indicate "-0" as the value.  This doesn't give enough precision to see
the actual value, so the precision for these very small negative values 
was fixed.

*** 90.1:8416  In Exceptions detail table, move units to column header ***
  Record Type:  Enhancement
  Resolved In:  3.1.17
It was reported in the past that customers like to export and use a report's 
table (i.e. in Excel).  However, the data columns in the Exceptions report 
detail table include both the value and units.  Users find it very difficult 
to use the exported table in Excel because they need to split the value and 
unit, so they sometimes have to build a macro to go through each row and
try to split the value and unit.  It made more sense to put the units into the 
column header, and leave only the value in the table rows, so this was changed
on the Exceptions report detail table.

*** 90.1:8417  Add 'Other Consumption' and 'Production Units' data point types ***
  Record Type:  Enhancement
  Resolved In:  3.1.17
With the introduction of the product normalization feature to VES AX, users 
will likely be importing histories containing production unit data.  This type 
of data is normally considered to act like consumption when it is rolled up.  

So, in order to make this easier for users to configure, two more VES 
data point types were added: 'Other Consumption' and 'Production Units'.  
Users should use these types (instead of 'Other') for imported production unit 
histories, since they will ensure that the rollup calculation is handled 
correctly.

*** 90.1:8518  'Production Units' and 'Other Consumption' types should support "Main of its type" feature ***
  Record Type:  Enhancement
  Resolved In:  3.1.19
It was discovered that the new data point types introduced for the product 
normalization feature, 'Production Units' and 'Other Consumption', did not 
support the "This is the Main Meter/Data Point of its type for the site" 
feature.  So this was fixed, such that production unit data points in VES can 
be used in the Aggregation Analysis and Enterprise Ranking reports.

*** 90.1:8523  Allow for 'Auto' detection of table granularity interval ***
  Record Type:  Enhancement
  Resolved In:  3.1.19
In the Correlation Report, there was a setting for the table granularity 
interval that used 20 as the default.  This was not a safe default, since data 
values could be much higher than 20. In such cases, generating a table with a 
granularity of 20 could cause things to be very slow.  

So, a new 'Auto' checkbox was added as the default setting, so the table 
granularity interval will automatically be computed based on the data (divides 
the range by 50 to determine the auto interval to use).  The user can always 
uncheck this 'Auto' checkbox to enter their own custom interval, just like 
before.  However, this default 'Auto' setting is more efficient, and helps 
users avoid hang ups.

*** 90.1:8531  Added a new E2 Profiler report: the Correlation Report ***
  Record Type:  Enhancement
  Resolved In:  3.1.14
A new E2 Profiler report was added to VES:

The Correlation Report allows you to correlate two logs of data over a user defined 
period of time. This can be useful for determining the relationship between any two 
data points. It allows the user to select the data points to use for the x and y axis 
of a correlation chart (scatter plot), and then use the configuration parameters to 
enable a linear regression trend line (automatic or custom), set up linear regression 
forecasting, and tweak the tabular results. The Correlation Report also leverages from 
the other common features available to all E2 Profiler reports.

The Correlation report can be useful for determining a relationship between energy data 
logs and timestamped unit production logs. This can allow you to forecast energy usage 
based on predicted production units. 

Refer to the online documentation in VES for more details.


*** 90.1:8544  Data cleansing was off for irregular intervals (i.e. not a 15 minute interval) ***
  Record Type:  Bug
  Resolved In:  3.1.20
For certain conditions, the data cleansing algorithm was processing the data 
too late.  For irregular collection intervals (i.e. not a 15 minute collection 
interval), the algorithm was performing the rollup to 15 minutes, and then 
performs the data cleansing filter afterwards.  This was out of order.  The 
data cleansing filter was fixed so that it is now performed on the original 
data at its collection interval, and then the rollup to 15 minutes occurs
afterward.

*** 90.1:8583  Korean OS JDBC Problem ***
  Record Type:  Bug
  Resolved In:  3.1.21
VES AX relies on the jTDS driver to support a connection to a relational 
database (i.e. MSDE).  jTDS is a Java implementation of JDBC (refer to 
http://jtds.sourceforge.net/ for details).  In the Korean OS (and non-English 
OS) the version of the jTDS driver used could not support a connection to MSDE, 
because it caused a 'default charset' exception.  Reverting back to jTDS version
0.9 appears to solve the problem, so the switch back to jTDS v0.9 was made in
VES AX.

*** 90.1:9031  Eas license check fails for unlimited dataPoint or costMeter limit ***
  Record Type:  Bug
  Resolved In:  3.1.27
Prior to this change, if you had a license including VES ("eas" feature) that
provided unlimited use for either number of data points or cost meters,
the license checking would fail (i.e. you would get an "eas not licensed" fault).
That is, if the dataPoint.limit and/or costMeter.limit were set to "none" in the
license, it would fail to recognize that this provides unlimited access to VES.
The license checking code was fixed, and this case is now properly handled.

*** 90.1:9040  Weather normalization discrepancies between various reports ***
  Record Type:  Bug
  Resolved In:  3.1.27
It was discovered that the weather normalization feature in VES was giving 
inconsistent results between various reports.  In particular, discrepancies
were noticed between the Aggregation Analysis, Enterprise Ranking, Point 
Trending, and Relative Contribution reports.  It was also discovered that an
outside temperature log using units different from those selected as the 
'Degree Day' setting in these reports was causing the results to be skewed.

The discrepancies related to the weather normalization feature in the 
aforementioned VES reports have now been resolved.

*** 90.1:9055  Cost profiler failed on data collected at certain intervals ***
  Record Type:  Bug
  Resolved In:  3.1.27
It was discovered that data logs used in Cost Profiler that were collected at
certain intervals (i.e. 1 hour) were experiencing failure.  The standard output
for the station would display the following exception when trying to run one
of the cost profiler reports on data collected at these special intervals:

Caught exception in FlatFeePerUnit.computeCostForRange():
java.lang.ArrayIndexOutOfBoundsException: 2880
        at com.tridium.eas.api.TSDataSummary$3.getSample(TSDataSummary.java:144)
        at com.tridium.eas.cost.util.RawCostData$PopulationResult.next(RawCostData.java:156)
        at com.tridium.eas.cost.rate.components.FlatFeePerUnit.computeCostForRange(FlatFeePerUnit.java:403)
        at com.tridium.eas.cost.rate.components.RateComponent.computeCostForInterval(RateComponent.java:357)
        at com.tridium.eas.cost.rate.Rate.computeCostForInterval(Rate.java:1039)
        at com.tridium.eas.cost.rate.Rate.doComputeForInterval(Rate.java:821)
        at com.tridium.eas.cost.rate.Rate.computeForInterval(Rate.java:773)
        at com.tridium.eas.cost.rate.RateHistory.computeCostForInterval(RateHistory.java:370)
        at com.tridium.eas.cost.rate.RateHistory.doComputeForInterval(RateHistory.java:286)
        at com.tridium.eas.cost.rate.RateHistory.computeForInterval(RateHistory.java:227)
        at com.tridium.eas.cost.report.ReconciliationReport.runReport(ReconciliationReport.java:423)
        at com.tridium.eas.web.EasCostHandler.runReconciliation(EasCostHandler.java:1349)
        at com.tridium.eas.web.EasCostHandler.doPost(EasCostHandler.java:582)
        at com.tridium.eas.web.EasServlet.doPost(EasServlet.java:1868)
        at com.tridium.eas.BEasService.doPost(BEasService.java:1369)
        at javax.baja.web.BWebServlet.service(BWebServlet.java:125)
        at com.tridium.web.WebProcess.serviceWebServlet(WebProcess.java:374)
        at com.tridium.web.WebProcess.service(WebProcess.java:79)
        at com.tridium.web.SysServlet.service(SysServlet.java:105)
        at javax.servlet.http.HttpServlet.service(HttpServlet.java:802)
        at com.tridium.httpd.ServiceThread.handleRequest(ServiceThread.java:207)
        at com.tridium.httpd.ServiceThread.run(ServiceThread.java:61)        


This bug has now been fixed.

*** 90.1:9059  EAS Logs webpage was sometimes partially complete if numerous logs ***
  Record Type:  Bug
  Resolved In:  3.1.27
Under special circumstances (i.e. when there are a lot of configured logs), it
was possible for the EAS Logs webpage to not load completely.  This page is
accessed from the main VES homepage by clicking the 'View Logs' link at the
bottom.  If a lot of logs exist in the database, this page would sometimes only
partially load.  

This bug has now been fixed, so that the EAS Logs page will fully load.

*** 90.1:9218  Product normalization incorrect for histories not collected at 15-minute intervals ***
  Record Type:  Bug
  Resolved In:  3.1.30; 3.2.4; 3.1.29.1
There was a bug found in the new product normalization feature of VES.  If your
normalizing data is collected at a non 15-minute interval, then it was possible
that the results would be skewed due to a rollup problem on the normalizing
data.  This bug has now been fixed, so that the normalizing data will be rolled
up as appropriate for its declared type (ie. outside air temperature types are
rolled up using the average value for the interval, consumption types are 
spread out evenly over the interval, and demand types use the maximum value 
for the interval).

*** 90.1:9540  Eas Demo data generator causes 'By Floor Area' filtering to break ***
  Record Type:  Bug
  Resolved In:  3.1.31; 3.1.30.1; 3.2.9
If you had a station running VES (Eas Service installed), and you created VES
demo data by using the eas demo generator, then a side effect of the demo data
generation was to remove the 'By Floor Area' groupings as defined in the VES
GROUP_PROP Sql table.  So you might have noticed that if you chose the 'By
Floor Area' filter for the selection tree in any of the reports, it would appear
blank.  

This bug has now been fixed, so that both the eas demo generator won't remove
the 'By Floor Area' groupings, and a check in VES was also added to see if these
groupings are missing, and if so, automatically re-add them on station restart.


*** 90.1:9543  Add missing 'By Floor Area' ranges ***
  Record Type:  Bug
  Resolved In:  3.1.31; 3.2.9; 3.1.30.1
When using the 'By Floor Area' grouping feature in VES, you may have noticed
that the end range was closed and didn't allow for any ranges greater than
200000.  The following 'By Floor Area' ranges were added to the existing
default ones:

200001-300000
300001-500000
500001+


*** 90.1:9714  VES not using correct TimeZone database ***
  Record Type:  Bug
  Resolved In:  3.1.31; 3.2.11; 3.1.30.3
It was discovered that VES was using the wrong TimeZone implementation (it was
using the java.util.TimeZone implementation in some places).  VES has now been
fixed to use the Niagara timezone database (as specified in timezones.xml).
This allows VES to benefit from the new DST rule changes that go into effect
in 2007.

Prior to this change, if you had an updated timezones.xml, you would notice 
that the VES reports might behave strangely around the DST switchover time
ranges.  You may have observed extra data, that didn't appear consistent with
the rules defined in timezones.xml.  This fix should clear up those
problems, and make it work consistently with the rules defined in timezones.xml.

*** 90.1:9741  Allow online EAS help to be branded ***
  Record Type:  Enhancement
  Resolved In:  3.1.30.3; 3.2.12; 3.1.31
In addition to the customizeable (and brand-able) home page, the online EAS help
html pages have now been enhanced to support branding.  In order to support
this branding effort, 3 new <server> tags were addded:

To insert the brand logo:  

<server>brandLogo</server> (case sensitive) resolves to the following html:  
<img src="pathToLicensedEasBrandLogo">

also you can optionally add attributes as follows (don't forget to insert the colon after the 
word brandLogo, and spaces are important also): 

<server>brandLogo: width="340" height="50" alt="EnergyLogo"</server> resolves to the following 
html:  
<img src="pathToLicensedEasBrandLogo" width="340" height="50" alt="EnergyLogo">
                                      

To insert the brand name (long form): 

<server>longBrandName</server>  (case sensitive) resolves to the following text (assuming "vykon" 
brand) - Vykon Energy Suite

 
To insert the brand name (short form): 

<server>shortBrandName</server>  (case sensitive) resolves to the following text (assuming "vykon" 
brand) - VES


Note that the translations of the brand information is based on the station's
license (ie. the "eas" feature has an optional "brand" attribute, which defines
the branding to use).


*** 90.1:9742  Default Guest user causes exception with logging into VES from a browser ***
  Record Type:  Bug
  Resolved In:  3.2.12; 3.1.31; 3.1.30.3
It was discovered that if the default guest user was enabled for a station running
the Eas Service (and the default guest user has the appropriate permissions
to access EAS), then when going to the EAS homepage from a browser 
(ie. http://host/eas), the following exception was being thrown and the 
EAS homepage wouldn't be loaded unless you forced a login (it would show a
500 Server Not Found error).


java.lang.NullPointerException
 at com.tridium.util.EscUtil.escape(EscUtil.java:97)
 at javax.baja.naming.SlotPath.escape(SlotPath.java:216)
 at javax.baja.user.BUserService.getUser(BUserService.java:263)
 at com.tridium.eas.web.EasServlet.getUser(EasServlet.java:164)
 at com.tridium.eas.web.EasServlet.getMain(EasServlet.java:441)
 at com.tridium.eas.web.EasServlet.doGet(EasServlet.java:381)
 at com.tridium.eas.BEasService.doGet(BEasService.java:1303)
 at javax.baja.web.BWebServlet.service(BWebServlet.java:123)
 at com.tridium.web.WebProcess.serviceWebServlet(WebProcess.java:377)
 at com.tridium.web.WebProcess.service(WebProcess.java:79)
 at com.tridium.web.SysServlet.service(SysServlet.java:105)
 at javax.servlet.http.HttpServlet.service(HttpServlet.java:802)
 at com.tridium.httpd.ServiceThread.handleRequest(ServiceThread.java:207)
 at com.tridium.httpd.ServiceThread.run(ServiceThread.java:61)


This problem has now been fixed so that the default guest user is 
recognized and allows access (if guest permissions allow it).

*** 90.1:10574  Point Trending report won't save under certain configurations ***
  Record Type:  Bug
  Resolved In:  3.3.4; 3.2.17; 3.1.31
It was discovered that there was a bug when attempting to save a Point 
Trending report that caused it to fail (refer to the java console
exception below).  It only occurred if you tried to save a Point Trending 
report that had a configured baseline AND the x or y correlations were set 
to 'Do not correlate'.

This bug has now been fixed.


java.lang.NullPointerException
 at com.tridium.eas.ui.reports.PointTrendingParameters.getIndexOf(PointTrendingParameters.java:317)
 at com.tridium.eas.ui.reports.PointTrendingParameters.saveParams(PointTrendingParameters.java:284)
 at com.tridium.eas.ui.reports.ReportParameters.save(ReportParameters.java:276)
 at com.tridium.eas.ui.reports.EasReport.saveReport(EasReport.java:860)
 at com.tridium.eas.ui.reports.EasReport.buttonPressed(EasReport.java:906)
 at com.tridium.eas.ui.reports.PointTrending.buttonPressed(PointTrending.java:790)
 at com.tridium.eas.ui.EasApplication.actionPerformed(EasApplication.java:740)
 at com.tridium.eas.ui.reports.EasReport.actionPerformed(EasReport.java:886)
 at javax.swing.AbstractButton.fireActionPerformed(Unknown Source)
 at javax.swing.AbstractButton$Handler.actionPerformed(Unknown Source)
 at javax.swing.DefaultButtonModel.fireActionPerformed(Unknown Source)
 at javax.swing.DefaultButtonModel.setPressed(Unknown Source)
 at javax.swing.plaf.basic.BasicButtonListener.mouseReleased(Unknown Source)
 at java.awt.AWTEventMulticaster.mouseReleased(Unknown Source)
 at java.awt.Component.processMouseEvent(Unknown Source)
 at javax.swing.JComponent.processMouseEvent(Unknown Source)
 at java.awt.Component.processEvent(Unknown Source)
 at java.awt.Container.processEvent(Unknown Source)
 at java.awt.Component.dispatchEventImpl(Unknown Source)
 at java.awt.Container.dispatchEventImpl(Unknown Source)
 at java.awt.Component.dispatchEvent(Unknown Source)
 at java.awt.LightweightDispatcher.retargetMouseEvent(Unknown Source)
 at java.awt.LightweightDispatcher.processMouseEvent(Unknown Source)
 at java.awt.LightweightDispatcher.dispatchEvent(Unknown Source)
 at java.awt.Container.dispatchEventImpl(Unknown Source)
 at java.awt.Component.dispatchEvent(Unknown Source)
 at java.awt.EventQueue.dispatchEvent(Unknown Source)
 at java.awt.EventDispatchThread.pumpOneEventForFilters(Unknown Source)
 at java.awt.EventDispatchThread.pumpEventsForFilter(Unknown Source)
 at java.awt.EventDispatchThread.pumpEventsForHierarchy(Unknown Source)
 at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
 at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
 at java.awt.EventDispatchThread.run(Unknown Source)


#########################################################################
91  accessControl
#########################################################################

=========================================================================
91.1  Fixed
=========================================================================

*** 91.1:8076  The alarm notes dialog box always displayed when alarm was acknowleged. ***
  Record Type:  Bug
  Resolved In:  3.1.28
The Notes dialog box always displayed when the user initiated
an alarm acknowledgement. This behavior is now optional.

The "Alarm Indicator and Priority Setup" view now provides
an option check-box that allows Admin and Maintenance users to choose
whether or not to automatically display the Notes dialog box when 
an "Acknowledge" action is initiated. A change in the option 
status affects all users and takes place only after the option
status change is saved and the Alarm Console view page is refreshed.

*** 91.1:8606  Adding hardware offline allowed user to exceed maximum supportable modules. ***
  Record Type:  Bug
  Resolved In:  3.1.22
Adding hardware offline under the Network Setup view (Misc Config. link) 
was allowing a user to add more modules than could be physically supported.
The offline configuration has been changed so the user can only add one 
Security JACE, seven reader modules, and eight I/O modules.

*** 91.1:8692  Ability to UNEXPAND error messages ***
  Record Type:  Bug
  Resolved In:  3.1.25; 3.2.1
The user had the ability to select 'Show details' and expand details of an error
displayed in the browser. This was useful, but caused the browser window to become
crowded, with no way to then hide the error details.

This has been corrected and now the user can hide the details, as well as
show them.


*** 91.1:8702  Credentials do not export properly to Excel ***
  Record Type:  Bug
  Resolved In:  3.1.24
The credential was not exporting correctly into MicroSoft Excel.

It was found that when opening a CSV file (Comma Separated Values), Excel turns a number into scientific 
notation on import. This can happen with long credential numbers in the 'badge.csv'
file.

Solution:

1. Open a blank sheet in Excel.
2. Keep 'A1' highlighted so the data import is placed into the worksheet properly.
3. Select the Data Menu (Alt-D). 
4. Select 'export external Data->import text file'.
5. Find badge.csv, and click import.
6. This will bring up the Text Import Wizard
7. On step 1, just click next.
8. On step 2, uncheck tab as a delimiter and click comma
9. On step 3, Highlight the credential number column (or column that is giving you a problem).
10. Change the radio button under "Column data format" from "General" to "Text". Then click finish.
11. It should import properly now.

Once these changes are made, any future information will save properly in Excel. If zipped back up, the
import will work correctly. 

Alternatively, use some other program other than Excel, such as Notepad, which works fine for a small size file.


*** 91.1:8708  Badge activity was not being recorded correctly. ***
  Record Type:  Bug
  Resolved In:  3.1.26
Badge activity was not being recorded correctly in the database. This caused
an exception to display in the  associated station output view when the Access
History Report was viewed in the browser. Badge status data is now 
stored properly in the Badge Activity history and the error does not occur.

*** 91.1:8785  Cut and shorted wire (fault) alarms used delay time ***
  Record Type:  Bug
  Resolved In:  3.1.25
It was found that the fault conditions 'shorted' and 'cut' wires used the alarm 
delay time.  This is not desireable.  An additional alarm extension was added 
so that both fault conditions have separate alarm settings.

*** 91.1:8807  Assign Instructions from alarm setup produced long delay and no status ***
  Record Type:  Bug
  Resolved In:  3.1.25
If you went to Setup, Alarm, Instructions and then clicked on one of the links 
under 'Source Name', this produced an extremely long delay, with no status 
bar at the bottom of the browser.  After a minute, the 'Assign instructions' 
window would pop up.  If you clicked multiple times, thinking nothing was 
happening, the clicks would be cached and several windows would pop up as you 
closed others.  This was resolved in the release 3.1.23 patch.


*** 91.1:8827  Beta version of JAVA 1.6 browser plugin is not supported ***
  Record Type:  Bug
  Resolved In:  3.1.25
The Beta version of JAVA 1.6 browser plugin causes login and permissions
problems and genereates errors in the Station Dialog. 
This version of the Java plugin is not supported. Java 1.5.06 works properly.

*** 91.1:8844  Neptune DB loading slowly on station startup ***
  Record Type:  Bug
  Resolved In:  3.1.25
Security JACE was taking a long time to load Neptune DB on station startup. 
Changes to optimize database file access improved load time.

*** 91.1:8856  Supervised input fault condition did not generate an alarm. ***
  Record Type:  Bug
  Resolved In:  3.1.24
For Supervised Inputs, fault alarms were not being generated in response to fault conditions.
An alarm extension was added to all supervised inputs, so that they can now generate
an alarm on an fault condition.

*** 91.1:8862  Profile Switch/HomePage Switch ***
  Record Type:  Enhancement
  Resolved In:  3.1.25
When logging into the Vykon Security Application, a user's initial view
would be based on the previous session final view. Because of possible different
user profile privileges, this could cause an initial view to fail to display.

For example, if an admin user logged off the application while displaying the
"Edit Users" view, then immediately logged back in, the first view displayed
would be the "Edit Users" view. However, if the next user to log in from the
same workstation had only an operator-level profile, the initial view would 
not display and result in an error because the operator profile would not allow
that user to have access to the "Edit Users" view.

The application was changed so that the initial view for all user profiles is
the user's profile-specified home page.

*** 91.1:8869  PIN Timeout message not reporting to console ***
  Record Type:  Bug
  Resolved In:  3.1.25
For "Reader Plus Keypad" validation, after a valid badge swipe, failure to 
enter a required PIN within the specified Keypad Entry Time produced an
"Action Failed Pin time out error" in the Station Director. However, no alarm
was reported to the alarm console.

This issue is resolved in build 3.1.25 and the same action causes
"Access Denied - Invalid Pin" error to report to the alarm console.


*** 91.1:8884  Issues with deleting an assigned reader-schedule ***
  Record Type:  Bug
  Resolved In:  3.1.25
When an assigned schedule is deleted, no warning was given that the schedule
is assigned to a reader. The door that the schedule was assigned
to could be left in an unlocked state until a new schedule was assigned. 
After deleting a schedule, assigning and saving a new schedule caused an
error on the first "Save" attempt.

Users are now advised that deleting an assigned schedule affects the reader
configuration and readers now revert to an unlock schedule of 'None' when
assigned schedules are deleted. After deleting an assigned schedule, 
no error is displayed on subsequent configuration change save attempts.

*** 91.1:8898  Minimum Auto Logoff time was too small. ***
  Record Type:  Bug
  Resolved In:  3.1.26
Admin users could set an Auto Logoff that was so short that they could not get
back into the system long enough to increase that time. This resulted in the
admin user being locked out of the system. The minimum Auto Logoff time was changed 
to 5 minutes to allow enough time to log in and change the Auto Logoff time.

*** 91.1:8944  Deleting badges in Edit Existing Badges view caused errors. ***
  Record Type:  Bug
  Resolved In:  3.1.25
Deleting an assigned user badge from the Edit Existing Badge view caused errors 
in the station and browser. The Alarm Indicator polling could not work 
correctly with the changed page. The alarm event is now cancelled in the view
when a badge is deleted. No errors are generated.

*** 91.1:8971  History log defaults set and 2 new views added. ***
  Record Type:  Bug
  Resolved In:  3.1.26
All history logs were not set to an optimum default size and history management
features were needed. History logs are now set to a default size of 2000 records
and are configured, by default, to "rollover" when exceeding that size. 
A History Capacity view was added to allow the user to change the record sizes 
and log handling characteristics, as desired. A history log view was added that 
displays a table of log record data.

*** 91.1:8976  Entering certain non-alphanumeric characters caused view to not display. ***
  Record Type:  Bug
  Resolved In:  3.1.26
Using certain non-alphanumeric characters in data entry fields caused lack of 
access to the view. After entering these characters, the view could not reload
the data tables. Data handling was modified to allow display of data containing
these characters. Table views with this data now display correctly.

*** 91.1:9173  CheckBox on Personnel Tables for mass editing/deleting ***
  Record Type:  Enhancement
  Resolved In:  3.1.30
A batch editing feature is now available for certain properties in the
following table views:

 - PdfStyles (batch delete)

 - Badges (batch delete)

 - Access Rights(batchdelete)

 - Personnel (batch: delete, edit access rights, batch edit department, batch
edit person).

To batch edit, do the following:

1. In the desired table view, select "Advanced..." from the Search option list
and set Max Results to a number that includes all records in the table. The
advanced search features of the selected view display and all records display
(only display records are edited). Increase Max Results and click Search, if
necessary to display all records).

2. Click the checkbox in the column header to select all the records ON THE
PAGE (clear any that you don't want to edit). If you have no items checked, the
batch edit does not work.

3. Click the Batch Edit button. The Batch Edit dialog box displays.

4. Select the desired options in the Batch Edit dialog box and click the Ok
button. Edits are completed.

*** 91.1:9206  Cannot rename schedules or configured graphics from appliance ***
  Record Type:  Bug
  Resolved In:  3.1.30
Users may now rename schedules from the appliance if they have the
appropriate write access.

*** 91.1:9213  Required changes to history configuration screen ***
  Record Type:  Bug
  Resolved In:  3.1.30
In the History Configuration view, if you decrease the capacity value for any
of the displayed properties, it is possible to delete records. This view now
displays a warning if you are about to delete records. The following histories
are configurable: Audit History, Log History, Alarm Activity, Access History,
Attendance, Intrusion.

*** 91.1:9219  Time zone change in the appliance changes all badge records expiration dates. ***
  Record Type:  Bug
  Resolved In:  3.1.30
Changing the time zone caused a change in the badge Expiration Date property
option from "Never" to an actual date. Time zone changes no longer affect the
Expiration Date "Never" option. 

*** 91.1:9223  Users may not delete the only Wiegand Format ***
  Record Type:  Bug
  Resolved In:  3.1.30
There must always be at least one Wiegand format available in the Security
Applicance system (see the Wiegand Format Property in the Edit Existing Badge
view). Users may not delete the ONLY format or any Wiegand format that is
currently assigned to a badge.

*** 91.1:9227  Batch badge creation enhancements ***
  Record Type:  Bug
  Resolved In:  3.1.30
The following batch Badge Create enhancements are added:

- During Batch Create, a warning message indicates how many badges will be
created.

- During Batch Create, an alert is sent when Badge Create is complete.

- All Credentials will have the same amount of digits

*** 91.1:9258  Badge Status Alarms missing owner ***
  Record Type:  Bug
  Resolved In:  3.1.30
Badge Status Alarms "Lost" and "Disabled" are no longer missing the 
"owner" Alarm Data.

*** 91.1:9259  BACnet points are not created when a Reader module is added. ***
  Record Type:  Bug
  Resolved In:  3.1.30
The BACnet export table did not automatically create Reader Module Points when
a Reader Module was added to a Security Appliance system. This is now corrected
so that points are created when a module is added.

*** 91.1:9469  FanIn flag is now used for Object Linking ***
  Record Type:  Enhancement
  Resolved In:  3.1.29
Object linking in Access Control now uses the Fan-In flag when creating links instead
of using output priority to link multiple inputs to a single output. All inputs now 
use the same output priority (in10) instead of allowing users to choose priority levels.
This simplifies object linking in the security appliance and keeps users from
accidentally prioritizing an object link over a manual override.

Neptune Links created before 3.1.29.15 keep their original priority level setting.

*** 91.1:9727  Hx Auto-Logoff Error when time not Synchronized ***
  Record Type:  Bug
  Resolved In:  3.1.31; 3.2.11
Auto-Logoff in hx (for the security App) fails if the client is 24 days ahead
of the server in builds 3.1.23 through 3.1.30. The cookie would be set to an
expiration time that would automatically expire when received on the client.
The following workaround may be used:

1. Change the client System Time to be close to the server time.

2. Logon to the server and (for the desired user) in the Edit User dialog box,
set the "Autologoff Enabled" property to "false".

3. In the Security JACE, on the Misc Config view, set the correct time.

4. Reset the client System Time to the correct time and reset "Autologoff
Enabled" property to "true", if desired.

In NiagaraAX-3.x any time differential is supported.

=========================================================================
91.2  Open
=========================================================================

*** 91.2:9222  Import personnel data with comma in the CSV file ***
  Record Type:  Bug
  Resolved In:  3.1.30
Personnel Imports now have the ability to handle imports with 
comma's in the CSV files.

*** 91.2:10454  Upgrade causes graphical error ***
  Record Type:  Bug
  Resolved In:  
Browser cache should be cleared after an upgrade to ensure that the browser
is using the correct style sheets and javascript files.

#########################################################################
92  accessDriver
#########################################################################

=========================================================================
92.1  Fixed
=========================================================================

*** 92.1:8564  Remote I/O Module Outputs 5-8 were initialized with incorrect values ***
  Record Type:  Bug
  Resolved In:  3.1.21
When a new Remote I/O module was added to the network, relays 5-8 were initialized with
the incorrect fallback of NULL, instead of the correct value of "false". Initialization now sets all 
eight relays of a newly added Remote I/O module with a fallback value of 'false'.

*** 92.1:8602  All "Validation Required" options did not display in Mozilla Firefox browser ***
  Record Type:  Bug
  Resolved In:  3.1.22

The 'Badge only' option, under the "Reader Setup" view was not displayed in 
the Mozilla FireFox. 'Badge plus Keypad' and 'Badge or Keypad' were the only
options displayed. Microsoft IE displayed all three options correctly.
This has been corrected so that all options display in both browsers.

*** 92.1:8604  Security JACE DI3 proxy extension was not being initialized correctly. ***
  Record Type:  Bug
  Resolved In:  3.1.22
On the Security JACE, DI3 proxy extension was not being initialized correctly. 
This resulted in incorrect default property values for DI3, as well as an 
absence of proxy and alarm extensions with no alarm generation while a fault 
status was indicated. The proxy extension for DI3 was changed so that it initializes
correctly and displays the correct properties.

*** 92.1:8614  Unnecessary "alarm cleared" messages reported from points with stale alarm values ***
  Record Type:  Bug
  Resolved In:  3.1.25; 3.2.1
Point alarm extensions were being processed, even though the alarm
value was stale. The alarm extension is no longer processed for alarms 
if the value of the point is stale.

*** 92.1:8711  AccessDeviceManager Match function requires an additional discovery for device to come online. ***
  Record Type:  Bug
  Resolved In:  3.1.23
The AccessDeviceManager Match function was requiring an additional Discover
to make a device come online. The AccessDeviceManager was modified to 
automatically do a discovery after a match.

*** 92.1:8752  Wink function added to Device Manager. ***
  Record Type:  Enhancement
  Resolved In:  3.1.24
The AccessNetwork's DeviceManager view was modified to provide the ability to
"wink" and identify a security module before it is added to the station.

*** 92.1:8753  Cutting security device from station may cause "not running" exceptions. ***
  Record Type:  Bug
  Resolved In:  3.1.24
Deleting a remoteReader or remoteInputOutput device from the station running 
AccessDriver versions prior to 3.1.24 may cause "not running" exceptions to be 
thrown and printed in the station output.

*** 92.1:8851  Surge voltage test produces many "Unknown Wiegand Format" alarms ***
  Record Type:  Bug
  Resolved In:  3.1.25
During surge voltage testing, the appliance reported a large amount of 
"Unknown Wiegand format" alarms and recorded data for the unknown 
Wiegand format data. 

The Appliance was modified so that the user has the option to either ignore or
or report any unknown Wiegand Format. This option is set in the Network Setup 
view, accessible from the Misc Config link in the navigation tree.
This option allows hiding all traces of unknown Wiegand format for UL testing
or other reasons.

*** 92.1:8861  Supervised Digital Inputs were not creating Alarms on fault detection ***
  Record Type:  Bug
  Resolved In:  3.1.24
Supervised Digital Inputs were not creating Alarms on fault detection.
Alarm extensions were added to detect and generate fault alarms, as needed.

*** 92.1:8868  Disabeling a Reader does not disable reader I/O points ***
  Record Type:  Bug
  Resolved In:  3.1.25
If a user disabled a reader, the application did not disable the associated 
door I/O. Alarm traffic from the associated door I/O was reporting to the alarm
console even if the parent reader was disabled.

The application was modified so that when a reader is disabled the associated I/O
inherits the "disabled" status from the parent reader.

*** 92.1:9210  Entry / Exit Reader Pair activates 2 relays on access grant ***
  Record Type:  Bug
  Resolved In:  3.1.30
Entry Exit pairing was firing multiple alarms and multiple audit histories
for the same door. Now the alarming and audit histories have been refined to
only report once on each action when in this mode.

*** 92.1:9231  Remove digital input enable actions from Security JACE and Reader Module on Network Discovery view ***
  Record Type:  Bug
  Resolved In:  3.1.30
Tamper, Battery Status, and Primary Power enabling actions have been removed.
These inputs are now general purpose inputs, and special actions to 
enable or disable these inputs are no longer required.

*** 92.1:9264  Remove default Battery, Tamper Power Status configuration ***
  Record Type:  Enhancement
  Resolved In:  3.1.30
Tamper, Battery Status, and Primary power status inputs are now, by default,
general purpose inputs. You may still configure and use any of these inputs to
monitor the status of: Tamper, Battery, and Primary Power, if desired.

See http://www.niagara-central.com for the latest release notes.