IzoT TM Net Server Release Notes
Release 4.5, August 2021
© 2013 – 2021
Dialog Semiconductor Corporation
All Rights Reserved
The IzoT Net Server is the standard network management software platform for commercial and industrial LON networks. It is based on the LNS Server that is the foundation for the most capable, popular tools for designing, installing, maintaining, and monitoring LON networks, and it ensures interoperability of devices, applications, and tools.
The IzoT Net Server is included with the IzoT Commissioning Tool (CT), and is also included with other popular network tools providing their LON network management services.
The “IzoT Net Server” name is the current name for the software previously called the OpenLNS Server and the LNS Server. The “IzoT Commissioning Tool” name is the current name for the software previously called the OpenLNS Commissioning Tool (CT) and the LonMaker Integration Tool. The product names referred to by the IzoT Net Server and IzoT CT software and documentation are not all updated to the new IzoT names, so you may see references to both sets of names in the software and documentation.
For additional documentation, see the Resources listing at https://www.dialog-semiconductor.com/products/industrial-edge-computing/izot-net-server#tab-field_tab_content_resources. For the latest software updates, see http://iecdocs.diasemi.com/display/PortTL/IzoT+Net+Server+and+OpenLNS+Server.
Following are the system requirements for computers running IzoT Net Server:
· 64-bit and 32-bit versions of MicrosoftÒ Windows 10, Windows Server 2019, and Windows Server 2016.
· 1GHz x86 or x64 processor or faster (2 GHz or faster processor recommended).
· Microsoft .NET Framework 4.8 or newer.
· LON/IP or LON Network Interface. You can use any OpenLDV 5.1 compatible network interface including the Dialog SmartServer IoT and the Dialog U10, U20, U60, or U70 USB network interfaces.
You can verify that you have Release 4.5 by starting the Programs and Features control panel and checking the Version number of Echelon IzoT Network Services Server.
The “IzoT Net Server” name is the name of the of OpenLNS Server software starting with Release 4.02. The following table summarizes the OpenLNS CT releases:
OpenLNS Server 4.0
IzoT Net Server 4.0
IzoT Net Server 4.1
IzoT Net Server 4.3
IzoT Net Server 4.4
IzoT Net Server 4.5
IzoT Net Server 4.5 removes the MSXML 6 installation included with previous versions. Supported versions of Windows include MSXML 6.
Following are warnings for IzoT Net Server.
The IzoT Net Server 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:
1. Open the Windows Control Panel.
2. Double-click Programs and Features (Windows 10 or Windows Server).
3. Click program to be repaired in the program list.
4. Right-click the program, and then click Repair (Windows 10 or Windows Server).
5. Repeat steps 2 –4 for each program to be repaired in the program list. You may need to repair the following programs:
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 LonScanner™ 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. (LNSWIN-43979)
If you have a device on the network, and you are monitoring it with a data 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. Workaround: Remove the monitor point or set prior to deleting the device. (LNSWIN-34347)
The OpenLNS Remote Server will report a runtime error if the specified UDP port is already in use. Workaround: Specify an available UDP port to be used by the OpenLNS Remote Server as described in the OpenLNS Remote Server documentation.
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. (LNSWIN-18451)
If a router configured as a repeater is defined between an IzoT Network Services Full Client and the server, and the client has not specified a channel prior to opening the system, the IzoT Network Services Server 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 IzoT Network Services Server. (LNSWIN-17220)
Microsoft TCP/IP Networking must be installed to use IzoT Network Services, or else a DB #-2524 error is reported when an IzoT Network Services 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 the IzoT Network Services Server runs on. Depending upon the Windows operating system that you are using, the Microsoft TCP/IP Networking component may be named slightly differently. See the Windows documentation for further information on how to install the Microsoft TCP/IP Networking component. (LNSWIN-20485)
Providing MonitorPoint update events to a remote lightweight client puts a high load on the OpenLNS Remote Server. If too many MonitorPoint updates are received at the same time, the OpenLNS Remote 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 Remote Server will run out of memory, leading to a variety of problems. Workaround: Use remote full clients instead of remote lightweight clients, use a faster computer, install more physical memory in the computer, reduce the number of remote lightweight clients doing monitoring, reduce the number of points monitored by each client, change the throttle rate for the points being monitored, change the points to report only by exception, or some combination of the above.
The Remote Server application optionally produces an Access Log, an Error Log, and a Trace Log. 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. The Trace Log slows down the OpenLNS Remote Server by up to 50%, and on a very heavily loaded OpenLNS Remote Server, 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.
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 compatible channels. (LNSWIN-18415)
The Echelon IP-852 Configuration Server can run on the same computer as the IzoT Network Services Server or it can run on a different computer. When it runs on the same computer as the IzoT Network Services Server, the IP-852 Configuration Server and IP-852 network interface must have different IP port numbers. Port conflicts between the IP-852 network interface and the IP-852 Configuration Server cannot always be automatically detected, especially when channels and devices are defined before the IzoT Network Services VniServer process is loaded. When a port conflict is detected, the error reported is not always correct. Workaround: If you run the Echelon IP-852 Configuration Server and the IzoT Network Services Server on the same computer, configure them to use different IP port numbers. (LNSWIN-17249)
If you close down the OpenLNS Remote 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. Workaround: Close remote clients before closing the OpenLNS Remote Server. (LNSWIN-18198)
You can use the System.FileTransfer object to perform file transfers to and from devices that support the LON File Transfer Protocol. IzoT Net Server 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 LON messages, and this burst of network traffic may temporarily affect the network as any burst of network activity would. On a standard TP/FT-10 channel, it can take approximately 3 seconds to transfer 5000 bytes.
The File Transfer Protocol service is available to all IzoT Net Server 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 IzoT Network Services 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: If you are using a lightweight client to do a LON file transfer and 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 IzoT Net Server remote lightweight client. Workaround: Do not use System.GetServiceStatus() on an IzoT Net Server remote lightweight client. (LNSWIN-19174)
If the NVMonitorPoint.Tag property is set after opening a 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(). (LNSWIN-20956)
Attempting to remove a network from the RemoteNetworks collection will result in an IzoT Net Server #8 error. Workaround: Remove the remote network from the VniNetworks collection instead. (LNSWIN-33531)
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 “LCA #6: The object was not found.” exception. Workaround: When removing a subnet, remove it by name. (LNSWIN-34708)
The following sequence of events can cause full clients on a network to get out of synch with the IzoT Network Services 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 IzoT Net Server may incorrectly assign the same network address to multiple clients. 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. (LNSWIN-35000)
If two or more IzoT Net Server 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 IzoT Net Server transactions, serializing the access across multiple clients. (LNSWIN-35144)
The IzoT Net Server Database Validation tool, which is available in the Echelon IzoT Network Services 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. (LNSWIN-35159)
Using a mixture of remote full clients and remote lightweight clients on the same network may sometimes result in unexpected behavior. Workaround: Use the same type of remote clients within a network, either all remote full clients or remote lightweight clients. (LNSWIN-34423)
The Auto Scope Determination (ASD) feature for LonMarkObject objects 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).
The IzoT Commissioning Tool (CT), OpenLNS Commissioning Tool (CT), and the LonMaker Integration Tool embed IzoT Network Services LonMarkObject.Mode information in Functional Block shapes, using it to match dropped Functional Block 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 IzoT CT, OpenLNS CT, or LonMaker behavior. Devices that used the default 0 and 3 values may see a change in newly-imported devices with IzoT CT or OpenLNS CT—Functional Block shapes that worked in the LonMaker tool running early LNS versions may no longer work on OpenLNS CT.
Workaround: Modify the IzoT CT or OpenLNS CT Functional Block shapes that no longer work 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 the IzoT Net Server. They may also include the true scope value if the resource files are newly found and included in the resource catalog. (LNSWIN-34735)
If one IzoT Net Server 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 “LCA #6: The object was not found” exception, wait and retry the operation. (LNSWIN-35090)
If uplink sessions with a SmartServer are managed by an OpenLNS listener application, the uplink session handling will be disabled if the OpenLNS 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. (LNSWIN-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. (LNSWIN-20412)
The current documentation describing an LCA #51 error is incomplete. The current error description is as follows: “The program ID from the DeviceTemplate object does not match the one found on the device during an attempt to commission the device.”
Workaround: Following is the updated documentation: The LCA #51 exception is now also thrown when importing an XIF file into an existing DeviceTemplate where the program ID in the XIF file does not match the program ID in the DeviceTemplate. (LNSWIN-40967)
In chapter 4 of the OpenLNS 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. Workaround: If your application encounters excessive delays when traversing a list, traverse the list without an enclosing transaction, but retry with a transaction if your application encounters any of the concurrency errors described in this section. (LNSWIN-45728)
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. (LNSWIN-48540)
The OpenLNS documentation makes the following incorrect statement: “In networks that only contain configured routers, devices that do not use authentication can be physically moved at any time while OpenLNS is OnNet; OpenLNS will eventually detect the move and reconfigure the device.” Workaround: To move a device from one channel to another, always use the AppDevice.PreMove and AppDevice.PostMove methods, or the AppDevice.MoveEx method. (LNSWIN-49736)
Database validation and repair operations must adhere to the following rules:
· Databases that are repaired must always be validated again after repair. Occasionally, database validation will detect additional repairable errors after a repair is done, as the first round of repairs can fix database object interconnections in such a way that other errors may subsequently be detected and repaired.
· Databases must always be backed up before validation and repair operations are attempted, in addition to normal periodic backups.
If you have previously installed LNS release 3.08 or earlier, and then install the IzoT Network Services Server without first upgrading to LNS Turbo Edition, you may see an error dialog each time the computer is rebooted or you log on to the computer, that contains the text “SntpClient.exe – Entry Point Not Found”. Workaround: You may close the dialog box and ignore the error. The SntpClient.exe is not required for the IzoT Network Services Server. To prevent this error message from appearing again, remove the "Echelon LNS SNTP Client" value from the following Windows registry key: “HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Run”. (LNSWIN-65834)
When importing a device template, you may receive a File Transfer Failure Error (NS #103) if the folder containing the XIF file for the device template is not writable. The IzoT Network Services Server needs to rewrite the XFB and XFO files if they use an older format (for example, if the file were created with LNS). By default, all users can write to the LonWorks Import folder, but if the XIF, XFB, and XFO files are stored in a different folder, you may need to modify the permissions on that folder so that the files can be updated. (67514)
You may also encounter this error if you try to import a XIF file using only a relative path (for example, manf\prod\dt.xif). With the LNS Server, this path was interpreted relative to the current working directory of the process. With the IzoT Network Services Server, this path is interpreted relative to the path specified in the System.ImportDirectory property. (LNSWIN-62283)
By default, the IzoT Network Services Server runs an IzoT Network Services database server as a service running under the Network Service account. The IzoT Network Services database server is based on a FastObjects Server service. Generally, this improves system performance; however, if you try to use or add a network database that is located on a remote drive to the global database using a mapped drive (for example, X:\DB) or a UNC path (for example, \\SERVER\SHARE\DB), you may receive a database error (for example, DB #-2019 or #-2031). This is because mapped drives are user-specific and typically not available to services, and network sharing permissions may restrict access to the service account unless they are set correctly. Workaround: Change the FastObjects Server service to run under a user account that has appropriate access to the shared network resource. Alternatively, you can stop and disable the FastObjects Server service. If the FastObjects Server is stopped, it will be started as needed under the account of the currently logged in user. (LNSWIN-63941)
When importing an XIF file, a plug-in may fail with a "File transfer failed due to file open error" (NSS #103). This occurs if the IzoT Network Services Server tries to update the plug-in supplied XFB file, but the XFB file (and all other plug-in files) was installed under the C:\Program Files directory without a DACL, which left the files as read-only. Workaround: Make the folder containing the files writable. (LNSWIN-67514)
When starting an IzoT Net Server application, it may fail with a “LonTalk stack has not been opened” (NI #22). This occurs if the permission on registry entry was not set to full control for Everyone. To prevent this error message from appearing again, add group permission of “Everyone” to Full control in the following Windows registry key: “HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\LonWorks\DeviceDrivers”. (LNSWIN-15516)
Dialog, Adesto, Echelon, LON, the Dialog logo, the Adesto logo, the Echelon logo, LonWorks, NodeBuilder, LonTalk, LonPoint, Neuron, 3120, 3150, LNS, i.LON, ShortStack, LonMaker, IzoT, OpenLDV, LonScanner, and LonBridge are trademarks of Dialog Corporation that may be registered in the United States and other countries. For a complete list of registered trademarks see the Dialog web site at www.dialog-semiconductor.com. All rights reserved.
Other trademarks belong to their respective holders.