Issue
How to change the CX level controllers message count to improve I2 Infinet communications.
Throttling adjustments using accinfoframe1 and accinfoframe2.
Product Line
Andover Continuum
Environment
- accinfoframe, accinfoframes, acc info frame
- Continuum Cyberstation
- CX 9680
- Infinet I2 bus
Cause
Improve I2 communications on the infinet bus. Changing the CX level controller's message count on the Infinet bus to improve alarm delivery and exported data times when heavy polling is occurring.
Resolution
TPA-BOST-00-0004.00 describes several fixes, including one that improves field bus with heavy traffic. One of the fixes speeds up graphics and field bus reloads. With the latest version of the firmware the ability to throttle the number of messages during token passing has been added. This will allow a variable to adjust an Infinet bus based on the amount of traffic a particular bus is experiencing.
With the latest firmware versions 2.100028, 2.000030 for the Netcontroller 9680 there are variables that can be used to adjust the number of messages per token pass. This is very similar to the MaxInfoFrames setting on Bacnet the devices; we'll call them “accinfoframe” for this document and examples. The value can be adjusted for values of 1-128. Since the TPA was issued, the value is defaulted to 128 and if no accinfoframe variable is created the default value is 128.
In order to have the ability to adjust the number of messages in the supported controllers, an infinity numeric needs to be created in the CX/BCX. The name of the variable has to be correctly spelled but is case insensitive. The names are accinfoframe1 and accinfoframe2. Accinfoframe1 will be the setting for comm1 one and accinfoframe2 will control the setting for comm2. When configuring accinfoframe1 or accinfoframe2, make sure to select the SetPoint and back up the flash on your controller, so that you retain the settings in case of power failure.
Example of when to use throttling:
There will be instances where the accinfoframe variables will need to be throttled. For instance, lets theorize a site “ChillerPlant” and the ChillerPlantCX(9680) has 100 infinet controllers located on Comm1. In our scenario we have 3 workstations each running a graphic polling 2 points(200 points) from each Infinet controller and we are running listviews of infinitynumerics on 8 of the Infinets controllers or perhaps hundreds of points that are being collected for extended logging. As one might think, communications would begin to slow down when polling for values on approx 600 points not to mention the point to point communications of the listviews and extended logs.
With all of this traffic, the CX will dominate the network token. Since it can do 128 messages when it receives the token and it receives the token between every Infinet, the token round time can go into minutes. This means that the Infinet controllers can take minutes to deliver alarms and exported data.
Another potential scenario is if one selected 4 Infinet controllers to reload, the bus may very well be overloaded at this time and may be receiving errors on the reloads in the distribution window. One of the error messages that could be expected is “Unable to reload object CarlNet\My_9680\My_I2_814\Num_1. An invalid response was received from a remote service request.” In this example we could create a infinity numeric on the CX named accinfoframe1(for Comm1) and start to reduce the number of messages CX would generate before passing the token.
On the other extreme, if the ACCInfoFrame setting is set too low, such as to 1 as in the earlier versions of Netcontroller II firmware, this extreme traffic could cause such issues as extreme slowness of graphics and listview updates, Extended logging not being capable of retrieving the required data at the required intervals, and possibly the Infinet controllers randomly appearing to be offline to the system.
In the example above the question is “What value should the accinfoframe1 be set to?” The answer entirely depends on how much traffic is on the Infinet bus. How many extended logs, how many listviews, how many graphics, alarms and Plain English programs are creating traffic on the bus? The quick way out here would be set the accinfoframe1 to a value of 1. We know for a fact that this would slow the bus down, and you might want to increase the number to 5. As mentioned this is all dependent on the amount of traffic on the Infinet bus.
Or we could take a more in depth approach and find out what the token round time is on the bus and adjust our accinfoframe1 based on token round time. We could create the following points.
TOKEN ROUND TIMER PROGRAM
InfinityNumeric MaxTokenItem InfinityNumeric MaxTokenRound InfinityNumeric TokenRoundTime Logsize:100 Logtype: LogMaximum InfinityProgram TokenRoundCalc InfinityDateTime LastDateExport
Program code: Initialise: LastDateExport = PointMapsTests\Infinity2\i2_851\Date Goto DoTokenRoundCalc
DoTokenRoundCalc: If LastDateExport <> PointMapsTests\Infinity2\i2_851\Date then TokenRoundTime = (PointMapsTests\Infinity2\i2_851\Date - LastDateExport) – 1 LastDateExport = PointMapsTests\Infinity2\i2_851\Date Endif MaxTokenRound = maximum(TokenRoundTime) MaxTokenItem = maxitem(TokenRoundTime)
E: If TS >= 5 then Goto Initialise
The program and points above created in the CX will allow the token round time to be captured and one could essentially get very creative and change the accinfoframe value dynamically through Plain English programming. For these examples we just want to find out the token round time and manually adjust the accinfoframe1 variable to avoid any reload errors.
The TokenRoundTime, MaxTokenRound and MaxTokenItem numerics can be added to a watch window or a graphic to visually monitor the TokenRoundTime. If you see that your TokenRoundTime is 5, 10 15 seconds, this is an indication you need to reduce the accinfoframe1 value. As a rule of thumb a TokenRoundTime of less then 2 seconds is acceptable, while keeping the TokenRoundTime below 0.7 seconds is ideal.
