event the primary path fails. Redundant and unreliable paths can be eliminated by
activating neighbor-filters in the various nodes and by disabling some beacons.
8.5.3.6 Maintaining Links
Links are maintained by means of the CVI (p. 511). The CVI can be specified in
each node with the Verify Interval setting in DevConfig (ComPorts Settings).
The following rules apply:
Note During the hello-message, a CVI must be negotiated between two
neighbors. The negotiated CVI is the lesser of the first node's CVI and 6/5ths of
the neighbor's CVI.
• If Verify Interval = 0, then CVI = 2.5 x Beacon Interval
• If Verify Interval = 60, then CVI = 60 seconds
• If Beacon Interval = 0 and Verify Interval = 0, then CVI = 300 seconds
• If the router or master does not hear from a neighbor for one CVI, it begins
again to send a hello-message to that node at the random interval.
Users should base the Verify Interval setting on the timing of normal
communications such as scheduled LoggerNet-data collections or datalogger-to-
datalogger communications. The idea is to not allow the CVI to expire before
normal communications. If the CVI expires, the devices will initiate hello-
exchanges in an attempt to regain neighbor status, which will increase traffic on
the network.
8.5.4 PakBus Troubleshooting
Various tools and methods have been developed to assist in troubleshooting
PakBus networks.
8.5.4.1 Link Integrity
With beaconing or neighbor-filter discovery, links are established and verified
using relatively small data packets (hello-messages). When links are used for
regular telecommunications, however, longer messages are used. Consequently, a
link may be reliable enough for discovery using hello-messages but unreliable
with the longer messages or packets. This condition is most common in radio
networks, particularly when maximum packet size is >200.
PakBus communications over marginal links can often be improved by reducing
the size of the PakBus packets with the Max Packet Size setting in DevConfig
Advanced tab. Best results are obtained when the maximum packet sizes in both
nodes are reduced.
8.5.4.1.1 Automatic Packet-Size Adjustment
The BMP5 file-receive transaction allows the BMP5 client (LoggerNet) to specify
the size of the next fragment of the file that the CR1000 sends.
Note PakBus uses the file-receive transaction to get table definitions from the
datalogger.
Because LoggerNet must specify a size for the next fragment of the file, it uses
whatever size restrictions that apply to the link.
397
To Next Page
Loading...
Need help?
General
