LNS® Server/Turbo
Edition Service Pack 6 ReadMe
December 2009
Copyright © 2004 – 2009 Echelon Corporation
All Rights Reserved
This LNS Server/Turbo Edition Service Pack 6 update fixes customer-reported problems with installations of LNS Server 3.20, 3.21, 3.22, 3.23, 3.23A, 3.24, 3.24A, and 3.25, and may be applied to any of those installations. It may also be applied to LNS Server/Turbo Edition Service Pack 1 (3.21) 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 this update is applied, you would refer to it as LNS Turbo Edition Service Pack 6 or LNS 3.26.
Additional information and updates, including critical updates, may be available at www.echelon.com/downloads.
LNS® Server/Turbo Edition Service Pack 6 ReadMe December 2009
Copyright © 2004 – 2009 Echelon Corporation All Rights Reserved
4 Silent LNS Runtime Installations
5 Repairing an LNS Runtime Installation
6 Changes in LNS 3.26 (Turbo Edition SP 6)
6.1 Neuron Firmware Version 18 and 19 Support
6.5 NodeBuilder FX Compatibility
6.6 Large Configuration Properties
7 Changes in LNS 3.25 (Turbo Edition SP 5)
7.1 LNS #116 Errors after AppDevice.Upgrade
7.2 Database Validation Improvements
7.3 Database Repair Improvements
7.4 Installing SP4 followed by SP4A shows two LNS Server entries
7.5 Ad-hoc installation problems
7.6 Memory leak with network variable monitoring
7.7 LNS DDE Server fails with LNS #6 Error
7.8 AppDevice.Name stale on name change event
8 Changes in LNS 3.24A (Turbo Edition SP 4A)
8.1 ConfigProperty.Value Changes Are Not Persistent
9 Changes in LNS 3.24 (Turbo Edition SP 4)
9.1 LNS Channel Type Determination
9.2 Vista Installation Warnings Eliminated
9.7 Neuron Firmware Version 17 Support
9.8 LonMarkObjects.Remove(index) Update
9.9 Networks(index) Memory Leak
9.10 Database Corruption Issues Fixed
9.12 Router.PreMove/Router.PostMove
9.13 Access Violation in LCAENG.DLL
9.14 NS #149 Error After Deleting and Restoring a Network
9.15 NS #130 Error When Replacing a Network
9.16 Slow Updates for Large Configuration Properties
9.17 Lost LonMark Resource Files
9.18 AppDevice.Upgrade Problems
9.19 Routers.ItemByNeuronId Errors
9.20 Database Validation Improvements
9.21 CP/NV Access Performance Improvements
9.23 DownloadConfigProps Failures
9.24 GetMessagePoint Failures on a Remote Full Client
10 Changes in LNS 3.23A (Turbo Edition SP 3A)
10.2 Updated NodeSim User’s Guide
11 Changes in LNS 3.23 (Turbo Edition SP 3)
11.1 New Redistributable Tools and Components
11.2 New LNS Turbo Performance Update Event
11.3.1 LNS VniServer Process Shut Down
11.3.6 Inherited Functional Profiles
11.3.8 Network Interface Assignment
11.3.9 Channel.AppDevices Collection
12 Changes LNS 3.22 (Turbo Edition SP 2)
12.1 New Interface.AllowDuplicateNvNames() Property
12.2 New LNS Turbo Database Upgrade Event
12.4.1 LNS 3.08 and LNS Turbo Compatibility
12.4.2 Multiple-client Deadlock
12.4.3 Configuration Properties
12.4.5 LNS VniServer Process Shuts Down
12.4.6 LNS Turbo German Strings
12.4.12 Firmware Version 16 Upgrade
12.7 NetworkVariable.ParentInterface
13 Problems Fixed in LNS 3.21 Update 1 (Turbo Edition Service Pack 1, Update 1)
13.1 Network Variable Type Conflicts
14 Problems Fixed in LNS 3.21 (Turbo Edition SP 1)
14.4 System.Connections Property
14.6 NetworkVariable.GetDataPoint() and DataPoint.GetRawValue()
14.7 DeviceTemplate.ResyncToResources()
14.9 LNS DDE Server Application Messages
14.11 NetworkVariable.Value Property
14.12 AppDevice.Upgrade() Method
14.13 Network Database Corruption
15 Problems Fixed in LNS 3.20 (Turbo Edition)
15.2 LNS VniServer Process Shut Down
15.5 Implicit Network Variable Connections
15.6 DataPoint.GetField() Method
15.8 Network Interface Operations
15.9 GetElementFromDevice Method
15.11 Network Interface Program IDs
15.12 Unconnected Host Network Variable
16 Known Problems and Workarounds
16.1 Application Download on PL-20 Channels
16.2 LNS 3 Incompatibility with Programmatic Names
16.5 Windows XP SP2 Port Blocking
16.6 Unsupported Versions of Windows
16.9 LonMaker Integration Tool and the LNS ADK
16.11 Moving Remote Full Clients
16.17 Ordering LNS Device Credits
16.18 i.LON 600 Internet Server Configuration Server
16.19 Closing Remote Full Clients
16.20 LonWorks File Transfer Protocol Support
16.21 System.GetServiceStatus() on LNS Lightweight Clients
16.22 NvMonitorPoint.Tag Property
16.23 Recovery CD Mechanism from Dell
16.24 Norman (not Norton) Anti-virus Software
16.25 LonWorks Bundle Deployment Kit (OSGi) Software
16.26 Extension.GetValueX() Methods Range Checking
16.27 LonWorks Interfaces Control Panel
16.29 OnNetworkServiceDeviceResetNew Event
16.33 Configuration Properties
16.38 LonMaker Functional Block Shapes
16.39 Event Timing with Multiple Remote Clients
16.40 LNS xDriver Broker Service
16.41 NetworkVariable.DsIsDefaultFormat Property
16.42 DeviceTemplate.SelfDocConsistency Property
16.45 Visual Studio 2005 or 2008 Failures
16.46 NS #51 Error Documentation
16.47 Traversing Lists with LNS Clients
16.48 Vista: Driver Installation Warning on Windows Vista
16.49 Vista: LNS ADK Install, ldrfcat.exe run
16.50 Vista: Online Help Problem
16.51 Application Load Warning
16.52 Swapped Near and Far Side Neuron IDs
16.53 Moving AppDevices Documentation
16.54 LNS ADK Monitor Point Example
16.55 Database Validation and Repair
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.4 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 Web sites, respectively. If you are licensed to redistribute the LNS runtime with your application, you are licensed to redistribute these runtimes as well.
This software product is installed using Microsoft Windows Installer technology. Some components of this product were also present in earlier installations of Echelon products that did not follow the Windows Installer installation rules. As a result, installing some older Echelon products after installing this product may revert some files to obsolete versions. Workaround: If you experience software behavior changes as a result of another software installation, you can repair this product installation through the following procedure:
The programs that you may need to repair in the Add or Remove Programs program list include the following:
Starting with the LNS 3.23 release, the Echelon LNS Server installation no longer shows a Repair button in the Add or Remove Programs program list. If you need to repair an Echelon LNS Server Turbo installation, you may do so by installing the Echelon LNS Server Service Pack 6 update, even if it has been previously installed.
The following changes are included in LNS 3.26 and LNS Turbo Edition Service Pack 6, which is an update to the LNS Turbo redistribution. This update may be applied directly to LNS Server 3.20, 3.21, 3.22, 3.23, 3.23A, 3.24, 3.24A or 3.25 redistributions. Numbers in parentheses at the end of the problem descriptions are Echelon's internal problem tracking IDs.
Added support for system image upgrade/downgrade for Neuron firmware versions 18 and 19. This support does not include devices based on the FT 5000 or Neuron 5000, which already include version 18 or 19 firmware, and may not be downgraded. (54791)
A fatal error occurred when upgrading some databases from LNS 3.0 to LNS Turbo. (53584, 54898)
Neuron hosted devices with more than 62 network variables that do not include self-identification data are now supported. (54938)
The network variable and alias configuration tables are now correctly initialized for Neuron hosted devices with a total of more than 255 network variables plus aliases. (54527, 54545)
Replacing a router would sometimes fail due to an unnecessary check of the router far-side Neuron ID. (54331)
If the LNS Service Pack 5 installer was run more than once on the same computer, it would cause a newer version of the NXE and XIF file conversion utilities in NodeBuilder FX to be overwritten. (54895)
The LonWorks® File Transfer Protocol (FTP) used in conjunction with priority messaging would fail when downloading configuration properties larger than 48K bytes. (54860)
The following changes are included in LNS 3.25 and LNS Turbo Edition Service Pack 5, which is an update to the LNS Turbo redistribution. This update may be applied directly to LNS Server 3.20, 3.21, 3.22, 3.23, 3.23A, 3.24 or 3.24A redistributions. Numbers in parentheses at the end of the problem descriptions are Echelon's internal problem tracking IDs.
An AppDevice.Upgrade operation will succeed, but when the resulting UpgradeStatus object is accessed an LNS #116 exception will be thrown for each change resulting from the upgrade. Applications that depend upon the UpgradeStatus being successfully read will fail. In the LonMaker Integration Tool, this means that a drawing resynchronization to the database is necessary after an upgrade operation. (51122)
Several internal improvements were made to database validation. These include fixes for the following problems:
Several internal improvements were made to database repair. These include fixes for the following problems:
Installing LNS Server SP4 followed by SP4A leaves two LNS Server entries in the Windows Control Panel “Add or Remove Programs” list. Uninstalling one of them is benign, and will leave the LNS Server functional. The multiple LNS Server entries will be cleaned up in this release. (50920)
Several fixes were made for ad-hoc installation issues:
A memory leak sometimes occurred when monitoring network variables. (52579)
In some cases, the LNS DDE Server, when running as a remote client, would fail with an LNS #6 error. (52469)
After an LcaObjectRenamed event was received for an AppDevice, in some cases, fetching the AppDevice.Name would still show the old name. (52758)
Race conditions resulted in the VniServer process crashing when monitoring network variables. (52664, 52665)
The following changes are included in LNS 3.24A and LNS Turbo Edition Service Pack 4A, which is an update to the LNS Turbo redistribution. This update may be applied directly to LNS Server 3.20, 3.21, 3.22, 3.23, 3.23A or 3.24 redistributions. Numbers in parentheses at the end of the problem descriptions are Echelon's internal problem tracking IDs. The version number found in the Windows Control Panel Add or Remove Programs, the Echelon LNS Server item, is the best way to determine whether a PC has SP4 or SP4A applied. The version shown for SP4 is 3.24.042. The version for SP4A is 3.24.048.
Numbers in parentheses at the end of the problem descriptions are Echelon's internal problem tracking IDs.
Changes to the ConfigProperty.Value property for many ConfigProperty objects were no longer persistent, although no exception was thrown. (50884)
The following changes are included in LNS 3.24 and LNS Turbo Edition Service Pack 4, which is an update to the LNS Turbo redistribution. This update may be applied directly to LNS Server 3.20, 3.21, 3.22, 3.23, or 3.23A redistributions. Numbers in parentheses at the end of the problem descriptions are Echelon's internal problem tracking IDs.
Prior to this LNS release, if the user moved a NetworkServiceDevice from one channel to another, the channel type of the new channel switched automatically to the network interface transceiver type. This behavior was found to be disruptive for some LNS applications.
LNS will now keep track of whether the channel type has ever been set by the user, or by new network interface assignment to the channel. When going OnNet with a network interface newly assigned to a channel, the channel's transceiver type will be set to match the network interface, but only if it has never been set by this process before, and if the user has never set it explicitly.
This changed behavior will require different workaround behavior in some cases. For example, suppose the first time the network is set OnNet it uses the wrong network interface, with the wrong channel type. Previously this could be fixed by closing the network, switching interfaces, going OffNet, and going back OnNet. Now it requires setting the channel type explicitly. (48110)
When the LNS Server or an LNS service pack was installed, Windows Vista displayed an "unidentified program wants access to your computer" message, or a message stating that the software to be installed had an “Unidentified Publisher”. Starting with this release, the LNS installations are digitally signed by Echelon Corporation, so these Vista warnings are no longer displayed. (43756, 50632)
The CrypKey runtime files within LNS are updated in this release, to address the following issues:
The OpenLDV installation embedded within the LNS Server install has been upgraded to OpenLDV 3.4. (50616)
Several new events were added in order to help LNS clients maintain cache consistency in multi-client environments.
See the LNS 3.24 ADK Help Addendum, available within the LNS 3.24 ADK Update at www.echelon.com/lns, for details. (34656, 35625, 48107)
New properties have been added to ConfigurationProperty, NetworkVariable and Interface objects to provide better cross reference between CPs and NVs implementing CPs.
See the LNS 3.24 ADK Help Addendum, available within the LNS 3.24 ADK Update at www.echelon.com/lns, for details. (48109)
Added support for system image upgrade/downgrade for Neuron firmware version 17. (48756)
The LonMarkObjects.Remove(index) method did not work like any other “access by index” method. It failed to convert the index from its external representation to its internal representation correctly, resulting in removal of the wrong object or an error. (44602)
When accessing the Networks collection with an invalid index, a memory leak occurred. (45410)
Several LNS database corruption issues were fixed. These typically occurred when modifying a dynamic device interface when simultaneously accessing that interface from another LNS client. Other issues involved upgrading from a device with a static interface to one with a dynamic interface. (45424, 47443, 48154, 48198, 48649)
In some cases, when an LNS-based application was running as a service and SP3A was installed, the LNS global database was deleted. (45750)
After SP3 was installed, the Router.PreMove operation, followed by Router.PostMove did not result in a changed network topology. (45893)
On Windows Vista, the following sequence would sometimes cause an Access Violation in LCAENG.DLL:
(46080)
An NS $#149 error would occur in the LonMaker Integration Tool when using the i.LON LNS Proxy application. If you deleted the network in the LonMaker tool, and then immediately restored the network database with the same name from a backup, you could get this error in the LNS Proxy application the next time that the database was accessed. (47196)
The Network replace procedure consists of the following steps:
This procedure would result in an NS #130 exception during step 3. (47628)
Updating a ConfigurationProperty that was greater than 96 bytes would take a very long time over the network, increasing geometrically with the size of the CP. (47994)
Upgrading from LNS 3.08 to LNS 3.23 removed LonMark Resource Files if version 13.00.08 or higher of the resource files installation was present. (48185)
Numerous problems were fixed in the AppDevice.Upgrade feature. (48191, 48192, 48215, 48221)
Routers.ItemByNeuronId could only find a Router if the near side Neuron ID was passed in. It would not find the Router if the far side Neuron ID was passed in. (48293)
Several internal improvements were made to database validation. (48580, 49739, 49890, 50583)
ConfigurationProperty and NetworkVariable object access within LonMarkObject objects suffered some performance degradation when migrating from LNS 3.08 to LNS Turbo. Longer access times when searching these data sets is unavoidable due to improvements in object locking to prevent database corruptions. Performance in these areas has been optimized in 3.24 to give improved performance over prior LNS Turbo releases. (48787, 49141)
LNS applications would sometimes get into a state where they would get a fatal LNS DB Error -2262 when trying to open their global database. (48933)
NS #92 occurs during AppDevice.DownloadConfigProps when there are no Configuration Properties. The error logged for this benign situation has been removed. (49312)
AppDevice.GetMessagePoint failed on Remote Full Clients with an LNS #8 error. (49401)
The following changes are included in LNS 3.23 and LNS Turbo Edition Service Pack 3A, which is an update to the LNS Turbo redistribution. This update may be applied directly to LNS Server 3.20, 3.21, 3.22 or 3.23 redistributions. The SP3A update has the same version number as SP3 for most LNS components. The version number found in the Windows Control Panel Add or Remove Programs, the Echelon LNS Server item, is the best way to determine whether a PC has SP3 or SP3A applied. The version there for SP3 is 3.23.030. The version for SP3A is 3.23.040.
Numbers in parentheses at the end of the problem descriptions are Echelon's internal problem tracking IDs.
Some LNS client types were not receiving events when the ObjectServer.Flags property was set with the lcaFlagsDirectCallback value. (44566, 45411)
The NodeSim Node Simulator was added to the LNS Server SP3 runtime, but the NodeSim.pdf documentation file associated with it was obsolete. This file has been updated in SP3A. (43825)
The following changes are included in LNS 3.23 and LNS Turbo Edition Service Pack 3, which is an update to the LNS Turbo redistribution. This update may be applied directly to LNS Server 3.20, 3.21, or 3.22 redistributions. Numbers in parentheses at the end of the problem descriptions are Echelon's internal problem tracking IDs.
A new NodeSim Node Simulator has been added to the LNS Server runtime. LNS Server users can use this tool to generate network traffic to help debug network problems. For more information on this utility, see the NodeSim.pdf document in the LonWorks bin directory. (43825)
A .NET Primary Interop Assembly for LNS 3.22 has been added to the LNS Server runtime. It is only installed if the .NET 2.0, or higher, runtime is already installed on the computer. This assembly can be used by LNS applications developed using Microsoft .NET development tools. (43733)
The OpenLDV driver installed with the LNS Server has been updated to OpenLDV 3.3C. See the OpenLDV ReadMe document for a description of the OpenLDV changes. (42699)
A new LNS event type has been added to allow LNS to notify interested clients of the current value of various performance related counters. One counter is currently available—it reports the depth of the Windows message queue as a percentage of full at a resolution of 10%.
See the LNS 3.24 ADK Help Addendum, available within the LNS 3.24 ADK Update at www.echelon.com/lns, for details. (43277)
The following problems are fixed in LNS 3.23 and LNS Turbo Edition Service Pack 3.
The LNS VniServer process sometimes unexpectedly shut down when monitoring many network variables. (42302)
If the version 13 LonMark standard resource files are already installed on a computer, the LNS Turbo installation overwrites them with the version 12 LonMark standard resource files. (42245)
The LNS Server Service Pack 2 patch required the media, containing the original LNS installation, to be present when installing the patch. (42813)
The LNS Server Service Pack 2 patch would fail to install on the first attempt on many non-English versions of Windows. (42902)
On some computers, the LNS Server Service Pack 2 installation would appear to fail with a Microsoft error report dialog and an “InstallDriver Module has encountered a problem and needs to close” error message. (42851)
LNS would sometimes stop responding while commissioning a device in a network with more than ten channels. (42995)
In some cases after calling AppDevice.ResynchToTemplate and network variable names were changed as a result, the Network.Validate function erroneously reported errors on the renamed network variable objects. (42251, 42726)
A FastObjects icon is sometimes displayed on the Windows task bar. (43396)
Inherited functional profiles with non-contiguous member numbers sometimes did not work correctly. (42746)
Setting the NetworkVariable.SnvtId property of a changeable type NV to zero caused an LNS #162 error if the NV uses a SCPTnvType configuration property to change the NV type. (44272)
The error string for the LNS #162 error was missing from the LNS string server. (37086)
Upgrading from a network without a network interface to a layer 5 network interface sent unnecessary messages on the network. (43314)
The LNS Server had poor (quadratic) performance when iterating the Channel.AppDevices collection. Iterating through this collection will now cache the location of the last query and use that as a more intelligent starting point, providing a linear iteration time in most cases. (43121)
Creating an NV Monitor Point with a request to fetch the initial value could result in multiple poll requests. The number of requests has been reduced to one in all cases. (43083)
NV Monitor Points could get stuck, with value updates stopped, if there were a large number of initial value fetches pending as well as incoming updates. (42973)
The initial value fetch on NV Monitor Points is now retried until it is successful. (42919)
Lockup in a busy monitoring system would sometimes cause updates to cease. This happened under heavy monitor point event activity, coupled with getting and accessing DataPoints directly from the NV object. (43528)
Downloading CPs sometimes caused an NS #24 error if some default CP values were not available. This would occur if the device defined default CP values for its CP-NVs, but did not define them for its file-based CPs. (43603)
The following changes are included in LNS 3.22 and 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.
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 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).
See the LNS 3.24 ADK Help Addendum, available within the LNS 3.24 ADK Update at www.echelon.com/lns, for details. (34162)
The LonMark 3.4 Application-layer 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 following problems are fixed in LNS 3.22 and LNS Turbo Edition Service Pack 2.
Several compatibility problems were fixed, where LNS Turbo behaved differently than LNS 3.08. The fixed incompatibilities include:
Multiple clients accessing the LNS database simultaneously could become deadlocked. (38690, 39413)
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)
LNS full clients failed to read and write configuration property values with a length of over 140 bytes. (35940)
When installing the LNS Turbo SP1 runtime over LNS Turbo, the installer would sometimes display a “Please insert the disk: 1” message, and fail to install. The workaround was to uninstall the existing LNS release before installing the new LNS release. (40508)
If you had installed LonMark Resource files version 12.11 or 13.00 on your computer, then installed LNS Turbo, the newer LonMark Resource Files would be overwritten by version 12.00 files. 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 Silent LNS Runtime Installations for details. (39269)
The LNS VniServer process sometimes unexpectedly shut down when performing frequent updates, and when shutting down on a remote client. (39403, 39750)
In configurations where LNS Turbo was installed over the Echelon LonMaker 3.13 German Edition, and the LNS Server Application was launched, it would display an “Unsupported operation was attempted” message and then crash with an access violation. (39671)
When testing an authenticated router that had been successfully commissioned, LNS would return a misleading “key mismatch” error, 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)
When the DeviceTemplate.ResynchToResources() method was called on a DeviceTemplate containing a network variable that was defined in an associated functional profile as SNVT_xxx, that network variable would lose knowledge of its type and format. (40417)
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)
Subsystem 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 did not generate an event, whereas renaming a LonMarkObject or NetworkVariable object did. (38203, 36034, 38388)
Calling the AppDevice.MoveEx() method to move a device to another channel was silently failing on remote clients. (38199)
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. (39356)
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)
The Network.Handle property of a network is supposed to be unique within an LNS Server computer. However, it was easy to generate duplicate network handles by copying an LNS network database from one computer 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 computer to another or restored from a backup. (40505)
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)
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 device developer declares a network variable as a standard network variable type (SNVT) in the device interface (XIF) file, and incorrectly declares that same network variable as another type in the device’s functional profile, LNS sometimes changes the network variable type in the LNS database to what is incorrectly defined in the functional profile. This will result in incorrect data formatting for the affected network variable.
This problem will only be encountered if the device’s XIF file is inconsistent with the device’s functional profile in the resource file set. 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 functional profile 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 lcaResyncToResourcesOptionUpdateDevices option flag 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)
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)
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)
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)
The following problems are fixed in LNS 3.21 and LNS Turbo Edition Service Pack 1, 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 SCPTnwrkCnfg configuration property tells whether a device is self-installed or managed by an external network manager. In order to make a smooth transition from a self-installed network to an LNS-managed network, this CP should be set to CFG_EXTERNAL during the network recovery process. (37347)
On certain rare system configurations, shutting down an LNS application may display a “Microsoft Visual C++ Runtime Library” error. (36499)
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)
Access to the System.Connections property became much slower between LNS 3.08 and LNS Turbo. 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. (36923)
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 failed with a Data Server #374 exception. (36646)
A small amount of memory would be lost to the LNS-based app process when calling both NetworkVariable.GetDataPoint() and DataPoint.GetRawValue(). (36103)
The DeviceTemplate.ResyncToResources() method fails with an NS #51 exception when called for a device containing changeable-type network variables. (35610)
LNS could not replace devices with changeable types and no SNVT self-identification data if configuration properties are to be uploaded from the device. (36991)
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 a "The format type referenced does not exist (subsystem: DS, #44)" exception. (35997)
Devices with static interfaces that are brought into the network through the device discovery mechanism sometimes erroneously fail database validation. (36180)
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)
The AppDevice.Upgrade() method did not recognize network variable arrays as the same when upgrading from one device version to another. (36403)
Occasionally, a network database would become corrupted in a way that caused the database open to always fail with an NS #6 exception. (37037)
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)
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 occasionally failed to deliver the network variable update to the LNS application, if that update occurred near the time that other network variable points were disabled or enabled using single point monitoring. (28713)
Under certain rare circumstances when using a layer 5 network interface, the LNS VniServer process (VNIServer.exe) could crash. (23526)
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)
An LCA OLE error could occur when creating many Subsystem objects in a loop. (28316)
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. 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, which is available from www.echelon.com/lns.
This problem occurred only if all of the following conditions occurred:
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, or i.LON 100/600/1000 Internet Server.
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)
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)
Invoking the SetElement method on large ConfigProperty objects (larger than 2K bytes) would cause an access violation. (28953)
The LcaConfigProperty object did not expose the Inherited property. (9317)
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. You must be running the latest available firmware revision in any i.LON 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)
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)
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)
Numbers in parentheses at the end of the problem descriptions are Echelon's internal problem tracking IDs.
An application download may fail on a PL-20 channel with default transport timers if monitoring is occurring at the same time as the application download. This problem occurs because the default PL-20 channel transport timers are optimized for typical application communication and monitoring traffic, not for monitoring combined with device application downloads. Workaround: Increase the channel delay to support simultaneous monitoring and application download. To determine the appropriate channel delay, collect a protocol analyzer log of normal channel operations. In the protocol analyzer log, look for messages being sent from the Network Service Device being retried even though there are responses for those messages. Typically, in this case, the responses will be sent after all of the retries. However, due to transmission delays, some of the responses may be sent before the all of the retries have been sent. If there are a number of unexplained retries, increasing the channel cost will likely fix the problem. (43979)
In LNS 3.08, LonMarkObjects.Item(Name) and NetworkVariables.Item(Name) would sometimes search through the list of object names first, and then through the list of object programmatic names, and would then create a database inconsistency. The Item(Name) properties were always meant to take the object name as their argument, but this was not enforced in LNS 3.08. This problem has been fixed in LNS Turbo, which can lead to application incompatibility for applications that rely on this LNS 3 bug. Workaround: To search these object sets by programmatic name, call the LNS Turbo LonMarkObjects.ItemByProgrammaticName() and NetworkVariables.ItemByProgrammaticName() methods. (39407)
Certain after-market disk defragmenters, such as Symantec's Norton Utilities Speed Disk or Executive Software's Diskeeper, can break the LNS 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 the .ENT, .KEY, and .RST extensions. 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.
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 for it. (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). Workaround: Your product installer can check for a compatible version of Windows. (34225)
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. Workaround: 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 computer 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 the LonMaker tool. 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.
You can use the Network.Replace() method 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, communication problems will occur if you replace the current NSD with another that is running. Workaround: Replace the current NSD with a new one or one that is not currently in use. (18451)
If a router configured as a 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. Workaround: 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 to use LNS, or else an LNS #-2524 error is reported when an LNS database is opened. Workaround: 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 computer. 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 many MonitorPoint updates are received at the same time, 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 computer running the LNS Server will run out of memory, leading to a variety of problems. Workaround: Use a faster computer, or install more physical memory in the computer, 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. Workaround: Only use the Trace Log for debugging.
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, an "NS #138 (Local interface is in the wrong state (unconfigured)" error 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 causes LNS to report 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 you 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. Workaround: Only merge channels of compatible type. (18415)
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 computer. LNS applications that support deleting devices should warn users not to delete devices when they have an outstanding credit request.
The i.LON 600 Internet Server's Configuration Server can run on the same computer as LNS or it can run on a different computer. When it runs on the same computer 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 LNS VniServer process 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)
You can use the System.FileTransfer object to perform file transfers to and from devices that support the LonWorks 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.
One test of the File Transfer Protocol indicated that, on a standard TP/FT-10 channel, it takes approximately 3 seconds to transfer 5000 bytes.
The 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. Workaround: Set the NvMonitorPoint.Tag property before opening the monitor set with NvMonitorSet.Open(). (20956)
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. Workaround: Repartition the hard disk without the hidden partition and reinstall the Windows operating system without using the Dell recovery CD. (21970)
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. Workaround: Uninstall the Norman software before using any LNS applications. (29759)
The LonWorks Bundle Deployment Kit software, version 1.0, does not work with LNS Turbo Edition. Workaround: Use LNS 3.08 with the LonWorks Bundle Deployment Kit software. (32459)
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. Workaround: When creating Extension record data, limit input data to 65000 bytes in your application. (32590)
After a fresh LNS installation on Windows 2000, the LonWorks Interfaces Control Panel item is visible, but will not launch until after the computer is rebooted. This appears to be a caching problem in the Windows 2000 Control Panel, as Windows Vista and Windows XP do not exhibit this problem. The LNS installation will not call for a reboot in this case. Workaround: If your application embeds the LNS Server redistribution, advise the user to reboot if the operating system is Windows 2000. (32724)
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. 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. Embedding the Echelon LNS Server or Echelon LNS Remote Client distributions within your product installation will not create any connection between 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. (32993, 34751, 34704)
Attempting to remove a network from the RemoteNetworks collection will result in an LNS #8 error. Workaround: Remove the remote network from the VniNetworks collection instead. (33531)
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. Workaround: When removing a subnet, remove it by name. (34708)
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 invocation. This exception is persistent until the Object Server is closed. 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. (34400)
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 the 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. Workaround: When restoring 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. (35000)
If two or more LNS clients are simultaneously reading and writing the value of a configuration property implemented in a configuration file, the read and write operations may fail with a combination of NS exceptions, including #99, #11 and #4038. Workaround: Surround CP access with LNS transactions, serializing the access across multiple clients. (35144)
The Borland Delphi development environment incorrectly lists the ObjectServer.CurrentFormatLocale property as a protected member, meaning that only read access is allowed. Workaround: The following assignment code works in Delphi:
LcaObjectServer1.DefaultInterface.CurrentFormatLocale := ILcaFormatLocale(myLocale)
(35077)
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. Workaround: Delete the legacy network database directory tree if the Network.Create() method fails. (35159)
If you are downloading an application to a device and the device resets, the load may fail persistently with an NS #36. Workaround: Decommission the device, set the Neuron ID, load the application again, and recommission the device. (34430)
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. Workaround: Use the same type of remote clients within a network. (34423)
LNS Turbo Edition added the Auto Scope Determination (ASD) feature for LonMarkObject objects. This feature automatically attempts to determine the scope (also known as mode) of each functional block on the device (during XIF import) by searching through LonMark resource files that match the device program ID at scope 6 first, then proceeding to the lower-numbered scopes. If the functional block is not found after ASD is run, the LonMarkObject.Mode will be set to lcaResourceScopeUnknown(-1).
This 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. In most cases, this method does a better job of selecting the correct scope.
The LonMaker Integration Tool embeds LNS LonMarkObject.Mode information in Functional Block shapes, using it to match dropped FB shapes with functional 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 may see a change in newly-imported devices when LonMaker 3.1 is running on top of LNS Turbo Edition – Functional Block shapes that worked in LonMaker running earlier LNS versions may 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 functional 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 included in the resource catalog.
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. 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. (35090)
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. Workaround: Restart the listener application after the Broker service is restarted in order to restart uplink listening. (24687)
The NetworkVariable.DsIsDefaultFormat property does not work as documented in all cases. Workaround: You can determine whether a NetworkVariable object 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. (20412)
Users of the DeviceTemplate.SelfDocConsistency property can experience two problems related to the lcaSelfDocConsistencyIdenticalOnAllDevices (0) property value. 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. Workaround: Always choose a less-rigorous setting for this property, either lcaSelfDocConsistencyStringsMayDifferByDevice (1) or lcaSelfDocConsistencyStringsAndFormatMayDifferByDevice (2). The lcaSelfDocConsistencyStringsMayDifferByDevice (1) value is the default setting for devices with a standard program ID. (41612, 41623)
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. Workaround: To preserve old example files or other files, move them before installing the LNS Application Developer’s Kit Turbo Edition software. (34840)
In order to fix several LNS Turbo installation problems, LNS 3.23 and later updates perform a Windows Installer major upgrade over previous LNS Turbo installations. Since the installation programs for earlier versions of LNS—including earlier versions of LNS Turbo— do not contain checks to prevent installing over later LNS Turbo installations, they will attempt to install over LNS 3.23 or later.
Workaround: In the event that you accidentally install an earlier LNS Server installation over a more recent LNS Server installation, you may correct the problem by the following procedure:
An LNS application created using Microsoft Visual Studio 2008 (or Visual Studio 2005 with .NET Framework 2.0 SP1) runs successfully on Windows XP, but fails on Windows Vista, with the error:
Creating an instance of the COM component with CLSID {104B7F00-06EE-11CF-9AE0-0020AFD34749} from the IClassFactory failed due to the following error: 80040023
The cause of this error is an access violation when LNS tries to create its (hidden) event window. The access violation is actually caused by a Data Execution Protection (DEP) violation.
Visual Studio 2008 (or VS2005 with .NET Framework 2.0 SP1) C++ development environment, by default, specifies the linker option /NXCOMPAT, which means that the application is known to be compatible with DEP. The C# and VB.NET compilers for these Visual Studio versions also automatically set the NXCOMPAT attribute. The LNS Turbo runtime, however, is not compatible with DEP.
Microsoft Knowledge Base article #948468 <http://support.microsoft.com/kb/948468> describes the problem in more detail.
Workaround: Do one of the following two options:
Use option #1 if you are still in the application development stage. If your application is deployed, but you need a workaround in the field, use option #2.
To test whether an application has the NXCOMPAT attribute set, you can run the command "DUMPBIN /HEADERS {application.exe}" (DUMPBIN >= V8.00.50727.42) and look for the phrase "NX compatible" under the Optional Header Values > DLL Characteristics section. (48740)
The current documentation describes an NS #51 error is incomplete:
The program ID from the DeviceTemplate object does not match the one found on the device during an attempt to commission the device.
The NS #51 exception is now also thrown when importing an XIF into an existing DeviceTemplate where the program ID in the XIF does not match the program ID in the DeviceTemplate. (40967)
In chapter 4 of the LNS Programmer’s Guide, the section entitled Using Transactions with Collections recommends surrounding list traversals with a transaction. While this will result in a consistent list every time, it may also result in a visible delay if multiple clients are in use and the listing client is put in queue, waiting for the current transaction. An alternative strategy is to try traversing the list without an enclosing transaction, but retrying with a transaction if your application encounters any of the concurrency errors described in this section.
(45728)
When installing LNS (which installs OpenLDV 3.4) on Windows Vista, you will see a dialog entitled “Windows Security”. The dialog message says “Windows can’t verify the publisher of this driver software”, with the choices “Don’t install this driver software” or “Install this driver software anyway”. Workaround: Choose “Install this driver software anyway” to complete the installation. (46103, 50667)
Several LNS utility applications were built with Visual Basic 6.0, and have trouble running on Windows Vista. These applications include the LNS ADK Registration Wizard and the LNS Resource File Catalog Utility.
The problem is that the VB 6.0 runtime in these applications cannot initialize itself, which includes Registry modifications, unless it is run with Administrator privileges. Workaround: Right click on one of these applications, and select “Run as…” to run as an Administrator. After successfully running the application as an Administrator once, the problem no longer occurs.
(49970)
The LNS utility online help files do not work on new Windows Vista computers. You will see an error message if you open online help by pressing the F1 key or clicking the Help button.
This is caused by the fact that the Windows Help (WinHlp32.exe) program is no longer included with Windows operating systems starting with Windows Vista—see Microsoft’s Knowledge Base article at support.microsoft.com/kb/917607 for details. The Knowledge Base article also notes that "...third-party programs that include .hlp files are prohibited from redistributing the Windows Help program together with their products."
Workaround: Microsoft has posted a new version of WinHlp32.exe for Vista at: www.microsoft.com/downloads/details.aspx?FamilyID=6ebcfad9-d3f5-4365-8070-334cd175d4bb&displaylang=en. While Echelon may not redistribute this component, you may download it from the Microsoft website, subject to Microsoft licensing terms, and install it on your Vista computer to enable LNS utility help to function correctly. (45779)
LNS application load can be destructive to the device when loading the following Neuron Chip models: FT 3150 2K, CY7C53150 2K, and PL 3150 2K.
Workaround: Be very careful that any application image that you download into devices using these Neuron Chip models that was linked for the specific model. Never specify the system image upgrade option when downloading one of these Neuron Chip models. (49854)
The Router.MoveEx function causes the Neuron IDs of the Router near and far side to get swapped if the network interface is on an "isolated" channel with no paths to the Router. Workaround: Move the network interface to a channel with a path to the Router that you are going to move. (48540)
The LNS documentation erroneously makes the following statement:
In networks that only contain configured routers, devices that do not use authentication can be physically moved at any time while LNS is OnNet; LNS will eventually detect the move and reconfigure the device.
The only way that a device gets moved from one channel to another in the database is to use the AppDevice.PreMove and AppDevice.PostMove methods, or the AppDevice.MoveEx method. (49736)
The LNS ADK Monitoring Example has a number of problems in its implementation of the LNS Monitor Point Listener. Workaround: See the updated LNS ADK Monitoring Example code, available within the LNS 3.24 ADK Update at www.echelon.com/lns, for details. (44752)
Database validation and repair operations should follow these rules:
Echelon welcomes your comments on the LNS network operating system and the LNS development products. Please direct any comments or suggestions to lonsupport@echelon.com.