Issue
Xenta programmable controllers can communicate to each other using TAC Network Variables (TANV). These are defined in the Menta programming and travel on Xenta Group Bindings in the LNS environment. If data is failing to update in the receiving controller, there are a few troubleshooting techniques that can help.
Product Line
TAC Vista
Environment
- Xenta programmable controllers
- Xenta 280, 281, 282, 283, 300, 301, 302, 401, 401:B
- Menta
- LonMaker/NL220
Cause
TAC Network Variable communication can be compromised for four reasons:
- Network path not defined correctly in the Menta file
- Network path name is too long
- Group Bindings not done correctly in LonMaker/NL220
- Controller's network output capacity has been exceeded
Resolution
Verify the Network Path
If the network variable has been populated by browsing Menta files on the hard drive, or was entered manually, it can be the cause of the problem. Even visual inspection of the network path is not 100% reliable -- a lowercase "l" and an uppercase "I" appear the same, for example. The only way to be certain the path is correct is to browse it in through the Vista database.
- Open the Menta file from the Vista database. Right-click on the receiving controller and select Edit.
Editing a Menta file directly from the hard drive of a computer does not give you the same network browsing options and can lead to incorrectly mapped network variables. - Double click the network variable AI block and go to the Bind dialogue.
- Next to the Network Address text field is a browse button ("..."). Click it to open the network browse window. This tree structure should be the same as the folder view in Vista Workstation.
- Navigate to the sending controller's public signal and click okay.
- Download the application to the controller.
Verify that the Network Path Name is not too long
If the network variable path name, or the Network Address, is too long then this will cause a problem.The network variable path name, if the point is in a module, looks like ControllerName\ModuleName\PointName. If it is not in a module then it will have the Program Specification name instead of a module name. So it would look like ControllerName\ProgramSpecificationName\PointName. If the ModuleName\PointName or ProgramSpecificationName\PointName part of the path is longer than 33 characters, counting the "\", then it will not work.
Verify Group Bindings are correct
- Refer to Verifying Xenta Group Bindings in an LNS system for the procedure on verifying group bindings.
- If the group bindings are not correct, redo group bindings and download the sending and receiving controllers.
Calculate the total output of the controller
Depending on the controller type, there are different limits on the network variable outputs. This includes both SNVTs and TANVs. If together, they exceed the capacity, there will be spotty updates and random signals that don't make it to the receiving controller. Unfortunately, there is no easy way to count the TANVs.
- In the Menta file of the sending controller, go to Options > Memory Usage... > Advanced...
- Make note of the TACNV/SNVT Out Free number. Each SNVT output defined in the Menta file consumes one of these outputs and decreases the number of Free signals available for use with a TANV.
- The only way to count the number of network variable outputs is to know each receiving controller that is pointing back to the sending controller with a TANV.
- Unlike with SNVTs, EACH signal in EACH receiving controller consumes one of these available outputs. If the output limit has been exceeded, the communication will suffer.
- Reduce the number of network variables coming from one controller by "cascading" signals.
