Echelon LNS - Manual (Page 200)

LNS Programmer's Guide 186
the Index, Length, and ObjectType properties of the TypeSpec object.
If LNS is unable to find the resource file for the program ID entered in
step 2, the LCA#154 lcaErrUnavailableResourceFiles exception
will be thrown. If LNS finds the resource file but is unable to find the
type name referenced in step 2, the LCA#155
lcaErrNotFoundInResourceFiles exception will be thrown. Be sure
that the network variable can support the new type before assigning it. If
the length of the new type is too long for the network variable, then the
LCA#156 lcaErrTypeLengthTooLong exception will be thrown.
SCPTnvType Configuration Properties
If the ChangeableTypeSupport property is set to lcaNvChangeableTypeSCPT, then
the network variable supports changeable types via a SCPTnvType configuration
property. This is the recommended LonMark-compliant way to implement changeable
type network variables on a L
ON
W
ORKS
device. If this method is supported, LNS will
automatically update the value of the SCPTnvType configuration property when the
network variable’s
TypeSpec
property is changed. If the single SCPTnvType
configuration property is declared for multiple network variables, changing the type of
one of those network variables changes the type of all of them.
However, the device can refuse the desired type. For instance, a device could implement
a generic PID controller that supports a wide range of numeric data types (float, signed
long, etc) for the process value, setpoint, and control value network variables. Changing
these network variables to a non-numeric type such as a string (e.g. SNVT_asc_string)
may not be meaningful in the context of the application. The device will report this error
condition using its NodeObject LonMark functional block, and will not change the
network variable type.
This presents a problem when configuring a device in engineered mode. When you
change network variable types in the definition phase while the application is not
attached to the network, and then create network variable connections based on the
desired, new, network variable type, these connections may malfunction if one of the
participating devices rejects a type change request once it has been set online. Echelon
recommends that integrators only use device-specific plug-in software to change network
variable types, as such software has built-in knowledge of the network variable types
that a given device supports. In turn, you should design your LNS application so that it
does not support changing network variable types to any arbitrary type, at least not
without warning the user of these implications.
You must also be aware that changing the type of a single network variable can have a
snowball effect. Some devices are designed to implement multiple network variables of
changeable type, but with the restriction that some or all of these network variables
must have the same type. For instance, the aforementioned generic PID controller could
be implemented to support a wide range of numeric network variable types, but could
require that setpoint, control and process value network variables always use the same
network variable type. Unfortunately, LNS has no method to determine if such a
relationship exists. Consequently, changing one network variable may leave the related
network variables with the inappropriate type and format selection. However, the device
manufacturer can ensure that a set of network variables always have the same type by
using a single SCPTnvType for all of them.
Likewise, a configuration property of an inheriting type could apply to a changeable type
network variable. Configuration properties of inheriting types derive their type from the