- Intermittent "Completion Event Failure"
- Xenta controllers go offline and come back online randomly
- Vista Workstation
- LNS Database
- LonMaker / NL220
Completion event failure can occur for many reasons: not using Lon cable terminators, too much network traffic, "acknowledged" type SNVT bindings to a node, etc.
- "One to many" bindings set as acknowledged can cause data storms, download failures, completion event failures, X'ed values in graphics, and communication problems because controllers are busy re-sending information. The reason the controllers might be resending is because they did not get a response from one of the recipients or did not get a response in time. It then resends the packet to all of the recipients, not just the unresponsive node, and waits for acknowledgments from all of them. If one of them is offline, there will be a lot of unnecessary network traffic being generated. When "one to many" bindings are required it is almost always preferable to select unacknowledged or repeated as the binding type. Note that the default binding type for programmable controllers is acknowledged.
- If you still have problems with completion event failures after making sure that the network is correct, you can change the number of retries in the Network object. In TAC Vista Workstation, right click on the Lonworks Network object, go to Properties, select the Timer tab, under Networks timer change the retry from 2 (default) to 4.
- If using LonMaker, right click on the LNS Network Interface, go to Properties, select the time tab, set the Non Group Receive Timer to the recommended 6144ms. If NL220 is being used, double click the LNS Network Interface, go to the Network tab, change the Non Group Timer to the recommended selection 11 - 6.144s.