LNS®
Server/Turbo Edition Service Pack 2 ReadMe
June 2006
Copyright
© 2006 Echelon Corporation
All Rights Reserved
This update (Service Pack 2) fixes customer-reported problems with installations of LNS Server/Turbo Edition (LNS 3.2) and LNS Server/Turbo Edition Service Pack 1 (LNS 3.21), and may be applied to either of those installations. It may also be applied to LNS Server/Turbo Edition Service Pack 1 with Update 1.
NOTE: LNS Turbo Edition is synonymous with LNS 3.2. The terms LNS Turbo Edition and LNS 3.2 refer to the major LNS release generically (not specifying a specific service pack level for this major release). To be precise about a service pack level, one would refer to the initial LNS Turbo Edition release as LNS 3.20. After Service Pack 1 is applied, you would refer to it as LNS Turbo Edition Service Pack 1 or LNS 3.21. After this update is applied, you would refer to it as LNS Turbo Edition Service Pack 2 or LNS 3.22.
Additional information and updates, including critical updates, may be available at www.echelon.com/downloads.
NOTE: During installation of the service pack, you may be prompted to insert the original LNS installation media. This will be the installation CD for the LNS based product that you installed. The file name for the LNS Server installation on that CD is “Echelon LNS Server.msi” (with spaces between “Echelon”, “LNS” and “Server”), and may be located on the CD using the standard Windows file search mechanism.
4 Silent LNS Runtime Installations
5 Problems Fixed in LNS 3.22 (Turbo Edition Service Pack 2)
5.1 Compatibility issues between LNS 3.08 and LNS Turbo
5.2 Two multiple-client deadlock issues fixed
5.5 Error Installing LNS Server Turbo SP1 runtime over LNS Server Turbo runtime
5.6 LNS Turbo overwrites LonMark Resource File versions greater than 12.00
5.7 VNI Server process crashes
5.8 LNS Turbo German string resource problems
5.9 Failures when using Authentication
5.10 DeviceTemplate.ResynchToResources() causes loss of TypeName and FormatName info
5.13 Moving device to another channel does not work on a Remote Client
5.14 LNS Turbo does not support system image upgrade to version 16 firmware
5.15 DB Recovery Wizard updated to support sub-system recovery according to LonMark 3.4 Guidelines
5.16 Networks.RemoveEx() did not work as documented
5.17 The Network.Handle value may be duplicated on a PC
5.18 New Interface.AllowDuplicateNvNames() property
5.19 New LNS Turbo Database Upgrade Event
5.20 Microsoft Visual C++ Runtime Library “pure virtual function call” error
6 Problems Fixed in LNS 3.21 Update 1 (Turbo Edition Service Pack 1, Update 1)
6.1 Network variable type conflicts between XIF and FPT cause unexpected type changes
6.2 Possible deadlock when multiple processes access the same LNS database object at the same time
6.3 Setting CP format to “RAW_HEX” causes LCA OLE Error and crash
6.5 Possible memory leak when removing Temporary Monitor Sets
7 Problems Fixed in LNS 3.21 (Turbo Edition Service Pack 1)
7.1 LNS Network Recovery didn’t change SCPTnwrkCnfg to reflect management by LNS
7.2 Shutting down an LNS-based app may show dialog “Microsoft Visual C++ Runtime Library Error”
7.4 System.Connections property access became much slower in LNS Turbo Edition
7.5 Data Server #374 exception when accessing a network variable DataPoint object
7.6 Memory leaks in NetworkVariable.GetDataPoint() and DataPoint.GetRawValue()
7.8 Cannot replace a device with changeable types and no SNVT SI Data
7.9 LNS DDE Server 2.11 fails to send application messages – Data Server #44 Exception
7.10 Discovered devices with static interfaces sometimes fail DB validation
7.12 AppDevice.Upgrade() method does not upgrade network variable arrays properly
7.13 Network database open fails with NS #6 exception
8 Problems Fixed in LNS 3.20 (Turbo Edition)
8.1 LNS application misses network variable bound updates received via single point monitoring
8.2 VNIServer process crash using L5 MIP
8.3 Memory leak opening and closing monitor sets
8.4 LCA OLE error when creating subsystems in a loop
8.5 Single point monitoring cannot create implicit network variable connections on LNS 3.07 or 3.08
8.9 GetElementFromDevice method can only read the first array element properly
8.10 Commission() method causes "NS#5030" error message
8.11 LNS Network Interfaces don’t use standard LonMark Program IDs
8.12 DS #34 error when trying to write to an unconnected host network variable
8.13 The Inherited property of a CP is not exposed
9 Known Problems and Workarounds
9.3 Windows XP SP2 port blocking issues
9.4 LNS Server installer fails on unsupported versions of Windows
9.6 LNS events are not received by Full clients that are hard offline
9.7 UDP ports used by the LNS Server application
9.8 LonMaker Integration Tool can't launch the LNS Server application
9.9 Replacing an NSD that is in use
9.10 Moving Remote Full clients
9.11 LNS DB -2524 error reported if TCP/IP Networking not installed
9.12 LNS 112 errors when monitoring from a remote lightweight client
9.13 LNS Server logging recommendation
9.14 Miscellaneous unclear error messages
9.16 Ordering LNS Device Credits
9.17 i.LON 600 Internet Server Configuration Server and LNS on the same PC
9.18 Closing Remote Full clients when the LNS Server is not available
9.19 LonMark File Transfer Protocol support
9.20 System.GetServiceStatus() on LNS Lightweight clients
9.21 NvMonitorPoint.Tag property must be set before NvMonitorSet.Open()
9.22 Recovery CD mechanism from Dell causes LNS license failure
9.23 LNS is not compatible with Norman (not Norton) anti-virus software
9.24 LonWorks Bundle Deployment Kit (OSGi) software does not work with LNS Turbo Edition
9.25 Extension.GetValueX() methods don’t properly range check input data size
9.27 Installing LNS 3 over LNS Turbo Edition downgrades the “LonWorks Interfaces” Control Panel item
9.29 OnNetworkServiceDeviceResetNew Event does not work on a Full client in some cases
9.30 Subnets.Remove(index) does not work
9.31 NS #176 exception when re-opening an authenticated network from a Full client
9.32 Installing this product uninstalls any existing LNS Application Developer’s Kit installation
9.33 Restoring a backup database may put Full clients out of synch with the LNS Server
9.35 Borland Delphi imports ObjectServer.CurrentFormatLocale as a protected member
9.37 Application load interrupted by device reset during load results in NS #36 and failed load
9.38 LNS Remote client recommendation
9.39 LonMaker Function Block shapes and Auto Scope Determination
9.40 Problem with event timing on multiple remote clients with transactioning
9.42 NetworkVariable.DsIsDefaultFormat property does not work as documented
9.43 DeviceTemplate.SelfDocConsistency property problems
Echelon recommends that you install the LNS runtime as a visible installer. Since the LNS runtime installation is time-consuming, installing visibly provides progress cues for the end user. If your overall product distribution strategy requires you to install LNS silently, there is an additional step that you must take if you are installing LNS version 3.22 or higher.
This LNS software product is installed using Microsoft Windows Installer technology. As of LNS 3.22, the LNS runtime redistribution installers – the Echelon LNS Server and Echelon Remote Client – contain embedded installations to install required components of the LNS runtime. These components are Echelon OpenLDV 3.3 and LonMark Resource Files 13.00. If you install the LNS runtime silently, because of Windows Installer concurrent installation rules, these embedded installations will not be run. For silent installations, you will have to separately include these embedded installers within your installer, after the LNS runtime installation is complete. These installations may be found on the Echelon and LonMark International (http://www.lonmark.org) web-sites, respectively. If you are licensed to redistribute the LNS runtime with your application, you are licensed to redistribute these runtimes as well.
The following problems are fixed in LNS Turbo Edition Service Pack 2, which is an update to the LNS Turbo redistribution. This update may be applied to directly to LNS Server 3.20 and LNS Server 3.21 redistributions. Numbers in parentheses at the end of the problem descriptions are Echelon's internal problem tracking IDs.
Several compatibility problems were fixed, where LNS Turbo behaved differently than LNS 3.08. The fixed incompatibilities include:
One incompatibility between LNS 3.08 and LNS Turbo behavior was discovered that cannot be fixed. In LNS 3.08, it appeared that LonMarkObjects.Item(Name) and NetworkVariables.Item(Name) would search through the list of object names first, and then through the list of object programmatic names. In fact, this unexpected behavior only occurred in some cases, and caused a database inconsistency when it did occur. The Item(Name) properties were always meant to take the object name as their argument. To search these object sets by programmatic name, call the LNS Turbo methods LonMarkObjects.ItemByProgrammaticName() and NetworkVariables.ItemByProgrammaticName(). (39407)
Two problems were found in which multiple clients accessing the LNS database simultaneously became deadlocked. (38690, 39413)
These problems are fixed in LNS 3.22.
LNS failed to set the default value of a Configuration Property successfully in some cases where the CP had a length greater than 255 bytes. (38984)
This problem is fixed in LNS 3.22.
LNS Full Clients failed to read and write Configuration Property values with a length of over 140 bytes. (35940)
This problem is fixed in LNS 3.22.
When installing the LNS Turbo SP1 runtime over LNS Turbo, the installer would sometimes display the message “Please insert the disk: 1”, and fail to install. The workaround was to uninstall the existing LNS release before installing the new LNS release. (40508)
This problem is fixed in LNS 3.22.
If you had installed LonMark Resource files version 12.11 or 13.00 on your PC, then installed LNS Turbo, the newer LonMark Resource Files would be overwritten by version 12.00 files. (39269)
This problem has been fixed in LNS 3.22.
Note that if you install LNS silently, but do not include the “LonMark Resource Files 13.00” installer within your product installer, you will still see this problem. See the section “Silent LNS Runtime Installations” in this document for details.
Two cases of the LNS VNI Server process crashing have been fixed in LNS 3.22. (39403, 39750)
In configurations where LNS Turbo was installed over the Echelon LonMaker 3.13 German product, and the LNS Server Application was launched, it would display the message “An unsupported operation was attempted” and then crash with an access violation. (39671)
This problem has been fixed in LNS 3.22.
When testing an authenticated router that had been successfully commissioned, LNS would return the misleading error “key mismatch”, even though the router was working properly.
When commissioning an application device while authentication was enabled, LNS would not properly update the authentication key. (39726, 39824)
These problems are both fixed in LNS 3.22.
When the DeviceTemplate.ResynchToResources() method was called on a DeviceTemplate containing a network variable that was defined in an associated Functional Profile Template as SNVT_xxx, that network variable would lose knowledge of its type and format. (40417)
This problem has been fixed in LNS 3.22.
If an AppDevice.Load() was called immediately after AppDevice.Replace() or AppDevice.Upgrade, an NS #51 error would occur and the load would fail. (39421, 38224)
This problem has been fixed in LNS 3.22.
Sub-system renaming did not always generate an event on remote clients.
AppDevice.ResynchToTemplate() did not generate events for database changes induced by the resynchronization.
Renaming a ConfigurationProperty object should generate an event, just as renaming a LonMarkObject or NetworkVariable object does. (38203, 36034, 38388)
These events have been fixed or added in LNS 3.22.
Calling the AppDevice.MoveEx() method to move a device to another channel was silently failing on remote clients. (38199)
This has been fixed in LNS 3.22.
The AppDevice.LoadEx() method allows you to optionally upgrade a device’s system image, if the system image resides in writable memory. This function did not work for Neuron firmware version 16 system images, but has been fixed in LNS 3.22. (39356)
The LonMark 3.4 Interoperability Guidelines specify the use of the SCPTlocation configuration property to specify the sub-system name during network recovery. The LNS Network Recovery Wizard has been updated to support the new LonMark Guidelines. (40146)
The Networks.RemoveEx() method did not allow the use of option flags as specified in the LNS ADK online help, and would sometimes erroneously throw an out of range error. (40158)
This problem has been fixed in LNS 3.22.
The Network.Handle() property of a network is supposed to be unique within an LNS Server PC. However, it was easy to generate duplicate network handles by copying an LNS network database from one PC to another or restoring from a backup.
The Network.Handle() generation has been modified in LNS 3.22 to make uniqueness far more likely and to regenerate the handle when a database is moved from one PC to another or restored from a backup. (40505)
LNS supports two types of Interface objects – the main AppDevice.Interface object, and the custom Interface objects within the AppDevice.Interfaces collection. The custom Interface objects are only allowed on AppDevices that support dynamic NetworkVariable and/or LonMarkObject objects. The main AppDevice.Interface object contains the static interface of the device, but it also contains any objects that are added on the dynamic custom interfaces of the device.
These two types of Interface objects have different rules for NetworkVariable object names within the interface. The main Interface object does not require unique NV names. The custom Interface objects require unique NV names within each interface, and throw an LCA #132 (lcaErrUniqueNvNameRequired) exception if the user attempts to add an NV with a duplicate name.
With the dynamic LonMarkObject feature added in LNS Turbo, it became possible for an AppDevice.Upgrade to transform an AppDevice interface from static to dynamic, moving objects from the main interface to a custom interface. Since this transformation would result in more-strict NV naming rules, the conflict between main and custom interface rules had to be resolved.
To allow custom Interface objects to loosen the NV naming rules to be the same as the rules for the main Interface object, a new Interface.AllowDuplicateNvNames() property has been added in LNS 3.22. This property will always be TRUE on the main AppDevice.Interface object, and may not be modified on that interface. By default, it will be FALSE on custom Interface objects, but may be modified. If a custom Interface object is created by upgrading an AppDevice interface from static to dynamic, this property will be set to TRUE on the created dynamic Interface object.
The new property allows the maximum compatibility possible for LNS-based applications that depend on LNS to ensure NV name uniqueness on dynamic Interface objects. However, those applications should be modified to examine the new property in order to handle this new behavior. (35192)
A new LNS event type has been added to signal progress during a time-consuming database upgrade (for instance, from LNS 3.08 format to LNS Turbo format). (34162)
The LNS ADK online documentation should be amended with the following Event entry:
Applies to: ObjectServer object
Summary: This is an event thrown to deliver progress information to a client
application during a database upgrade procedure. A database upgrade is initiated when calling Open on a network object that needs to be upgraded. Additionally, calling the CompactDB method can throw this same event.
Syntax: OnDbUpgradeEvent(totalPercentage as Long,
thisPhasePercentage as Long, thisPhaseNumber as Long, totalPhases as Long, thisPhaseName as String, thisStepName as String)
Element Description
totalPercentage The percentage of the database upgrade that
has been completed. This element has a range of 0-100.
thisPhasePercentage The percentage of the current phase of the
database upgrade that has been completed. You can use the thisPhaseName element to determine which phase of the database upgrade is currently being performed. This element has a range of 0-100.
thisPhaseNumber The number of the current phase. This
element has a range of 0-2,147,483,647.
totalPhases The total number of phases to be performed
during the database upgrade. This element has a range of 0-2,147,483,647.
thisPhaseName The name of the phase of the database
upgrade that is currently being performed. The phase name will be returned as a string of up to 128 characters.
thisStepName The step that is currently being performed.
The step name will be returned as a string of up to 128 characters. Generally, this will be the name of the object in the database that is currently being upgraded.
Added to LNS: Release 3.22
Remarks: Depending on the size of a network database, a database upgrade
can take a considerable amount of time to complete. You can use the information returned by this event to develop an idea of how long the database upgrade being performed will take. This event will be fired many times throughout the database upgrade, including each time the upgrade progresses to a new phase, and each time the upgrade progresses to a new step within that phase.
The number of phases, and the names of the steps and phases, involved in a database upgrade may differ from datatabase to database, and from release to release. You can use them to display a progress bar with your application, but you should not expect this event to return for the same number of phases or steps each time you perform a database upgrade.
An object reference count inconsistency was created when retrieving an Interface object pointer from a call to NetworkVariable.ParentInterface. This inconsistency could have resulted in prematurely releasing the interface object at a later time, resulting in a “pure virtual function call” error in the Microsoft Visual C++ Runtime Library. (41699)
This problem has been fixed in LNS 3.22.
The following problems are fixed in LNS Turbo Edition Service Pack 1 Update 1, which is an update to the LNS Server 3.21 redistribution. This update is to be applied to the LNS Server 3.21 redistribution only. Numbers in parentheses at the end of the problem descriptions are Echelon's internal problem tracking IDs.
If a LonMark device developer declares a network variable as a Standard Network Variable Type (SNVT) in the device’s external interface file (XIF), and incorrectly declares that same network variable as another type in the device’s LonMark resource file functional profile template (FPT), LNS sometimes changes the network variable type in the LNS database to what is incorrectly defined in the FPT. This will result in incorrect data formatting for the affected network variable.
This behavior, new in LNS Turbo Edition with or without Service Pack 1, is eliminated after Service Pack 1 Update 1 has been installed.
Note that this problem will only be encountered if the device’s XIF file is inconsistent with the device’s FPT in the resource files. Device manufacturers must fix their resource files in order to fix other problems associated with inconsistencies. One problem that can be introduced by invalid resource files is invalid User Network Variable Type (UNVT) assignment. UNVTs cannot get type information from the XIF and are completely dependent on type information from resource file FPT declarations. Additionally, LNS Turbo Edition and later releases apply data value range overrides specified in the resource files, thus inconsistent resource files may again prevent network variables or configuration properties from being written correctly. LNS Turbo Edition includes significant enhancements for LonMark standard formatting, and thus is much more dependent upon the validity of the device’s LonMark resource files.
After applying Service Pack 1 Update 1, LNS will be more tolerant of incorrectly specified network variable types in the device’s resource files. However, if an LNS database was upgraded to LNS Turbo Edition from an earlier LNS version (such as LNS 3), the database could still have the inconsistency even if Service Pack 1 Update 1 has been installed. For this case, after installing Service Pack 1 Update 1 the AppDevice objects may be restored to a consistent state by calling the DeviceTemplate.ResynchToResources() method with the option flag lcaResyncToResourcesOptionUpdateDevices set as well as an undocumented option flag (with hex value 0x80000000) set. The undocumented option flag will cause information to be re-imported from the XIF file as well as regenerating the XFO file derived from the XIF, which will cause the resynch process to take longer. (38157)
If two or more separate LNS clients attempt to access the same LNS database object at the same time, a deadlock could occur. (36467)
This problem is fixed by Service Pack 1 Update 1.
For certain long ConfigurationProperty values, if you created a DataPoint for the ConfigurationProperty, and set its format name to “RAW_HEX”, an LCA Error and crash would follow any attempt to write data to the ConfigurationProperty. (38116)
This problem is fixed by Service Pack 1 Update 1.
The LonMaker 3.1 Browser, when running on LNS Turbo Edition, will not access CP array data longer than 127 bytes. Beyond the 127th byte, the data is shown as all zeroes, and is not written to the device properly if the user chooses to write the data. (36603)
This problem is fixed by Service Pack 1 Update 1.
The Temporary Monitor Set object was introduced in LNS Turbo Edition, and is created by the Network.CreateTemporaryMonitorSet() method. If MonitorPoints objects created in this way are removed without ever enabling the point, a memory leak could occur. (38139)
This problem is fixed by Service Pack 1 Update 1.
The following problems are fixed in LNS 3.21, which is a patch to the LNS Turbo Redistribution Kit (RDK). After the patch is used to modify the RDK, the new LNS redistributables created by the RDK will be the newer LNS 3.21 version. Numbers in parentheses at the end of the problem descriptions are Echelon's internal problem tracking IDs.
The LonMark standard configuration property SCPTnwrkCnfg tells whether a device is self-installed or managed by an external network manager. In order to make a smooth transition, through the LNS network recovery feature, from a self-installed network to an LNS-managed network, this CP should be set to the value CFG_EXTERNAL during the network recovery process. (37347)
This CP value change is now performed in LNS 3.21.
On certain rare system configurations, shutting down an LNS-based application may display the dialog “Microsoft Visual C++ Runtime Library Error”. (36499)
This problem is fixed in LNS 3.21.
When installing the LNS Turbo redistribution over a previous version of LNS, one dialog (explaining that the old LNS version will be uninstalled first) is displayed even when the installation is run in silent mode. (36672)
This problem is fixed in LNS 3.21.
Access to the System.Connections property became much slower between LNS 3.08 and LNS Turbo. (36923)
This problem is fixed in LNS 3.21. While this property will be time-consuming in systems with many connections, the performance regression in LNS Turbo has been fixed.
If you open a Network and its associated System object, then obtain a DataPoint object via the NetworkVariable.GetDataPoint() method, data values for the DataPoint object are freely accessible. However, if you then close and re-open the Network and System objects without also closing the ObjectServer, DataPoint objects obtained within the network will fail with a Data Server #374 exception. (36646)
This problem is fixed in LNS 3.21.
A small amount of memory would be lost to the LNS-based app process when calling both NetworkVariable.GetDataPoint() and DataPoint.GetRawValue(). (36103)
This problem is fixed in LNS 3.21.
The method DeviceTemplate.ResyncToResources() fails with an NS #51 exception when called for a device containing changeable-type network variables. (35610)
This problem is fixed in LNS 3.21.
LNS can not replace devices with changeable types and no SNVT Self-Identification Data if configuration properties are to be uploaded from the device. (36991)
This problem is fixed in LNS 3.21.
After upgrading an LNS DDE Server 2.11 installation from LNS 3.08 to LNS Turbo, attempts to send application messages through the DDE Server fail with the exception "The format type referenced does not exist (subsystem: DS, #44)". (35997)
This problem is fixed in LNS 3.21.
Devices with static interfaces that are brought into the network through the device discovery mechanism sometimes erroneously fail database validation. (36180)
This problem is fixed in LNS 3.21.
Writing to the NetworkVariable.Value property of a disconnected device using acknowledged service should fail with a Data Server #200 exception, but it was returning success in some cases. (37064)
This problem was fixed in LNS 3.21.
The AppDevice.Upgrade() method does not recognize network variable arrays as the same when upgrading from one device version to another. (36403)
This problem was fixed in LNS 3.21.
Occasionally, a network database would become corrupted in a way that caused the database open to always fail with an NS #6 exception. (37037)
This problem was fixed in LNS 3.21.
MsgMonitorPoint objects created in LNS 3.08 or earlier may lose some of their setting information or cause an LNS #112 exception when accessed in LNS Turbo. (37292)
This problem was fixed in LNS 3.21.
There are thousands of changes and improvements in LNS Turbo Edition. The following list is a select group of notable fixed problems. See the LNS Programmer’s Guide for a list of key new features in LNS Turbo Edition. Numbers in parentheses at the end of the problem descriptions are Echelon's internal problem tracking IDs.
An LNS application that uses single point monitoring to monitor bound input network variables may occasionally fail to deliver the network variable update to the LNS application, if that update occurs near the time that other network variable points are disabled or enabled using single point monitoring. (28713)
This problem is fixed in LNS Turbo Edition.
Under certain rare circumstances when using a L5 MIP, the VNIServer process (VNIServer.exe) could crash. (23526)
This problem is fixed in LNS Turbo Edition.
Approximately 2100 bytes of memory were leaked every time that a monitor set was opened. LNS applications that opened monitor sets many thousands of times per execution session were affected by this leak. (25946)
This problem is fixed in LNS Turbo Edition.
An LCA OLE error could occur when creating many Subsystem objects in a loop. (28316)
This problem is fixed in LNS Turbo Edition.
In certain instances, LNS would poll a network variable even though the LNS application had requested that an implicit connection be created to get event-driven updates. Note that this problem did not occur when using monitor point monitoring (the preferred monitoring method that was introduced in LNS 3). For definitions and explanations of the terms “single point monitoring” and “monitor point monitoring”, see the LNS Programmer's Guide (078-0177-01), which is available from http://www.echelon.com/support/documentation/Manuals/.
Because this problem occurred only under a specific set of conditions, the conditions will be described below as a set of If/Then statements. Note that all of the If statements must be true in order for the problem to occur:
If an LNS application employed the single point monitoring
technique in order to monitor an output network variable on a LonWorks® device,
- and -
If the DsUseBoundUpdates property of the NetworkVariable object to be monitored
was set to True,
- and -
If a network variable connection did not pre-exist between the output network
variable on the LonWorks device and the LNS host where the LNS application was
running,
- and -
If this was not the first implicit network variable connection to be created on
the LNS host where the LNS application was running
Then LNS would fail to create the required network variable connection that was needed to receive event-driven updates, and thus would poll the network variable.
The request to create an implicit network variable connection is designed to fail silently, and to revert to polling. When an LNS application ran on LNS 3.07 or 3.08, the implicit network variable connection would fail every time except for the first time. This silent failure to implicitly create network variable connections may not have been noticed until the number of network variables that were polled grew to the point of LonWorks channel saturation. LonWorks channel saturation could occur much more quickly when using an LNS High Performance Network Interface, such as the PCC-10, PCLTA-10, PCLTA-20, PCLTA-21, i.LON 600 Internet Server or i.LON 1000 Internet Server.
Note that this problem was not a general problem with the LNS component that created network variable connections between devices or between devices and the LNS host(s).
Note that this problem did not affect an LNS application that explicitly created the network variable connections into the LNS host, in the instances where single point monitoring was being employed.
Note also that this problem did not affect an LNS application that was using monitor point monitoring, even if the LNS application requested LNS to implicitly create a network variable connection for the monitor point. (28336)
This problem is fixed in LNS Turbo Edition.
When using the GetField() method on the DataPoint object of a network variable monitor point, incorrect values would be returned if the network variable consisted of structures or unions. (19507, 28830)
This problem has been fixed in LNS Turbo Edition.
Invoking the SetElement method on large ConfigProperty objects (larger than 2K bytes) would cause an access violation. (28953)
This problem has been fixed in LNS Turbo Edition.
For LNS applications that opened two or more LNS networks that were attached to network interfaces, during the time that LNS was opening, closing, or reconnecting to a network interface, communication with all other LNS networks was blocked. The LNS applications most affected by this problem were service center monitoring applications that connected to i.LON 10 Ethernet Adapters or i.LON 100 Internet Servers through intermittent Internet connections. In this case, LNS and the i.LONs would automatically attempt to re-connect to one another, transparently to the LNS application. However, during this reconnect process, all communication with other LNS networks was blocked.
This problem has been fixed in LNS Turbo Edition. Note that you must be running the latest available firmware revision in any i.LON 10 Ethernet Adapter or i.LON 100 Internet Server products that you have, in order for all of the connection and reconnection features to work properly with LNS Turbo Edition. If you have a version 1.x i.LON 10 or version 1.0 i.LON 100, you will need to purchase a firmware upgrade. Contact your Echelon salesperson or distributor for details. (29019)
When using GetElementFromDevice (index) to read the first element of the array (index 0), it works fine for that first element, but not for the rest of the array. (31870)
This problem has been fixed in LNS Turbo Edition.
Warning messages in the NS#40xx range were sometimes incorrectly reported as warnings in the NS#50xx range, which had no associated error strings. (15736)
This problem has been fixed in LNS Turbo Edition.
LNS Turbo Edition uses LonMark standard program IDs for its network interfaces (19406). The IDs used are:
9000010103800000 - LNS Turbo Edition Layer 2 MIP
9000010103800001, 9000010103800002 - LNS Turbo Edition Layer 5 MIP
If an unconnected host network variable was written to by an LNS application such as the LNS DDE Server, a DS #34 error would be incorrectly returned after several seconds. (25958)
This problem has been fixed in LNS Turbo Edition.
The LcaConfigProperty object did not expose the Inherited property. (9317)
This problem is fixed in LNS Turbo Edition.
Numbers in parentheses at the end of the problem descriptions are Echelon's internal problem tracking IDs.
Certain after-market disk defragmenters, such as Symantec's Norton Utilities Speed Disk or Executive Software's Diskeeper, can break this product's software license if the disk defragmentation software is not configured properly. Other disk utilities that bypass the operating system's file system can also break the license. The disk defragmenters built into Windows XP, Windows 2000, and Windows Server 2003 do not break the license.
WORKAROUND: Prior to defragmenting your disk using an after-market disk defragmenter, configure it not to move files with extensions *.ENT, *.KEY, and *.RST. How this is done is dependent upon the after-market disk defragmenter that you are using. If the after-market disk defragmentation program is not configurable, either use the disk defragmentation built into Windows, or use after-market disk defragmentation software that is configurable.
The first time that a pre LNS Turbo Edition global or network database is opened with LNS Turbo Edition, the database will be automatically upgraded to the LNS Turbo Edition format. This process may be time-consuming, potentially taking many minutes, depending on the database size. After this initial upgrade, LNS Turbo Edition will provide faster access to the LNS object hierarchy than previous LNS releases. (34162)
Component Name Ports
Lcaserv.exe Echelon LNS Server TCP: 2540, 2451, 8002 UDP: 2540
LdvxBroker.exe Echelon xDriver Broker TCP: 1628 by default, maybe others
PtServ32.exe POET FastObjects Server 9.5 (LNS does not use external ports)
VniServer.exe Echelon VNI Server UDP: 1628 by default, maybe others
Ltipcs.exe Echelon LonWorks-IP Configuration Server (same as VNI Server)
In the case of the LdvxBroker.exe, there may be other ports configured for use by the xDriver Profile Editor or for the “Default” xDriver Profile that is accessed from the LonWorks Interfaces item in the Control Panel.
In the case of the VNIServer, there may be other ports configured for use by the Echelon LonWorks-IP Configuration Server application.
Note that the POET FastObjects Server 9.5 does NOT have to be configured to allow external connections in order to support LNS, so you can configure the firewall to block external connections. (34238)
The LNS Server installer will fail with a cryptic error message (such as “missing DLL”) on older, unsupported versions of Windows (Windows 95/98/Me and Windows NT). (34225)
WORKAROUND: If you desire, your product installer could check for a compatible operating system.
If you have a device on the network, and you are monitoring it with a point within a temporary monitor set when the device is deleted, you will not get an lcaMonitorEventTypeNvDelete event from OnNvMonitorPointEvent. Subsequent accesses to the stale point will return a “Data Server #374, object is not valid” exception. (34347)
LNS events are sent to all clients as they occur. A client may not receive an event for any number of reasons. LNS includes a protocol for detecting missed events and will automatically attempt to resynchronize the client. However, if a client is in the hard offline state, the events are not received and the resynchronizing protocol is not executed. (18352)
The LNS Server application will report a runtime error if the UDP port that it is specified to use is already in use. Consult the LNS Server application documentation for how to specify which UDP port the LNS Server application will use.
If you install the LNS Application Developer’s Kit on a machine that also has LonMaker Integration Tool installed, the user will not be able to start the LNS Server application until you have registered the LNS Application Developer's Kit by using the "Register LNS Application Developer's Kit" utility included with the LNS Application Developer’s Kit.
WORKAROUND: If you are not ready to register this product, you can regain LonMaker's ability to start the LNS Server by uninstalling the LNS Application Developer's Kit and re-installing LonMaker. Alternatively, you can register this product by running the Register LNS Application Developer's Kit utility in the Echelon LNS Application Developer's Kit program folder.
The Network.Replace() method can be used to replace the current NetworkServiceDevice (NSD) with another NSD from the NetworkServiceDevices collection. This is possible even if the replacement NSD belongs to another full client which is running during the replacement. However, replacing the current NSD with another that is running should not be attempted because the running version will experience communication problems. Instead, replace the current NSD with a new one or one that is not currently in use. (18451)
If a store and forward repeater is defined between an LNS Full Client and the server, and the client has not specified a channel prior to opening the system, LNS will not be able to determine the proper channel for that full client. A full client application cannot move its NSI to the correct channel--an attempt to do so will result in an "operation has been disabled, NS #91" error. It may be moved from an application running on the server machine.
If a remote client must be moved to another channel, initiate the move from a client local to the server. (17220)
Microsoft TCP/IP Networking must be installed, or else an LNS #-2524 error is reported when an LNS database is opened. Microsoft TCP/IP Networking is normally installed during operating system installation but it is an optional component if a network interface card (such as an Ethernet adapter) is not installed in the PC. Microsoft TCP/IP Networking is included on the Windows installation CD of all Windows operating systems that LNS Turbo Edition runs on. Depending upon the Windows operating system that you are using, the Microsoft TCP/IP Networking component may be named slightly differently. Consult the Windows documentation for further information on how to install the Microsoft TCP/IP Networking component. (20485)
Providing MonitorPoint update events to a remote lightweight client puts an exceptional load on the LNS Server. Because of this, if too large a number of MonitorPoint updates are received, the LNS Server cannot keep up with delivering the events and begins to exhaust available memory. The problem is compounded by the fact that once physical memory is used up, Windows starts doing memory page swaps, which further reduces real time performance and therefore worsens the situation. Ultimately the PC running the LNS Server will run out of memory, leading to a variety of problems. The resolution is to use a faster PC, or install more physical memory in the PC, or reduce the number of remote lightweight clients doing monitoring, or reduce the number of points monitored by each client, or changing the throttle rate for the points being monitored, change the points to report only by exception, or some combination of the above.
The LNS Server application optionally produces three log files. The Access Log and Error Log generally produce few messages; however the Trace Log is designed for debugging only, and produces voluminous information, especially for a monitored network. Besides the fact that the Trace Log slows down the LNS Server by up to 50%, on a very heavily loaded LNS Server, turning on the Trace Log can cause remote lightweight clients to be disconnected. Furthermore, the log file will grow until the hard disk space is exhausted. Therefore, the recommendation is to use the Trace Log for debugging purposes only.
LNS Database Recovery Wizard (18302): If you are recovering through a PCC-10, PCLTA-10, PCLTA-20 or PCLTA-21, use the LonWorks Plug 'n Play Control Panel to select the NSI NI Application. Otherwise, error "NS #138 (Local interface is in the wrong state (unconfigured)" is reported, then "NS #67 (system is not open)", then "LNS #55". Finally, the LNS Database Recovery Wizard only gives you the option to cancel the recovery.
LNS Error String #140 (18292): This error string should read: The source Network Service Device cannot be an LcaNsdTypePermanent. (Subsystem: LNS, #140)
LNS: When the maximum number of devices within a network (32385) is exceeded, the following error is reported: "An unspecified database limit was exceeded. (Subsystem: NS, #50)"
Formatting (18441): Attempting to format a 2 byte NV with the DISCRETE built-in type LNS reports the following error: "Internal Data Formatting Error (Subsystem: DS #55). The error should display "Attempt to format this NV failed".
The Routers.RemoveEx() method allows one to specify the merge option even if the two channels connected by the router are of different transceiver types. The devices will not be able to communicate after this process due to incompatible transceivers. (18415)
WORKAROUND: Only merge channels of compatible type.
If a user needs to add LNS Device Credits to an LNS Server, removing devices from a network with the AppDevice.Remove() method during the time from when the credit request is made to when the Application Key is returned will cause the returned Application Key to not be accepted.
WORKAROUND: Do not delete devices when a LNS Device Credit order is outstanding on the server PC.
The i.LON 600 Internet Server's Configuration Server can run on the same PC as LNS or it can run on a different PC. When it runs on the same PC as LNS, the Configuration Server and LNS IP Interface Device must have different IP port numbers. Port conflicts between the LNS IP Interface Device and the Configuration Server cannot always be automatically detected, especially when channels and devices are defined before the VniServer is loaded. When a port conflict is detected, the error reported is not always correct. (17249)
If you close down the LNS server while remote full clients are running, then close down the remote client, it can take a long time for the remote client to exit. This is due to the fact that there are relatively long timeouts associated with the client/server communication channel. It can take up to 4 minutes before the remote client completely exits. (18198)
The System.FileTransfer object can be used to perform file transfers to and from devices that support the LonMark File Transfer Protocol. LNS applications can specify the number of bytes to transfer, and for devices supporting random access, the start address of the transfer. Large file transfers results in correspondingly large numbers of LonWorks messages, and this burst of network traffic may temporarily affect the network as any burst of network activity would. It is recommended that LNS application consider the effect of their use of the File Transfer Protocol.
One test of the File Transfer Protocol indicated that, on a standard LonMark FT-10 channel, it takes approximately 3 seconds to transfer 5000 bytes.
File Transfer Protocol service is available to all LNS applications regardless of where they execute. Lightweight clients are restricted to transferring up to 65000 bytes in one file transfer request. The transfer size limitation does not apply to other types of clients. An attempt by a lightweight client to read more than 65000 bytes from a device in one request will result in an exception, and no data will be returned to the LNS application. An attempt to write more than 65000 bytes to a device in one request will result in an exception, and no data will have been written to the device.
WORKAROUND: This workaround is only required for lightweight clients. If the device to which the file transfer is being performed supports random access file transfer, transfer multiple blocks, each no larger than 65000 bytes.
System.GetServiceStatus() always returns zeros when invoked on an LNS Lightweight client. (19174)
If the NVMonitorPoint.Tag property is set after opening the monitor set, the OnNvMonitorPointUpdateEvent will return the pre-existing tag value. (20956)
WORKAROUND: Set the NvMonitorPoint.Tag property before opening the monitor set with NvMonitorSet.Open().
Using the Dell Recovery CD causes LNS license failure when creating an LNS database for the first time. It is believed that Dell’s use of Norton Ghost driver imaging software is behind the problem. Ghost creates a hidden partition on the hard disk that conflicts with LNS’s licensing software. (21970)
WORKAROUND: Repartition the hard disk without the hidden partition and reinstall the Windows operating system without using the Dell recovery CD.
LNS is not compatible with certain versions of Norman anti-virus software, from a company in Norway. This should not be confused with the popular Symantec Norton anti-virus software, which is compatible with LNS. (29759)
WORKAROUND: If Norman anti-virus is installed, and LNS cannot open any databases, uninstall Norman and try again.
The LonWorks Bundle Deployment Kit software, version 1.0, does not work with LNS Turbo Edition. (32459)
WORKAROUND: Use LNS 3.08.
The Extension.GetValue1(), Extension.GetValue2() and Extension.GetValue3() methods do not properly check that input extension records are less than 65000 bytes in length, so some cases of data overflow are not caught. Assigning extension records longer than this will cause client/server failures when remote clients attempt to access the data. (32590)
WORKAROUND: When creating Extension record data, limit input data to 65000 bytes in your application.
After a fresh LNS installation on Windows 2000, the “LonWorks Interfaces” Control Panel item is visible, but will not launch until after the system is rebooted. This appears to be a caching problem in the Windows 2000 Control Panel, as Windows XP does not exhibit this problem. The LNS installation will not call for a reboot in this case. (32724)
WORKAROUND: If your application embeds the LNS Server redistribution, advise the user to reboot if the operating system is Windows 2000.
Installing LNS 3 over LNS Turbo Edition causes the “LonWorks Interfaces” Control Panel item to be downgraded to the LNS 3 version. This occurs because the LNS 3 installation software was not based on Windows Installer, and is not fully interoperable with the LNS Turbo Edition’s Windows Installer based installation. (32993, 34751, 34704)
WORKAROUND: Reinstall or Repair the LNS Turbo Edition installation. If the original LNS Turbo Edition install media is not present, you can go to the “Add/Remove Programs” Control Panel item, and find the two items for “Echelon LNS Server”. One will have a text link entitled “Click here for support information.”, and the information found there will describe it as “Version: 3.20.xxx” – that is the LNS Turbo Edition entry. First uninstall the other “Echelon LNS Server” entry, then run the “Repair” option on the LNS Turbo Edition version as identified above. Note that embedding the “Echelon LNS Server” or “Echelon LNS Remote Client” distributions within your product installation will not create any connection between the your product’s installation and the LNS distribution for purposes of product Repair – only the Echelon LNS Server or Echelon LNS Remote Client item in the Control Panel will repair the Echelon software distribution.
Attempting to remove a network from the RemoteNetworks collection will result in an LNS #8 error. (33531)
WORKAROUND: Remove the remote network from the VniNetworks collection instead.
If the LNS Object Server has been opened with the lcaFlagsDirectCallbacks flag set on a Full client application, the NSD reset event will never be received even if a reset occurs. (34097)
The Subnets.Remove() method takes either a subnet name or index as an argument. The use of an index in this method will always result in an “LNS #6: The object was not found.” exception. (34708)
WORKAROUND: When removing a subnet, remove it by name.
If you open a Network and System with network management authentication turned on, close the System and Network, then attempt to re-open the same Network and System, you will get an NS #176 exception from the System.Open() method invokation. This exception is persistent until the Object Server is closed. (34400)
WORKAROUND: If you will be re-opening the same authenticated network later in an application session, either cache the opened network or call the ObjectServer.Close() method before attempting to re-open the network.
If you are installing the LNS Application Developer’s Kit/Turbo Edition software over a previous version of the LNS Application Developer’s Kit, the previous LNS Application Developer’s Kit software will be uninstalled in the process, and may cause example files to be removed. If you want to preserve old example files or other files, move them before installing the LNS Application Developer’s Kit/Turbo Edition software. (34840)
The following sequence of events can cause full clients on a network to get out of synch with the LNS Server:
1) the network database is backed up
2) a full client is added
3) the network is restored from backup
4) another computer joins the network as a full client
The result of this sequence is that the server will think that several clients are the same client and assign them the same network address. At this point, the duplicate clients will exhibit unpredictable behavior. (35000)
WORKAROUND: When reverting to a backup network database, delete the ObjectServer.VniNetworks entry named “r_<Network Name>” on any computer that has been added as a full client since the backup was made.
If two or more LNS clients are simultaneously reading and writing the value of a File Transfer Protocol based configuration property, the read and write operations may fail with a combination of NS exceptions, including #99, #11 and #4038. (35144)
WORKAROUND: Surround CP access with LNS transactions, serializing the access across multiple clients.
The Borland Delphi development environment incorrectly lists the ObjectServer.CurrentFormatLocale property as a protected member, meaning that only read access is allowed. (35077)
WORKAROUND: The following assignment code works in Delphi:
LcaObjectServer1.DefaultInterface.CurrentFormatLocale := ILcaFormatLocale(myLocale)
The LNS Database Validation tool, available in the “Echelon LNS Utilities” program folder, creates an XML report file with database validation results. This report file is placed in the network database folder for the network database that is validated. If you create a network database, then remove it, the directory tree containing the network database would ordinarily be deleted, but it will not be deleted if any extra files are found in the network database folder tree. If you then try to create the same network again, the creation will fail because files are found in the target directory tree. (35159)
WORKAROUND: Delete the legacy network database directory tree if the Network.Create() method fails.
If you are loading the application to a device and the device resets, the load may fail persistently with an NS #36. (34430)
WORKAROUND: Decommission the device, set the Neuron ID, load the application again and recommission the device.
Extensive LNS Remote Client concurrency testing was performed with both LNS client types, and a mixture of client types. However, the most extensive testing was performed with all remote clients of the same type – either lightweight or full. For this reason, we recommend that you consider using all remote clients of the same type in your enterprise application. (34423)
LNS Turbo Edition added the Auto Scope Determination (ASD) feature for LonMarkObject objects. This feature will automatically attempt to determine the scope (also known as mode) of each LonMark object on the device (during XIF import) by searching through LonMark resource files that match the device program ID at the scope 6 first, then proceeding to the lower-numbered scopes. If the scope is not found after ASD is run, the LonMarkObject.Mode will be set to lcaResourceScopeUnknown(-1).
This LonMark International approved method of determining the LonMarkObject.Mode value supersedes the behavior of earlier LNS versions, which would set a scope of 0 or 3 based on whether the LonMarkObject type index was in the standard or user range, respectively.
The LonMaker Integration Tool embeds LNS LonMarkObject.Mode information in Function Block shapes (Function Block is the new term for LonMark object), using it to match dropped FB shapes with Function Blocks that exist on network devices.
Devices that formerly set their LonMarkObject.Mode in a plug-in will not see any change in LonMaker behavior. Devices that used the default 0 and 3 values will see a change in newly-imported devices when LonMaker 3.1 is running on top of LNS Turbo Edition – Function Block shapes that worked in LonMaker running earlier LNS versions will probably no longer work on LonMaker running with LNS Turbo Edition. (34735)
WORKAROUND: LonMaker function block shapes may be easily modified to accept any number of values for the LonMarkObject.Mode property when looking for matching Function Blocks on network devices. The new values introduced by ASD may include lcaResourceScopeUnknown if there are no resource files for the device or the resource files cannot be found by LNS. They may also include the true scope value if the resource files are newly found and registered.
If one LNS remote client is making changes to the database within a lengthy transaction, and another remote client is subscribed to change events, the remote event listener may actually get notification of database changes before they are visible. New objects, for example, will only become visible to other remote clients after the transaction is committed. This is not a problem between remote and local clients, it is only a problem between multiple remote clients. (35090)
WORKAROUND: If you attempt to retrieve an object based on a database event, and get an “LNS #6: The object was not found.” exception, wait and retry the operation.
If uplink sessions with the i.LON 10 or i.LON 100 are managed by an LNS based "listener" application, the uplink session handling will be disabled if the LNS xDriver Broker service is stopped and restarted independently of the listener application. (24687)
WORKAROUND: Restart the listener application after the Broker service is restarted in order to restart uplink listening.
The NetworkVariable.DsIsDefaultFormat property does not work as documented in all cases. (20412)
WORKAROUND: You may determine whether a NetworkVariable is using its default format – that is, NetworkVariable.DsFormatType has never been manually set – by saving the value of NetworkVariable.DsFormatType, setting it to the empty string, then reading it back. If it returns the original value, it is using the default format. If this method is used and the NetworkVariable object is not using its default format, be sure to restore the original value of NetworkVariable.DsFormatType when you are finished.
Users of the DeviceTemplate.SelfDocConsistency property can experience two problems related to the property value lcaSelfDocConsistencyIdenticalOnAllDevices (0). You may receive an NS #59 error when setting the property to this value, or you may receive the same error when the property is already set to this value and you are trying to commission more than one device that does actually have identical self-documentation information. (41612, 41623)
WORKAROUND: Always choose a less-rigorous setting for this property, either lcaSelfDocConsistencyStringsMayDifferByDevice (1) or lcaSelfDocConsistencyStringsAndFormatMayDifferByDevice (2). Note that lcaSelfDocConsistencyStringsMayDifferByDevice (1) is the default setting for devices with a LonMark standard program ID.
Echelon welcomes your comments on the LNS network operating system and the LNS development products. Please direct any comments (not technical support issues) to LNS_request@echelon.com.