AAC20 - RateFolder - Optimalization of application

The article explains the application operating cycle in iSMA-B-AAC20 controllers and outlines how to use the 'RateFolder' component in order to optimize the application operating cycle. The article does not cover a question of principles of main application operating cycle, which is described in the AAC20 - ScanPeriod - Proper Configuration article.

In iSMA-B-AAC20 controllers, the application has one operating cycle in the 'app' component in the 'Scan Period' slot (by default, 200 ms). According to the time value set in this slot, all calculations and other operations (i.e., actions) in the logic are carried out. It happens that an integrator needs some calculations processed more often (e.g., every 100 ms) than others, which can be carried out in longer periods of time (e.g., every 1 min or every 15 min). If a controller's application is not too complex, the logic can be calculated easily in short periods of time as it does not overload the controller's microprocessor. If the application grows, the 'Scan Time' component's value, which indicates the actual time of the application operating cycle, can exceed the time set in the 'Scan Period' slot. As a consequence, the application operating cycle can be restarted with unfinished processes remaining from the previous cycle, and part of the logic can be blocked. 

It is therefore recommended to create an application using the 'RateFolder' components, available in the 'sys' kit. With these components, the integrator can immediately identify processes, which can be carried out in longer periods of time than the basic cycle, so they will not impede the functioning of the whole application (especially, they will not impede any time-critical processes), at the same time relieving the microprocessor and ensuring continuity and accurate logic performance.

'RateFolder' components function as a typical 'Folder' component (meaning the component containing a logic), expanded by a timer, which delays performing of the logic included in the 'RateFolder' component. Setting a value to the 'App Cycles To Skip' slot means the whole logic contained in this folder is not performed throughout the number of the controller's cycles that is indicated in the 'App Cycles To Skip' slot - the logic is performed in the first application cycle, then suspended for the number of cycles indicated in the slot, and then performed once again; and so the sequences repeats.

The example application including the following list of subprograms:

1. controlling air handling unit;
2. controlling lights in a hallway;
3. controlling floor heating in a hallway;
4. controlling supplementing of liquids (water/glycol) in heating and cooling installations;
5. monitoring electrical energy and heat meters (with trends saving) of the above facilities;
6. monitoring emergencies;
7. saving trends of sensors (e.g., outdoor air quality or outdoor temperature);

can be optimized as depicted on the figure below:

Figure 1. Example of dividing the application into smaller logics using the 'RateFolder' component and setting the 'App Cycles To Skip' slots values

In the example, assuming the default application cycle in the iSMA-B-AAC20 controller (200 ms), the listed logics will be performed in the following cycles:

1. 200 ms;
2. 200 ms;
3. 10 s;
4. 1 min;
5. 5 min;
6. 200 ms;
7. 1 min. 

Naturally, each integrator should decide individually how much time to delay particular processes while optimizing the iSMA-B-AAC20 controller, since such performing of logic always affects the quality of regulation (for example, 'LoopPoint or 'Tstat' components are calculated less often) and the reaction time to an event, for example, delayed monitoring of emergency crashes of devices in special cases may lead to their damaging.

In order to avoid situations, where an emergency crash of a pump has been reported, but the controller waits even a minute to shut it down, because the relevant logic cycle has been set to such value, it is possible in special cases to control speeding up of performing the logic contained in the 'RateFolder'. In the example below, the logic controlling supplementing of water in an installation is accelerated from 1 minute cycle to 200 ms in case of a pump emergency, and brought back to 1 minute cycle 5 seconds after normal functioning of a pump has been restored.

Figure 2. Example of speeding up slow logic in case of emergency in one of devices - the Wire Sheet view of the 'app' component

WARNING: In case of the logic contained in the 'RateFolder' component, remember that all time-critical components are not updated quicker than the cycle set in the 'RateFolder'. For example, having the 'RateFolder' component configured to 60 seconds cycle, two 'Multivibrator' components, one set to the 'Period' value of 1 second, the other set to 10 seconds, will be calculated in the same way - change of state will be executed every 60 seconds, so the real 'Period' value for both components will be in fact 120 seconds. The same applies to the 'Ramp' component - the 'Out' value will be updated according to the 'RateFolder' cycle, which can result in completely different characteristic. The below figures depict compared two historical charts (type of registration: 'COV') of the 'Ramp' component (with default settings) placed in the main application cycle (location: 'app' - 200 ms) and the 'Ramp' component placed in the 'RateFolder' (1 min):

Figure 3. Historical data from the 'Ramp' component operating in the main application cycle of 200 ms

Figure 4. Historical data of the 'Ramp' component operating in the 'RateFolder' component with the 'App Cycles To Skip' slot set to extend the cycle to 1 minute

WARNING: Each change of the 'Scan Period' slot in the 'app' component requires updating the 'App Cycles To Skip' slot in the 'RateFolder' components in order to preserve the cycle value of the logic contained in the 'RateFolder'.