Echelon LNS - Manual (Page 35)

LNS Programmer's Guide 21
Common exception codes for particular methods can and should be handled specially to
provide more guidance to your particular end-user. However, because the complete set of
exception codes that can be thrown for a given method can be large, and because all
exception codes must be handled by your application, you should also use a generic error
handler in your application that will handle all errors returned by LNS.
New Features
When adding new features to LNS, Echelon must make compatibility tradeoffs in order
to improve functionality and performance. Some of the new features described earlier in
this chapter may introduce compatibility issues into your application, so you should
consider the following information carefully when integrating these new features.
Propagating Device Changes While Offnet
The commission and replace operations behave identically in LNS Turbo Edition as in
prior versions of LNS, unless the new “propagate” flags provided with the
ReplaceEx()
and
CommissionEx()
methods are specified by the LNS application.
The new
AllowPropagateModeDuringRemoteOpen
property is simply an alias for the
RemoteIgnorePendingUpdate
property. The
RemoteIgnorePendingUpdate
property
is marked as hidden, but reading and writing the property is still supported by LNS
Turbo Edition.
Opening a remote Full client application with LNS Turbo Edition may succeed while the
system management mode is set
lcaMgmtModeDeferConfigUpdates
, even if there are
pending updates for other devices, and the
RemoteIgnorePendingUpdate
flag is
False
. The Network Service Device will be re-commissioned in this case. In prior
versions of LNS, the open would fail, and return an error.
Opening a remote Full client application with LNS Turbo Edition while the system
management mode is set to
lcaMgmtModeDeferConfigUpdates
, and the
AllowPropagateModeDuringRemoteOpen
property is set to
True,
may result in
commissioning the remote Network Service Device without propagating pending updates
to other devices. In prior versions of LNS, this would always result in propagating all
pending changes.
Dynamic Functional Blocks
Your application might currently assume that it will find all defined
LonMarkObject
objects for a device by accessing the
DeviceTemplate
object’s interface. However, the
dynamic
LonMarkObject
objects on a device do not appear in the interface of the
device’s
DeviceTemplate
object. Another possible problem is if your application
assumes that the collection index assigned to a LonMarkObject is one greater than the
value of the LonMarkObject object’s Index property. This relationship happens to hold
for static LonMarkObject objects, but may not for dynamic LonMarkObject objects.
DataPoint Object Improvements
The
DataPoint
object was introduced in LNS 3.0 to allow convenient access to the data
contained in monitor points. The feature allowing access to individual
DataPoint
fields
contained several defects that may not allow a current implementation of the feature to