Patent Publication Number: US-8112162-B2

Title: System level function block engine

Description:
This application is a continuation-in-part of U.S. patent application Ser. No. 11/620,431, filed Jan. 5, 2007. 
     This application is a continuation-in-part of U.S. patent application Ser. No. 11/427,750, filed Jun. 29, 2006. 
     This application is a continuation-in-part of U.S. patent application Ser. No. 11/564,797, filed Nov. 29, 2006. 
    
    
     BACKGROUND 
     The present invention pertains to engines for designing systems, and particularly to designing controller systems. More particularly, the invention pertains to designing control systems for buildings, engines, aircraft, and so forth. 
     The present invention may be related to U.S. Pat. No. 6,549,826, issued Apr. 15, 2003, U.S. Pat. No. 6,536,678, issued Mar. 25, 2003, and U.S. Pat. No. 5,479,812, issued Jan. 2, 1996. 
     U.S. Pat. No. 6,549,826, issued Apr. 15, 2003, U.S. Pat. No. 6,536,678, issued Mar. 25, 2003, U.S. Pat. No. 5,479,812, issued Jan. 2, 1996, and U.S. patent application Ser. No. 11/427,750, filed Jun. 29, 2006, are hereby incorporated by reference. 
     U.S. patent application Ser. No. 11/620,431, filed Jan. 5, 2007, is hereby incorporated by reference, U.S. patent application Ser. No. 11/427,750, filed Jun. 29, 2006, is hereby incorporated by reference. U.S. patent application Ser. No. 11/564,797, filed Nov. 29, 2006, is hereby incorporated by reference. U.S. patent application Ser. No. 11/559,706, filed Nov. 14, 2006, is hereby incorporated by reference. 
     SUMMARY 
     The invention is a function block engine system. 
    
    
     
       BRIEF DESCRIPTION OF THE DRAWING 
         FIG. 1  is a diagram of a relationship of the function block engine system, computer and resulting circuit or system. 
         FIG. 2  shows a display screen set up for designing circuits or systems with function blocks; 
         FIG. 3  shows a second page of the screen of  FIG. 2 ; 
         FIG. 4  shows from the screen a partial list of function blocks and other items that may be used in designing a circuit or system; 
         FIG. 5  shows a screen for a simulate mode for the designed circuit or system of  FIGS. 3 and 4 ; 
         FIG. 6  shows a second page of the screen of  FIG. 5 ; 
         FIG. 7  shows a table of data from the simulation of the designed circuit or system of  FIGS. 5 and 6 ; 
         FIG. 8  is a graph of the data in the table in  FIG. 7 ; 
         FIG. 9  shows a display screen with one of several pages showing a designed system have somewhat more complexity that the example circuit or system of  FIGS. 2 and 3 ; 
         FIG. 10  shows a dialog box with inputs, a parameter and an output; 
         FIG. 11  is a block diagram of a flow velocity calibration and balancing system; 
         FIG. 12  is a diagram of the air flow sensor; 
         FIG. 13  is an extended block diagram of a system like that of  FIG. 11 ; 
         FIG. 14  is an input/output block diagram that may be associated with interacting with an operating system of a system like that in  FIG. 13 ; 
         FIG. 15  reveals a linearization table; 
         FIG. 16  shows an engineering units lookup table; 
         FIG. 17  shows a velocity pressure (VELP) function block; 
         FIGS. 18 and 19  show a table of analog inputs and a table of outputs, respectively, for the VELP function block or module; 
         FIG. 20  is a list of network variables (NVs) used in the function block engine for balancing; 
         FIG. 21  is a diagram of a variable air volume balancing overview; 
         FIG. 22  is an overview block diagram of the present system with its interaction with a microcontroller; 
         FIG. 23  shows a schematic of illustrative example of a variable air duct system; 
         FIG. 24  is a graph of displayed air flow and measured air and a basis for correction; 
         FIG. 25  is a diagram of a hood used for measuring air flow; 
         FIG. 26  is a graph showing a relationship between air flow rate and pressure; 
         FIG. 27  is an overview diagram of a balancing block showing inputs and outputs; 
         FIG. 28  shows a diagram of a balancing system and times for activity between the system and several other components; 
         FIG. 29  is a diagram of a function block system; 
         FIG. 30  is a summary variable air volume block flow diagram; 
         FIG. 31  is a block diagram of an illustrative programmable HVAC controller; 
         FIG. 32  is a schematic diagram of an illustrative application framework of a programmable controller; 
         FIG. 33  is a schematic diagram of illustrative application configuration modules of  FIG. 22 ; 
         FIG. 34  is a schematic diagram of one or more execution modules of  FIG. 32  including a function block engine; 
         FIG. 35  is a diagram of a stage driver; 
         FIG. 36  is a diagram of a function block arrangement for the stage driver; 
         FIG. 37  is a table of analog inputs for the stage driver; 
         FIG. 38  is a table of analog outputs of the stage driver; 
         FIG. 39  is a diagram of a stage driver addition; 
         FIG. 40  is a table of the analog input for the stage driver addition; 
         FIG. 41  is a table of the analog outputs for the stage driver addition; 
         FIG. 42  shows a stage driver with several stage drivers adds; 
         FIGS. 43-48  constitute a block diagram of the stage driver; 
         FIG. 49  is a diagram of the stage driver add; and 
         FIGS. 50-56  relate to stage drivers as discussed herein. 
     
    
    
     DESCRIPTION 
     With the present invention, one may design and/or implement a system controller or another system having virtually no hardware except for the computer used to design and put the resulting software into a memory, e.g., in a form of microcode or other manner. An ordinary computer may provided the resulting function block engine designed software input to it, i.e., to a memory, and the computer may effectively become the designed controller with function blocks, interconnections, links, inputs, outputs, selections, adjustments, interfaces, a display, visual and/or audio indicators for showing variables, parameters, readings, prescriptions, results, on-station and/or remote monitoring and control whether by keyboard, mouse, touch screen, voice command, eye tracking and blinking control, or other communicative manner, having diagnostics, simulation capabilities within itself and a system to be controlled, plus more, effectively all in conveyable software. For an illustrative instance, one&#39;s home computer may loaded with and use the present system level function block engine to design virtually any kind of system controller in a context of software. After design, simulation and testing, as desired, this computer may become the designed system controller for an actual application, or the software may be transferred to another computer or other device to become the system controller. The computer, or some other like-designed processor, programmable personal assistant (PDA), cell phone, device and so on, with the software may become the designed system controller such as, for one among many examples, a programmable thermostat for a building HVAC. Communication between the controller on the computer and the controlled system may be via wireless or non-wireless media. 
     Additionally, in the commercial HVAC industry, there may be a need to have complex applications that are tested and implemented in controlling devices. These devices should be low cost and be able to meet application needs. There also appears to be a need to have a flexible low cost controller that allows applications to be met as demands change within the low cost controller platform and tools. The function block framework of the present invention may provide a logical application structure that allows a system control application designer (e.g., HVAC) to combine pre-designed blocks featuring powerful control capabilities and thorough connections of libraries and block functions, that may be incorporated the development of sophisticated applications to meet new and advanced customer needs. 
     The present function block engine system may use relatively little memory in view of its significantly powerful and revolutionary capabilities. Programmable controllers may be implemented as engines that can interpret a meta language that is resident wholly or partially in a random access memory (RAM) as it runs. This means that minimal RAM requirements for a small program may be about 15 K bytes (Kb) and can grow in proportion to the program. An inexpensive microprocessor may typically have a rather small RAM (e.g., 2 K bytes or less) which means that a little amount of RAM (i.e., about 1 Kb) is available after operating system (OS) and communication capabilities are taken into consideration. However, by providing programmability from a function block engine, as described herein, that is resident in FLASH and having the functions use a common pool of RAM to hold minimal static value storage while the rest of the pool is reused by all the blocks for temporary execution space, fairly complex programs can be executed with a fixed memory allocation of about 1K of RAM. The program may simply be a list of “function” calls, as described by the function block definitions herein, which can be downloaded to a small file in FLASH. 
       FIG. 1  is a diagram showing relationship of the function block engine system  600 , computer  651  and a resulting circuit or system  652 . One may take the present function block engine system  600 , perhaps on a memory medium (e.g., disk, stick or the like) to store and/or load it into a memory of an operating system such as that of a personal computer  651 . One may design a circuit or system  652 , for example, a controller, with the function block engine system  600 . That circuit or system  652  may be put into a memory, for instance, in microcode, or another code, manner or mode. The memory with the system  652  may be tied in with an operating system to provide the activity of a controller having the connections with the hardware or other to be controlled and monitored based on the function block designed system  652 . 
       FIGS. 2-8  show an operation for designing simple example system  652  with the function block engine system  600 . This operation may be implemented in a system designer and simulator on a personal computer  651  with software such as, for example, “Microsoft Windows XP Professional™”. One may have a screen like that shown in  FIG. 2 . A mouse may be used to move an arrow  611  to click on “controller” and then on “configure” of the tool bar  612 . Then one may, for example, click and drag out a function block  601  entitled “Timeset” from function block source area  602  into an area  603  of a display screen with the mouse arrow  611 . Even though a function block  601 , for instance, may be dragged from area  203  to area  603 , the source  601  of the function block would remain in area  602 . Then one may drag a Limit  604  from area  602  to area  603 . One may place the mouse arrow  611  on an output terminal  605  of block  601  and drag a connection  606  to an input terminal  607  of limit  604 . An add function block  608  may be dragged from area  602  to area  603 . A network variable input block  609  may be dragged with the mouse arrow  611  into area  603 . A multiply function block  610  may be dragged from area  602  to area  603 . The mouse arrow  611  may be placed and clicked on a terminal  613  of block  609  and a line  614  may be dragged from terminal  613  to a terminal  615  of function block  610  to make a connection between block  610  and input  609 . In a similar manner a line  616  may be dragged from an output terminal  617  of block  610  to an input terminal  618  of block  608 . Also, a connection may be made with a line  619  from an output terminal  621  of limit block  604  to an input terminal  622  of the add block  608 . The add function block  608  may add input values at terminals  618  and  622  to result in a sum at an output terminal  623  of block  608 . The output at terminal  623  may be provided to an input terminal  624  of another limit function block  625  with a line  626 . The source of limit function block  625  may be the same as that for limit function block  604  which is from area  602 . To check the inputs of add function block  608 , one may right click the mouse and click on edit to get a dialogue box that shows the inputs which may changed to one or more parameters with values placed in them in lieu of inputs to the add function block  608 . The same may be done for the multiply function block  610  where one input is replaced with a parameter of four which can be multiplied with a value at input at  615  to get a result at terminal  617 . Also, other things, such as function block names, may be changed in this right-clicked edit dialogue box. 
     The circuit or system design with function blocks in area  603  may continue on to another page as shown in the tool bar  612 . The pages may be relabeled, for example, as page  1  was relabeled ad ADD 1  at place  626  and page  2  was relabeled as ADD 2  at place  627 . The circuit or system may be continued on to the next page ADD 2  with a TAG connection block  628 , which can be dragged with the arrow  611  from the block source area  602  to area  603 . An output terminal  629  of block  625  may be connected with a line  631  dragged out with arrow  611  from terminal  629  to a terminal  632  of tag block  628 . 
       FIG. 3  shows a continuation of the circuit or system from page ADD 1  to page ADD 2 . Tag  628  may be a continuation of line  631  via input terminal  632  and an output terminal  633  of tag  628  in  FIG. 3 . A square root function block  634  may be dragged from area  602  to area  603  of the display. The line  631  connection may be dragged with the arrow  611  from terminal  633  to an input terminal  635  of the square root function block  634 . A network variable output  636  may be dragged from area  602  into area  603  of the display with the mouse arrow  611 . A connection line  637  may be dragged from an output terminal  638  of block  634  to a terminal  639  of output block  636 . 
     The ADD 1   626  and ADD  627  pages may themselves be placed into individual function blocks with their respective inputs and outputs. The block of pages  626  and  627  may be placed into one function block. If there are other function blocks having a number of pages of circuits made from various function blocks, they also may be combined into one function block. These one function blocks might be interconnected and also combined into still another one function block. This hierarchical progression of function blocks being combined may continue until an entire system of a design is in one block, such as an aircraft instrumentation, industrial plant, HVAC or some other kind of controller. The resulting function block might be treated as a black box in some instances. 
       FIG. 4  shows a list of function blocks and terminals in area  602  of the display that may be selected for developing various kinds of designs. The list is not inclusive in that other function blocks and terminals may be added. 
       FIGS. 5 and 6  show the circuits of  FIGS. 2 and 3 , respectively, in a simulate mode which may be selected by clicking on “controller” of the tool bar  612  with the mouse arrow  611 . Then “simulate” may be clicked on to put the designed circuit into an operational-like scenario. The label “watch” on the tool bar  612  may be clicked on to get the watch dialogue box  641 . The loops and outputs along with their respective values may be listed in box  641 . Also, values for each increment of time may be provided at the various output terminals of the function blocks. For example, a value of “25” is shown at the output terminal  621  of the limit function block  604 . Units may be of time, magnitudes, or some other kind of measurement. The circuit or system, on pages ADD 1   626  and ADD 2   627  indicated on the tool bar  612 , may include analog, digital or a combination of digital and analog function blocks. A simulation may run for various inputs may be recorded in a table  642  as shown in  FIG. 7  and plotted as shown in a graph  643  of  FIG. 8 . Graph  643  shows magnitudes for various outputs versus time. 
       FIG. 9  shows a simulation mode of a somewhat intricate circuit  644  of function blocks. Tool bar  612  appears to show that this circuit  644  is one of four pages  645 ,  646 ,  647 , and  648  of a larger combination of function blocks interconnected via tag connections  628 . 
       FIG. 10  shows a portion of the layout of the circuit in  FIG. 3 , but with a dialogue box  649  showing the inputs and output of the add function block  608 , as discussed herein. 
     An illustrative example resulting from the present function block engine system may be a VAV (variable air volume) system used for reducing the air quantity under periods of limited or no occupancy and saves both energy of air delivery and the energy involved in the heating/cooling the air. The present VAV system has an ability to have high resolution of air flow and the accurate control to an air setpoint, especially at low flow volume. The VAV air flow calibration process or field balancing is a very important part of the product delivery that allows an HVAC balancer to measure the flow very accurately and max flow and min flow and enter an adjustment to the VAV control calibration. At the high end of accuracy and resolution, ten point curves detailing the air pressure (proportional to voltage) in relation to velocity air flow may be customized and developed for the manufacture of flow pickup devices. There appears to be a need to develop an approach that can incorporate the minimum flow and calibration information in addition to the ease required for an HVAC balancer. 
     Advantages of the system may include the following. Function block architecture allows flexibility to accommodate new architectures, hardware, or changes in HVAC equipment due to improvements in sequences, control strategies, or communication to achieve balancing. A modular system gives ease of understanding. There is efficient use of resources—vastly simpler for balancing algorithm to implement resulting in savings of time and hardware/software resources. It takes advantage of a high point calibration technique in the present assignee&#39;s U.S. Pat. Nos. 6,549,826 and 5,479,812. This technique appears as being recognized in industry as leading in flow accuracy and low cost. The present invention facilitates this technique in a much more simple and elegant way. 
     The system may result in an ability to use multi-platform, multi-purpose programmable controller algorithms that can be adapted to, combined, merged, and/or synthesized with multi-protocols (TCP/IP/Ethernet, BACnet™, LON™ and so on), other applications (RTU, CVAHU, UV, FCU, VAVAHU, and so forth), internet (T7350H, XL15B, webserver) application (HVAC, boiler control per U.S. Pat. No. 6,536,678 owned by the present assignee) and industry (security, test, OEM, and so forth). 
     The system may address the balancing issues by using software blocks to represent actual control software and connections in an HVAC application control for a VAV application. Blocks used in the description of the balancing process include the VELP or velocity pressure block which converts a velocity pressure value to a velocity, the Comparison block which takes two values and compares them to each other and outputs a true if it is matching, the conjunction block which does a logical AND and a comparison of logical outputs and sets the output to true, and Override function which picks the highest priority input and a ratio box which allows multi-segment performance contouring of the resultant function for flow. The system may solve both the ten point curve calibration issue for very accurate and non-linear flow pick-up equations and also allow for the two point balancing flow capability required for quick and accurate use in the balancing process. 
     The system has a block of input ten point linearization, zeroing and calibration through coordination of flow velocity and balancing calibration blocks. With respect to air flow detection and measurement, following the flow signal, first, the flow sensor output voltage is amplified by a fixed-gain preamplifier, and then by a programmable scale amplifier. During Factory Test, the gain and offset required to correct the gain and offset of individual sensors may be stored in a hardware adjustable gain circuit. The A/D converter integral with the micro-processor may convert the flow sensor voltage into counts that that are inversely proportional to the flow sensor voltage. During Factory calibration, the reference voltage may be tested and used to store the correct calibration in a separate digital memory or hardware circuit. A ten point curve in memory may be used to adjust the linearization of the velocity pressure based on factory calibration of one or two specific pressures, including zero. The flow sensor may be zero corrected in the HVAC control application before use in the final control circuit. The ZeroFlowCorrection value may be subtracted from the flow pressure in the control application. 
     The flow sensor voltage may be linearized and converted to feet per minute by applying a linearization curve stored in EEPROM (nciVoltsCal and nciFlowCal). Between stored curve points, linear interpolation may be used. The linearization curve may be loaded into EEPROM using a management tool. The curve may take into account the sensor variations (using measurements made in the factory and stored in EEPROM in nciFactoryCal) and the pickup device curve (unique for each model and duct size). 
     The flow sensor results may be further corrected by field (job site) measurements. Using a management tool, three actual measured and three apparent values of flow may be entered into EEPROM (nciFld3PtCal). Then the linearized flow may be corrected to the functional flow by the three point curve using linear interpolation between the points. 
     The air flow sensing approach may be noted. Referring to  FIG. 11  showing a flow sensor block diagram, first, the flow sensor  11  output voltage may be amplified by a fixed gain preamplifier  12 , and then by a programmable scale amplifier  13 . During Factory Test, the gain  15  and offset  14  required to correct the gain and offset of individual sensors may be stored in EEPROM (FlowGainCal and FlowOffsetCal). At application restart and once a second when Mode is Factory Test, the scale amplifier hardware register may be loaded with the stored gain and offset from EEPROM. The A/D converter  16  may convert the flow sensor voltage into counts that are inversely proportional to the flow sensor voltage. The A/D converter  16  may also convert a reference voltage into counts. During Factory Test, the reference voltage may be measured and stored in EEPROM (HighCalVolts  19 ). The two raw counts  17 ,  21  and HighCalVolts  19  may be combined using a one point reference fixed slope linear equation to calculate the flow sensor voltage (FlowVolts)  22 . The latter may occur in the averaging/filtering module  18 . 
     The flow sensor may be zero corrected before linearization. The ZeroFlowCorrection value  27  may be subtracted from the flow sensor before or after the flow sensor linearization  23 . The flow sensor voltage  22  may be linearized and converted to feet per minute by applying a linearization curve stored in EEPROM (nciVoltsCal and nciFlowCal). Between stored curve points, linear interpolation may be used. The linearization curve may be loaded into EEPROM using a management tool. The curve may take into account the sensor variations (using measurements made in the factory and stored in EEPROM in nciFactoryCal) and the pickup device curve (unique for each model and duct size). 
     The flow sensor results may be further corrected by field (job site) measurements. Using a management tool, three actual measured and three apparent values of flow may be entered into EEPROM (nciFld3PtCal)—balancing calibration. Then the linearized flow may be corrected to the functional flow by the three point curve using linear interpolation between the points. There may be more (e.g., 10) or less (e.g., 2) measured and apparent values of flow along with a corresponding multi-point (e.g., 10, 2 or other) curve. It may be noted that FlowOffsetCal and FlowGainCal may be written from the EEPROM to the hardware registers at application_restart, and when Mode is Factory Test. 
       FIG. 11  is a block diagram of the present flow velocity calibration and balancing system  10 . Flow sensor  11  may be of a variable air volume (VAV) module. The sensor  11  may detect flow with a pair of pneumatic tubes in an air flow vent, duct or channel. The output may be a differential pair of signals that go to a preamplifier  12 . The output of amplifier  12  may go to a scale amplifier  13 , A flow offset signal  14  and a gain offset signal  15  may also be input to amplifier  13  to adjust the flow pressure signal relative to flow and gain offsets, respectively. The adjusted output of the scale amplifier  13  may go to an analog-to-digital converter  16 . The output of converter  16  may be a raw flow signal  17  in counts which is input to an averaging and filtering module  18 . Module  18  may have a high calibration voltage signal  19  and raw high calibration volts in terms of counts signal  21  input to module  18 . The output of module  18  may be a signal  22  in volts indicating an amount of flow. Signal  22  may go to an input of a linearization module  23  which provides an output signal  25  that proportionally represents uncorrected flow in terms of feet per minute (fpm). Input  24  for flow calibration volts and flow calibration in fpm may be input to module  23 . 
     The output  25  of module  23  may go to a summer  26  to be summed with a signal  27  of zero flow correction. The sum of signals  25  and  27  may go as an input signal  28  to a field flow correction module  29 . A balancing calibration signal  31  may be input to module  29 . A signal  23  from module  29  may be a flow sensor output in terms of fpm. Signal  32  may go to a calculate volume flow module  33 . There may be an input signal  34  containing duct area in, for example, square feet (f^2). The calculation of the inputs  32  and  34  may result in output signals  35  and  36  representing box flow and box flow out, respectively, in terms of cfm. 
       FIG. 12  shows the air flow sensor  11  with tubes  37  and  38  having ends situated in a duct  39  for measuring a flow of air  41  going through duct  39 . Incidentally, the cross-section shape of duct  39  may be square, rectangular, round or another shape. The ends of tubes  37  and  38  may be situated upstream and downstream relative to each other in duct  39 . As air  41  is flowing from left to right in the Figure, the end of tube  37  may sense a positive pressure (P + ) and the end of tube  38  may sense a negative pressure (P − ). A delta pressure (ΔP) which is a difference of a P +  and P −  may be converted into a voltage where the voltage is proportional to the delta pressure. This voltage may be a signal  42  that goes to a variable air volume (VAV) module  43 . Signal  42  may be processed between the air flow sensor  11  and VAV control module  43  or within module  43 . An output signal  44  may be digital and provided to a damper actuator  45  for controlling a damper  46 . Damper  46  may be incrementally closed or opened to regulate the air flow in terms of volume (cfm) through duct  39 . 
     The following is an explanation of a Piranha™ simulator balance chart. The process may be shown in a block diagram. The flow sensor input “Flow Sensor” is a valve that comes from the A/D hardware after it has been linearized to an engineering unit in inches water (inw). In a VAV system, the pressure sensor is converted to a flow valve by use of the following equation.
 
flow= K (Δ P −offset) 1/2 , and
 
 vel =flow/area;
 
where K=Flow coefficient (K-Factor) representing the actual flow in ft 3 /min corresponding to a velocity pressure sensor output of 1″ w.g., ΔP=flow sensor output pressure in inches water gauge (in W), Offset=a correction pressure (in W) to adjust for zero, Flow=airflow in ft 3 /min (CFM), vel=flow velocity in ft/min; and
 
area=duct area in ft 2 . The K-factor is often used in terminal unit controls to calculate actual airflow.
 
     Setting the autoSetOffset to a non-zero number results in the current pressure being stored as an offset that will be subtracted from the current pressure. The Offsetcan be cleared by setting the clear offset to a non-zero number. If the pressure is within 0.002425 in W of zero (approximately 50 fpm) then set the output flow and velocity to zero. 
     Consistent units should to be used. For example, if p is 1.02 inches water column, and if the offset is 0.02 inches water column, K is 1015, and the area is 0.54 square feet (10 inch diameter), then the flow will be 1015 feet per minute, and the velocity will be 1879 feet per minute. 
     In the preceding equation, flow is typically measured in cfm (cubic feet per minute) and ΔP is typically measured in inches water column (inw). The airflow is a pressure typically measured in inches water column. The flow sensor creates a voltage that is proportional to the pressure, V α P or V=(constant)×P. 
     After the conversion from voltage to engineering units, the input is fed from the flow sensor of the VELP function block. The VELP function block converts the pressure in inw and converts it to a flow rate taking into account the flow zero value “offset”. The value may be calculated as flow (in cfm)=K(ΔP−offset) 1/2 . 
       FIG. 13  is a more detailed block diagram of the processing of signals for system  10 . As in  FIGS. 11 and 12 , flow sensor  11  may provide a low voltage signal  42  where the voltage is proportional to the difference of sensed pressures from tubes  37  and  38 . The output signal  42  may go to an amplifier/conditioner module  47 . Module  47  may consist of preamp  12  and scale amp  13 . Also, module  47  may have offset and gain signals  14  and  15  as inputs. An output  48  in volts may be provided by module  47  to the A/D converter  16 . A sample rate input  49  may be provided to converter  16 . An output  17  of counts may go to an averaging module  51  that provides averaging of signal  17 . An average counts signal  52  may go to a digital filter module  53 . A filter rate  54  may be input to digital filter  53 . An output signal  55  of filtered average counts may be input to a count linearization module  56 . Linearization by module  56  may be based on a linearization table  57  input to module  56 . An output  58  of linearized counts may go to an engineering units (e.u.) module  59 . Information for module  59  to provide an analog signal  62  in inw (inches of water) from linearized counts or units may be provided by an e.u. lookup table  61 . Signal  61  may go to a public variable storage location analog value module  63 . Alternatively, connections  64  or  65  may provide and/or receive signals between module  63  and microprocessor  66  or  67 , respectively. Microprocessor  66  may be bidirectionally connected to an Echelon™ Neuron™ processor  68 . 
     Microprocessor  67  may be bidirectionally connected to a BACnet™ processor  69 . Processor  68  may be bidirectionally connected to a LonWorks™ bus  71 . Processor  69  may be bidirectionally connected to a BACnet™ bus  72 . Buses  71  and  72  may provide similar information as that of signal  62  ultimately from other sensors. 
     Module  63  may provide output signals  73  to an operating system module  75  and receive signals  74  from module  75 . Operating system module  75  may provide signals  76  to a balancing block implementation in a function block engine module  80 . Module  75  may receive signals  77  from module  80 . 
     Module  63  may include an input/output processor module  81  that receives sensor inputs and provides actuator outputs. A sensor input module  82  may be connected to module  81 . An actuator output module  83  may be connected to module  81 . Inputs  84 ,  85  and  86  may receive resistive signals, 4-20 mA signals and digital 24 VAC signals, respectively. Other kinds of signals may be received by the inputs. Outputs  87 ,  88 ,  89  and  92  may provide signals for dampers, valves, and so forth. Outputs  87  may provide 4-20 mA signals. Output  88  may be a floating actuation of plus and minus signals of about 24 VAC to provide good resolution positioning of a damper at various angles relative to an air flow. Output  89  may provide digital relay signals and output  91  may be a two-wire PWM (pulse width modulated) signals.  FIG. 14  is a diagram of modules  81 ,  82  and  83 . 
       FIG. 15  shows a linearization table  57 . It shows examples of linearization counts in and counts out for several pressures. The right column shows, for information, the subject pressures in Pascals. The latter information is not necessarily provided in the table.  FIG. 16  shows the e.u. lookup table  61 . It provides an equivalent inches of water output on the ordinate axis versus the linearized units input on the abscissa axis. The relationship appears to be linear. 
       FIG. 17  shows a velocity pressure (VELP) function block  92 . It may provide a flow  96  from pressure kFactor and area. The inputs may include pressure  93 , auto set offset and clear offset. The other outputs  97  and  98  may include offset and velocity, respectfully. Other inputs  99  and  100  may include area and kFactor, respectively. 
       FIGS. 18 and 19  show a table of analog inputs and a table of outputs for the VELP module  92 , respectively. Table  102  has columns showing the input name, Cfg, low and high range, input value and description for each of the inputs  93 ,  94 ,  95 ,  99  and  101 . Table  103  has columns showing output name, Cfg, low and high range, and description for each of the outputs  96 ,  97  and  98 . 
       FIG. 20  is a list of network variables (NVs) used in the function block engine for balancing. The regular single duct VAV balancing may use the NV names. 
       FIG. 21  is a diagram of a VAV balancing overview. Block  104  indicates that a control specialist may assign an address identification (ID) to a controller, and then download the controller using Evision™ or LonSpec™ to commission. The next step is an installation test question in diamond  105  of whether the control works as desired. If the answer is “no”, then one may return to block  104 . If the answer is “yes”, then one may go to a block  106  where a balancer calibrates minimum and maximum settings through Evision™ or LonSpec™ zero calibration and balancing procedure. Other products besides Evision™ or LonSpec™ may be used in blocks  104  and  105 . One may go to an air flow test question of diamond  107  which asks whether the air control operates properly. If the answer is “yes”, then the installation as noted in circle  108  may be complete. If the answer is “no”, then one may verify the configuration and retest items of the previous blocks as indicated in block  109 . After doing such verification one or more times, without success, then one may return the air control system as indicated in circle  110 . 
       FIG. 22  is an overview block diagram of the present system  10  with its interaction with a microcontroller. A central item may be a micro controller module  111 . Microcontroller module  111  may have one or more processors. Velocity pressure sensing input module  112  may be connected to microcontroller  111 . Universal analog/digital inputs module  113  may be connected to module  111 . An interface module  114 , having a wall module interface  115  and a serial communications interface (RF)  116 , may be connected to module  111 . Another interface module  117 , having a LonWorks™ ShortStack™ communications interface  118  and an RS485 MS/TP BACnet™ interface  119  may be connected to module  111 . A discrete inputs module  121  may be connected to module  111 . A monitor  122  may be connected to module  111 . A power supply module  123  may be connected to module  111 . An analog outputs module  124  and a triac outputs module  125  may be connected to module  111 . Other modules, as desired, may be provided and connected to microcontroller module  111 . 
       FIG. 23  shows a schematic of example portions of a VAV duct system and connection with an air handler system. An air handler unit (AHU)  131  may bring in fresh air at intake  132 , system return air at intake  133 , and put out exhaust air at outlet  134 . A fan  135  may push supply air  137  from AHU  131  into duct  136 . Supply air  137  may be set to have a 55 degree temperature. The temperature of the air may be affected by cooler  138  and heater  139 . Air  137  may be routed from the primary duct  136  to secondary ducts  141  and  142 . Ducts  141  may convey air  137  various zones of a building. Duct  141  may convey air  137  into a zone through a VAV  143 , a damper  144  and a heater  145 . 
     In zone  146 , air  137  may enter from duct  142  into smaller ducts  152 . The air  137  may enter the space of zone  146  through diffusers  153  at the ends of ducts  152 , respectively. In zone  14 G, there may be return vents and ducts for returning the air  137  back to the AHU  131  at the return opening  133 . Similar air delivery and return may apply the other zones of ducts  141 . A control  154  for VAV  142  may be connected to one or more temperature sensors  155 . 
     AHU  131  may have a fresh air intake damper  146 , a return air damper  147  and an exhaust air damper  148 . If the fresh air intake damper is 100 percent open, then the return air damper  147  would 100 percent closed and the exhaust air damper  148  would be 100 percent open. If the fresh air damper  146  is partially closed, then return air damper  147  may be partially open and exhaust air damper  148  may be partially closed. If fresh air damper  132  is completely closed, then damper  147  may be completely open and damper  148  may be completely closed. However, the fresh air damper may be generally open because of certain minimum fresh air requirements. One cannot just add up percentages of openness and closure to determine a relationship among the dampers because the amount of air flow according to the percentage of openness and closure of a damper may be generally nonlinear. 
     Ducts  141  may have corresponding VAVs  151 , controls and sensors for their respective zones. The air  137  just coming out of the AHU  131  may be at 6000 cfm. A 1000 cfm may go to each of the ducts  141  and 2000 cfm to duct  142 . Or each duct may receive a different amount of cfm than another duct. However, the 1000 cfm per duct  141  may be used for illustrative simplicity. 
     A display of the system  10  may indicate a certain amount of flow through a duct or ducts  137  and  152 . For example, the display may indicate 2000 cfm. However, the measured amount may, for instance, be 1503 cfm.  FIG. 24  shows a graph  161 . The ordinate coordinate shows the displayed cfm and the abscissa coordinate shows the measure cfm. Plot  162  represents data before balancing and plot  163  represents data after balancing. The data is supposed data. The difference  164  between the plots  162  and  163  may be characterized by a “K” factor referred to as “kFactor”. Line  165  represents the minimum flow. The airflow may be measured at the diffusers  153 , for example in  FIG. 23 , with a hood  166 . Opening  167  may be put up against the surface around the diffusers so that all of the air goes through the hood including the cfm sensor portion  168 . The air flow may exit out of opening  169 . The cfm of the air flow may be read on a meter  171 . The hood may be held up against the diffuser vent with handles  172 . 
     Graph  175  of  FIG. 26  shows a relationship between cfm of an air flow and the sensed delta pressure in inches of water. The relationship of the flow rate may be represented by “Flow=k(ΔP)^½.” The curve  176  represents that relationship. An area  177  of air flow measurement may be difficult to measure and/or monitor by related art systems. The system may provide a good resolution to sensed measurements in area  177  of curve  176 . 
       FIG. 27  is an overview diagram of a balancing block  181 . It shows inputs of air flow pressure  182 , balancing mode command  183 , duct area  184 , maximum flow speed  185  and minimum flow speed  186 . Block  181  has an actuator output  187 . 
       FIG. 28  shows portions of a balancing system  190  and their times for activity among them. For signals at inputs  191  to reach the function block and balancing system  193  via the conditioning  192  of the signals may take about 0.1 second. The time for the block and system  193  to process the received signals may be about one second. To provide signals from the block and system  193  to the outputs  194  may take about 0.1 second. The interaction of the block and system  193  and storage or memory  195  may be significantly faster than 0.1 second. 
       FIG. 29  is a diagram of a function block system  200  which may have application to the balancing or other system. Built-in function execute  201  may be connected to operating system schedule  203 , loop RAM/FLASH  205 , built-in functions configuration  206 , input converter  207 , and output converter  211 . Function block engine  202  may be connected to operating system schedule  203 , block execution list  204 , and loop RAM/FLASH  205 . Operating system schedule  203  is connected to input converter  207  and output converter  211 . Input converter  207  is connected to loop RAM/FLASH  205 , input configuration  208 , physical input/outputs  209 , and network input/outputs  210 . Output converter  211  is connected to output configuration  212  and output converter  213 . Output converter  213  is connected to physical input/outputs  209  and network input/outputs  210 . 
       FIG. 30  is a summary VAV block flow diagram  215 . A convert physical/inputs network  216  may be connected to a function block order list  217 . The function block order list  217  may be connected to a convert physical/outputs network  218  and to a loop RAM/FLASH  219 . 
       FIG. 31  is a block diagram of an illustrative programmable HVAC controller. The illustrative HVAC controller may be a programmable thermostat, or may be separate from the thermostat. In either case, the HVAC controller may provide one or more control signals that effect the operation of the HVAC system. 
     The illustrative HVAC controller may include a microcontroller  330  having a non-volatile memory  334  and a random-access memory (RAM)  336 . Additionally, the illustrative microcontroller  330  may include a central-processing unit (CPU)  332 , analog-to-digital converters (A/D)  338 , input/outputs (I/O)  342 , and a clock  340  or timer. The illustrative microcontroller  330  may include more or less than these illustrative components, depending on the circumstances. As illustrated, the aforementioned components may be provided internal to the microcontroller  330  without the need for any external components, but this is not required. 
     In some cases, the least expensive form of processor is a microcontroller. Microcontrollers typically contain all the memory  334  and  336  and I/O  342  interfaces, integrated on a single chip or device (e.g., microcontroller) without the need for external components. As noted above, one advantage of using a microcontroller  330  is the low cost when compared to the cost of a typical microprocessor. Additionally, microcontrollers  330  may be designed for specific tasks, such as HVAC tasks, which can help simplify the controller and reduce the number of parts needed, thereby further reducing the cost. While the use of a microcontroller may have some benefits, it is contemplated that the present system may be used in conjunction with a microprocessor or any other suitable controller, as desired. 
     In the illustrative microcontroller  330 , the non-volatile memory  334  may be FLASH memory. However, it is contemplated that the non-volatile memory  334  may be Read Only Memory (ROM), programmable Read Only Memory (PROM), Electrically Erasable Programmable Read Only Memory (EEPROM), Random Access Memory (RAM) with a battery back-up, or any other suitable non-volatile memory  334 , as desired. In the illustrative example, the amount of FLASH memory may be less than 100 Kb. In one case, the amount of FLASH memory may be about 60 Kb; however, it is contemplated that any amount of FLASH may be used depending on the requirements per application. 
     In some illustrative examples, the non-volatile memory  334  may be configured to have at least two portions including a first portion that is the equivalent of ROM and a second portion that is the equivalent of EEPROM. The first portion of non-volatile memory  334 , often called the firmware portion, may be used to store at least in part one or more execution modules, such as, for example, a function block engine. In some cases, this portion of the non-volatile memory  334  may be programmed at the factory, and not subsequently changed. Additionally, the one or more execution modules (e.g., function block engine) stored in the firmware portion may execute, in some cases, one or more function blocks also stored in the non-volatile memory  334 . 
     The second portion of the non-volatile memory  334  may include application configuration modules or data, including for example, a block execution list. In some cases, the non-volatile memory  334  in this second portion may be divided further to contain segments of data. This portion of the non-volatile memory  334  may be capable of being reconfigured post factory, such as during installation of the controller into an HVAC system in a building or structure. In other words, in some illustrative examples, the second portion of the non-volatile memory may be field programmable. In some cases, the amount of non-volatile memory  334  allotted for the second portion may be about 5 Kb. However, it is contemplated that any amount of field programmable memory may be provided, as desired. 
     It is further contemplated that the non-volatile memory  334  may also have a portion dedicated for the storage of constant values. This portion of memory may be provided in, for example, the firmware portion and/or the field programmable portion, as desired. 
     In the illustrative microcontroller  330 , the RAM  336  may be used for variable storage. In some cases, the RAM  336  may be a relatively small repository for exchanging information during execution of the one or more programs or subroutines stored in the non-volatile memory  334 . The RAM  336  may also be used for hosting the operating system of the microcontroller  330  and/or the communication capabilities, such as external interfaces. In the illustrative microcontroller  330 , the amount of RAM  336  included may be about 5 Kb or less, 2 Kb or less, or any other suitable amount of RAM. In some cases, the operating system and communication capabilities may consume about 1 Kb of RAM  336 , leaving about 1 Kb for other functions, such as storing variables and/or other data for the one or more programs. 
     The CPU  332  for the illustrative microcontroller  330  may interpret and execute instructions, and may control other parts of the microcontroller  330  as desired. In some cases, the CPU  332  may include a control unit and an arithmetic-logic unit contained on a chip. The clock  340  can provide a steady stream of timed pulses for the microcontroller  330 , which may be used, for example, as the internal timing device of the microcontroller  330  upon which operations may depend. The I/Os  342  can transfer data to and from the microcontroller  330  and an external component. In some cases, for each input, there may be a corresponding output process and vice versa. The A/D  338  converter can provide transformations of an analog input into a digital input format helping to enable the microprocessor to be able to read and interpret analog input signals. In some cases, a D/A converter may also be provided to allow digital signals to be provided as analog outputs, if desired. 
       FIG. 32  is a schematic diagram of an illustrative application framework of a programmable controller  350 . The illustrative controller  350  includes one or more execution modules, one or more application configuration modules, and a parameter and variable storage space. The execution modules, as illustrated by the circles in  FIG. 32 , can include a function block engine  352 , a built-in function execute module  370 , an input convert module  378 , a network convert module  376 , and an output convert module  380 . The application configuration modules, as illustrated by the cylinders, can include a block execution list  354 , a built-in functions configuration  360 , an input configuration  372 , a network interface configuration  374 , and an output configuration  384 . The parameter and variable storage space can include a loop RAM space  356  and a loop flash constant space  358 . Additionally, the illustrative controller  350  may include one or more external interfaces for communication capabilities, including a local input  362 , a network file transfer  366 , a network object in and out  364 , and a local output  382 . In some cases, the controller  350  may also include an operating system (OS) task scheduler  368 . 
     The one or more execution modules can be resident in the non-volatile memory of the microcontroller  350 , such as in FLASH memory. More specifically, in some cases, the one or more execution modules may be resident in the ROM equivalent or firmware portion of the non-volatile memory. At least one of the execution modules may include one or more programs, some of the one or more programs relating to the operation of the HVAC system. The one or more programs may include a set of sub-routines that the one or more execution modules can sequentially execute. The one or more execution modules may execute the one or more programs from the non-volatile memory. 
     The one or more application configuration modules can also be resident in the non-volatile memory, such as the FLASH memory, of the microcontroller  350 . More specifically, the one or more application configuration modules can be resident in the EEPROM equivalent or the field programmable portion of the non-volatile memory. These modules can be pre-configured for standard HVAC applications or can be configured for custom HVAC applications, as desired. Additionally, the one or more application configuration modules can be field programmable. For example, in some cases, the one or more application configuration modules may be programmed and configured either during or after the installation of the controller into a HVAC system. 
     In some cases, the one or more application configuration modules can include a block execution list  354 . The configuration of the block execution list  354  can direct the execution of the one or more execution modules (e.g., function blocks). In some cases, this configuration can be determined by the user or the installer. In some cases, a programming tool may be used that allows the installer to select the appropriate function blocks to create a custom block execution list  354 , along with the appropriate configurations, to perform specific HVAC applications. This may help the one or more application configuration modules to be configured on a job-by-job basis, which in turn, can direct the execution of the execution modules on a job-by-job basis. In some cases, the one or more application configuration modules can include parameters or references that point to a location in memory for data, such as to the parameter and variable storage space. 
     The parameter and variable storage space may be provided in the controller  350  for the one or more execution modules and/or one or more application configuration modules to reference data or values to and from storage space. In an illustrative example, the variable parameter storage space, or loop RAM space  356 , may be resident in RAM. This storage space can be used for the temporary storage of variables or parameters, such as function block outputs and/or temporary values from inputs, either local inputs or network inputs, of the controller  350 . 
     Also, in the illustrative example, the constant parameter storage space, or loop flash constants  358 , may be a storage space for storing constant values determined by the programmer or user. This storage space may be resident in non-volatile memory, such as the FLASH memory. Certain set points and operational parameters may be designated as constant parameter values selected by the application designer, installer, or user, and may be stored in the loop flash constants  358  storage space, if desired. 
     The HVAC controller  350  may also include external interfaces, such as local inputs  362  and local outputs  382 . The local inputs  362  may be stored according to the input configuration  372  module executed by the input convert module  378 . These modules may direct to storage the input value so that it can be used by other execution modules, such as the function block engine  352 . The local outputs  382  may be configured according to the output configuration  384  as executed by the output convert module  380 . This may output the value or data to an external HVAC component, such as a damper, thermostat, HVAC controller, or any other HVAC component as desired. 
     The OS task scheduler  368  may determine the operation and execution of the execution modules within the HVAC controller  350 . For example, the execution modules may be executed in the following order: discrete inputs; including input convert  378  and network convert  376 ; built-in function execution  360 ; function block execution  352 ; physical output processing  380 ; and finally network output processing  376 . However, it is contemplated that any suitable order may be used as desired. 
       FIG. 33  is a schematic diagram of some illustrative application configuration modules of  FIG. 32 , including an illustrative block execution list  354 . As indicated above, the block execution list  354  may be resident in non-volatile memory, such as FLASH memory, and more specifically the field programmable portion of the FLASH memory, if desired. The illustrative block execution list  354  includes a listing of one or more function blocks  355  and  357 , and is used to direct which function blocks and the order of execution of the function blocks, executed by the function block engine  352  according to its configuration. 
     The block execution list  354  may be programmed at the factory or by the user or the installer, to configure the order and type of function blocks  355  and  357  that are to be executed for the particular application. In some cases, the user or installer can have a programming tool that allows the user or installer to select the appropriate function blocks  355  and  357  and configuration to perform the desired tasks for the particular application. Thus, in some examples, the block execution list  354  configuration may be provided on a job-by-job basis for the controller. In some cases, this can allow the block execution list  354  to be programmed and configured in the field and changed depending on the desired application and function of the controller. 
     In the illustrative example, the Function blocks  355  and  357  are modules that perform a specific task by reading inputs, operating on them, and outputting one or more values. The function block  355  and  357  can be defined according to the block execution list  354 , which can be programmed by the factory, user, installer, or application designer. In the illustrative example, function blocks  355  and  357  may be classified into six categories: analog function blocks, logic function blocks, math function blocks, control function blocks, zone control function blocks, and data function blocks. 
     The function blocks  355  and  357  may perform higher level functions, such as higher level functions for HVAC operations. Additionally, the controller may include some more generic function blocks for performing some basic applications, but, in many cases, these may be combined with other function blocks to perform higher level HVAC application. 
     Referring back to  FIG. 33 , function blocks  355  and  357  may include a number of function calls or pointers to particular locations in memory. In the illustrative example, each function block  355  and  357  may include a function block type  355   a  and  357   a , and a number of parameter or references  355   b - m  and  357   b - m . The references and parameter  355   b - m  and  357   b - m  may point to variables or constants that are stored in the parameter and variable storage space, such as in either the function block variable space  356  or the function block constant space  358 . Additionally, in some cases, the reference and parameters  355   b - m  and  357   b - m  may relate to other function block outputs, inputs (either local or network), or pointers to any other data, as desired. 
     In one illustrative example, each function block may be about 22 bytes long. Each function block may include the function block type  355   a  and  357   a , which can be one byte. Each function block can also include nine references or variables  355   e - m  and  357   e - m , each reference or variable being allocated 2 byte WORD increments, totaling 18 bytes. Also, each function block  355  and  357  may include three parameter or configurations  355   b - d  and  357   b - d , each being one byte, totaling 3 bytes. However, these sizes are merely for illustrative purposes and it is not meant to be limiting in any way. 
     It is contemplated that any size function blocks  355  and  357  may be used, and/or any number or size of function block types  355   a  and  357   a , references or variables  355   e - m  and  357   e - m , and parameters or configurations  355   b - d  and  357   b - d . Furthermore, it is contemplated that the order may be the function block type  355   a  and  357   a , then one parameter  355   b  and  357   b , then the nine references  355   e - m  and  357   e - m , and then the two remaining parameters  355   c - d  and  357   c - d . More generally, it is contemplated that the function blocks  355  and  357  may be configured in any order and have any number of references and parameters, as desired. 
     The function block type  355   a  and  357   a  may be used to specify what function the function block  355  and  357  performs. Examples of functions that function block types  355   a  and  357   a  can perform may include, but are not limited to, one or more of: determining a minimum; determining a maximum; determining an average; performing a compare function; performing an analog latch function; performing a priority select function; performing a hysteretic relay function; performing a switch function; performing a select function; performing an AND/NAND function; performing an OR/NOR function; performing an exclusive OR/NOR function; performing a one shot function; performing an add function; performing a subtract function; performing a multiply function; performing a divide function; performing a square root function; performing an exponential function; performing a digital filter function; performing an enthalpy calculation function; performing a ratio function; performing a limit function; performing a reset function; performing a flow velocity calculation function; performing a proportional integral derivative (PID) function; performing a adaptive integral action (AIA) function; performing a stager/thermostat cycler function; performing a stage driver function; performing a stage driver add function; performing a rate limit function; performing a variable air volume (VAV) damper flow control function; performing an occupancy arbitrator function; performing a general set point calculator function; performing a temperature set point calculator function; performing a set temperature mode function; performing a schedule override function; performing a run time accumulate function; performing a counter function; and performing an alarm function. More generally, any suitable function may be performed by function block types  355   a  and  357   a , as desired. 
     Function block references  355   e - m  and  357   e - m  may be pointers to variables that can specify inputs, outputs and/or other data that is used by the function block  355  and  357 . These variables may include data inputs that are used by the function block  355  and  357  during execution. In the illustrative example, there may be a number of variable type references that may each have a unique mapping to a memory class. In the illustrative example shown in  FIG. 33 , there are nine different types of variables: input, parameter, input/parameter, parameter/input, output floating point number, nonvolatile output floating point number, output digital, static floating point number, and static digital. The input variables may include an input reference for the function block  355  and  357  stored in, for example, RAM memory. The parameter variable may be a value for the function block  355  and  357  to use, which in some cases, can be stored in either RAM or FLASH memory. The input/parameter variable can be a reference to either an input or a parameter, with the default being an input and may, in some cases, be stored in either FLASH or RAM memory. The parameter/input variable can be either a parameter or an input with the default being a parameter, and in some cases, can be stored in FLASH memory. The output floating point number variable may be an output of the function block  355  and  357 , which can be called up as an input to another function blocks that is later executed. In some cases, the output floating point number variables may be stored in volatile RAM memory. The nonvolatile output floating point number variable may be an output of the function block  355  and  357 , which can be called up as an input to another function block. In some cases, nonvolatile output floating point number variables may be stored in non-volatile RAM memory so that it retains its value on a power outage. The output digital variable may be an output of the function block  355  and  357  that can be called up as an input to another function block. In some cases, the output digital variables may be stored in RAM memory. The static floating point number variable may allow a function block  355  and  357  to use floats as static RAM variables. The static digital variable may allows a function block  55  and  57  to use digitals as static RAM variables. Additionally, there may be unused references, indicating that these references/variables are unused. More generally, it is contemplated that there may be any number of variable type references, as desired. 
     The output of function blocks  355  and  357  can be stored, in some cases, in the RAM for later use by the function block engine. As indicated above, and in some cases, the outputs of a function block  355  and  357  can be used as an input reference to another function block  355  and  357 . Additionally, in some cases, outputs can be referenced to the input of the same function block  355  and  357 , when appropriate. However, if an input is referenced to its output, there may be a delay before receiving the output signal at the input of the function block (e.g., by one cycle or iteration) due to the sequential execution of the function blocks in one illustrative example. In some cases, it may take about one second for the execution of the function blocks  355  and  357 , but this should not be required. 
     The parameters  355   b - d  and  357   b - d  may include design time configuration information needed by the function block  355  and  357  to execute. For example, the parameters  355   b - d  and  357   b - d  may instruct a corresponding function block  355  and  357  on how to initialize itself. In the illustrative example, each function block  355  and  357  may have three parameters  355   b - d  and  357   b - d , each including one byte of configuration information, for this purpose. However, it is contemplated that any suitable number of parameters of any suitable size may be used, as desired. In some cases, the parameter information may be entered by the application designer, the installer in the field, or the user, as desired. The parameters  355   b - d  and  357   b - d  may be configured to apply to just one specific function block type, one specific function block instance, or multiple function blocks, depending on the application. In some cases, the parameters  355   b - d  and  357   b - d  may be stored in the function block constants storage space  358 , but this should not be required. 
     The function block variable space  356  and the function block constant space  358  may be provided in the controller. For example, the function block variable space  356 , which may change, may be resident in RAM memory of the controller. In some cases, the RAM may have a portion that is volatile and a portion that is non-volatile. In the volatile RAM, upon a power disruption, the data may be lost or reset, whereas in the non-volatile PAM, upon a power disruption, the data should be retained. Thus, data that is desirable to maintain upon a power disruption may be stored in the non-volatile RAM, while other data may be stored in the volatile RAM. 
     The function block constant space  358  may be a constant value storage space for data, such as parameters, as determined by the application designer, installer or user. The constant value storage space may be resident in non-volatile memory, such as FLASH memory. This may include certain set points and operational parameters that are designated as constant parameter values selected by the application designer at design time, by the installer, or the user. In order to change a constant parameter, and in some cases, a new function block configuration may have to be downloaded to the controller. Additionally, in some cases, a function block description, which may be available to the user, programmer, and/or installer, can provide details as to which parameters are variable and which are fixed. Providing the function block constant space  358  may help improve the efficiency of the controller by maintaining parameters and/or variables that could be used by the function blocks  355  and  357 . 
     External interfaces, such as the network input/output and local input/output may also use the function block  355  and  357  variable space to map data in and out of the controller. To input data into the controller, an input configuration  372  may be provided to properly configure the input so that the function blocks identified in the block execution list  354  may properly reference the data. In some cases, the input configuration  372  may include an input number  373   a , name  373   b , conversion  373   c , units  373   d , calibration  373   e , linearization  373   f , and references  373   g . The input reference may map the input to the function block variable space  356  resident in the RAM memory. An output configuration  384  may also be provided to configure outputs that may be mapped out of the controller. The output configuration  384  may include an output number  385   a , name  385   b , conversion  385   c , units  385   d , calibration  385   e , drive type  385   f , and references  385   g . The output reference may map data from the function block variable space  56  resident in the RAM. 
       FIG. 34  is a schematic diagram of the illustrative one or more execution modules of  FIG. 32  including the function block engine  352 . As discussed previously, the function block engine  352  may be resident in the non-volatile memory of the microcontroller, more specifically, in the firmware portion of the non-volatile memory. The function block engine  352  may include one or more programs, such as one or more HVAC application programs. The functional block engine  352  may be a set of sub-routines that can sequentially execute function blocks identified by the block execution list. In some circumstances, the function block engine  352  may execute the function blocks every second in the order provided by the block execution list. 
     During execution, the function block engine  352  may follow the block execution list of function blocks. This may include reading variables and/or parameters stored in the function block variable pool  356  and/or the loop flash constants  358 , as directed by the function blocks and/or block execution list. The function block engine  352  may execute the function blocks from the non-volatile memory, such as FLASH memory, using the data read from the parameters and/or variables. In some cases, the function block engine  352  may also write values or data to the function block variable pool  356 . In some cases, these written values are stored only temporarily in the function block variable pool  356  for use in the execution of other function blocks or as outputs of the controller. 
     The function block engine  352  may allow the application designer to program the controller to perform a wide variety of functions, such as HVAC functions. The function block engine  352  sequentially may execute each function block that the application designer has configured in the block execution list. In some cases, the inputs to the function blocks may be referenced from the function block variable pool  356  that may be resident in RAM. In some cases, there may only be a small stack space in the function block variable pool  356 , which could be reused by the function blocks for local, temporary variable storage. Additionally, in some cases, local physical and network inputs may be provided with access to the variable space. 
     The built-in function configuration and execute block  360  may provide a means of translating inputs (both local and network), and providing the values as variables that can be used as inputs to any or selected function blocks. In other words, in some case, the function blocks may be unaware that an input to a function block came from a physical input, a network input, a parameter, or as an output from another function block. The input from the built-in function execute block  360  may be stored in the function block variable pool  356 , in some cases only temporarily, for use by the function block engine  352 . 
     The following is an approach for a balancing procedure for a configuration tool that may be used. First is a k factor method with the following steps: 1) Set nviFlowoverride from HVO_OFF_NORMAL (0) to HVO_Maximum (7); 2) Read nciMaxFlowCoolSP and nvoBoxFlowCool and compare; wait until the nvoBoxFlowCool is within 0.5% of the nciMaxFlowCoolSP; look at nvoCmdCoolDmpPos and monitor until changes stops for 5 seconds or direction changes; 3) Read nvoBoxFlowCool and nvoCmdCoolDmpPos for stability; average nvoVelSenPressC reading over a 5 sample window after stability is reached; if the Flow is unstable, ask the user, “Would you like to balance anyway?” 4) Display apparent flow (nvoBoxFlowCool) and Display Current K Factor nciKFactorCool; show the new calculated K Factor based on the equation below and ask user to proceed with new calculated K factor; (K Factor) nciKFactorCool=(user entered measured Box Flow)/sqrt([5 sample average of nvoVelSenPressC]−nvoPressOffsetC); and 5) Set nviFlowoverride from HVO_Maximum (7) to HVO_OFF_NORMAL (0); (optional) check minimum flow if desired. 
     Next is a min/max method with the following steps: 1) Set nviFlowoverride from HVO_OFF_NORMAL (0) to HVO_Maximum (7); 2) Read nciMaxFlowCoolSP and nvoBoxFlowCool and compare; wait until they are within control range of algorithm; look at nvoCmdCoolDmpPos and monitor until changes stops for 5 seconds or direction changes; 3) Read nvoBoxFlowCool and nvoCmdCoolDmpPos for stability; average nvoVelSenPressC readings over a 5 sample window after stability is reached; if the Flow is unstable, ask the user “Would you like to balance anyway?” 4) Display apparent flow (nvoBoxFlowCool) and request input for actual max flow; enter in value in nciMeasMaxFlowC; 5) Set nviFlowoverride from HVO_OFF_NORMAL (0) to HVO_Minimum (7); 6) Read nciOccMinFlowCSP and nvoBoxFlowCool and compare; wait until they are within control range of algorithm; look at nvoCmdCoolDmpPos and monitor until changes stops for 5 seconds or direction changes; if the Flow is unstable, ask the user “Would you like to balance anyway?” 7) Read nvoBoxFlowCool and nvoCmdCoolDmpPos for stability; average readings over a 5 sample window after stability is reached; if the Flow is unstable, ask the user, “Would you like to balance anyway?” 8) Display apparent flow (nvoBoxFlowCool) and request input for actual min flow; enter in value in nciMeasMinFlowC; and 9) Set nviFlowOverride from HVO_Minimum (7) to HVO_OFF_NORMAL (0). 
     The following presents a simple work bench arrangement of the required hardware and the associated wiring connections to configure Excel™ 10 W775D, F Controllers (by Honeywell International Inc.). One may proceed as in the following: 1) With power disconnected to the housing subbase, insert the controller circuit board (contained in the housing cover) into the subbase unit; 2) Apply power to the controller, and insert the Serial Interface cable into the jack on either the Excel 10 W7751D or F Controllers; 3) Use the CARE/E-Vision™ PC tools to configure the controller (See the CARE E-Vision™ User&#39;s Guides, forms 74-5587 and 74-2588, for further details), use the ID number sticker on the controller or press the bypass button on the wall module; 4) When configuration is completed, power down and remove the W7751D, F from the subbase, mark the controller with the Plant name or location reference so the installer knows where to install each controller in the building; 5) Repeat with next W7751D, F to be configured; and 6) The data file used for this configuration should be used at the job site so the commissioning data matches the controllers. 
     One may do configuring in the field. If the controllers were installed at the site, the procedure to assign the node numbers to the Excel™ 10 VAV Controller may be as in the following: 1) Instruct the installer to remove the ID sticker from each controller during installation and to affix it to either the job blueprint at the appropriate location or to a tabulated list, be sure the installer returns these prints to the application engineer after the controllers are installed; 2) Connect to the E-Bus with the CARE™ PC tool; and 3) Proceed to configure the W7751 (using the job prints for location reference for the controllers) by following the standard CARE™ procedures. 
     One may configure a Zone Manager. 
     The Q7750A Excel™ 10 Zone Manager may send out a one-time LonWorks™ message containing its 48-bit Neuron™ ID after any power-up WARMSTART™ or when the Excel™ 10 Zone Manager is reset by pressing the reset button. It may be important to note that pressing the reset button on the Excel™ 10 Zone Manager may cause all application files in the Q7751, including the C-Bus setup, to be lost. The LonWorks™ message is sent out one time and only on the E-Bus, not on the B-Port. The message may be the same as the one generated after pressing the service pin pushbutton available on Excel™ 10 VAV Controllers and also via the wall module bypass pushbutton. The CARE™ commission tool (E-Vision) can use this message to assign the node address. 
     The Assign ID procedure is the same as for an Excel™ 10 VAV Controller except, instead of pressing the bypass button, the reset button should be pressed or the power must be cycled (down then up) on the Q7750A Excel™ 10 Zone Manager. 
     The following is pertinent to Sensor Calibration. The space temperature and the optional resistive inputs may be calibrated. The wall module setpoint potentiometer can not necessarily be calibrated. One may perform the sensor calibration by adding an offset value (either positive or negative) to the sensed value using E-Vision™ menus (see E-Vision™ user&#39;s guide, form number 74-2588). 
     The following may be used in Air Flow Balancing for Pressure Independent applications. In addition to the ten point Flow Pickup Calibration Table, the Excel™ 10 VAV Controller may provide for 3-point (Maximum, Minimum, and Zero) Air Flow Calibration. This may allow the box to be adjusted so it can be certified that the box provides the flow rates specified by the consulting engineer. When balancing is complete, the actual flow from a box should be within 5 to 10 percent of the indicated air flow (as shown on the E-Vision™ screen). On may note that there are many sources of error in flow-hood measurements. Flow hood meters may typically attain accuracy to within plus or minus three to five percent of full flow. The error can be due to the device being out of calibration, or that it was last calibrated with a different style of diffuser. Even the operator technique may play a role in obtaining repeatable, accurate flow readings. When working with slotted diffusers, one should not use a hood, but rather use a velocity-probe type of instrument. 
     One may follow the diffuser manufacturer&#39;s recommendation for a procedure of how to best measure the air flow through their products. Prior to air flow balancing for the first time, perform a zero flow calibration procedure. To do so, power the Excel™ 10 VAV Controller for one hour or more before performing the procedure. Select the controller being worked on with E-Vision™ (see the E-Vision™ User&#39;s Guide, form 74-2588, for general details on using E-Vision). Due to inconsistencies in VGA display cards and modes, be sure to maximize the E-Vision™ window on the screen (by clicking the up-arrow at the top-right corner of the E-Vision™ window). This assures that all E-Vision activities are user viewable. Refer to the Air Flow balancing section in the E-Vision™ user&#39;s Guide form, 74-2588 for the exact procedure. As to resetting Air Flow Calibration to Factory Defaults, one may refer to the Air Flow Balancing section in the E-Vision™ user&#39;s Guide form, 74-2588 for the exact procedure. 
     A VAV Zeroing Procedure may include the following): 1) Manually command Damper to Closed Position; 2) Read nvoCmdCoolDmpPos until it has closed (See step 3 in K factor Balancing Procedure); 3) Command nviAutoOffsetC to true; 4) Command nviAutoOffsetC to false; and 5) Observe nvoPressOC has changed. 
     The present function block engine may have a stage driver  401  (StageDriver), as shown in  FIG. 35 . The StageDriverMaster function may take input number of stages active and determine which stages to energize or de-energize based on the lead/lag strategy chosen. StageDriver may work with StageDriverAdd to distribute additional stages above those provided in StageDriver. StageDriver may also maintain a nonvolatile runtime total and digital stage status information for each stage. 
     The configuration tool may set a runtime and stage stages offset in a single offsets variable. The offsets variable is not necessarily used as a Public Variable ID. The lower byte may store the offset in digital memory to reference the starting stage status memory index, and the upper byte may store the offset in nonvolatile memory to reference the starting runtime memory index. The stgStatusOut may be the offset to digital stage status that is used by connected StageDriverAdd blocks. 
     As more stages are set up during design, the configuration tool may calculate the starting address for both stage status and runtime and allocate the memory and calculate the offset from the base index that is the starting address for the runtime area and the stage status area in their respective memories. 
     The runtime area may be stored in non volatile floats (4 bytes). The stage status area may use a digital byte (1 bytes) so 8 bits or 1 byte of information storage is used for each 8 stages assigned. The tool should assign a 1-byte extra buffer to ensure correct stage driver add functionality. 
     The stage status information may be accessible to drive additional stages. Additional StageDriverAdd function blocks may be use to drive stages above those provided in StageDriver up to 255 stages. 
     The StageDriver RAM structure may be defined as: 
     
       
         
           
               
               
               
             
               
                   
               
             
            
               
                   
                 IN_ONLY 
                  nStgActive; 
               
               
                   
                 IN_ONLY 
                 rantimeReset; 
               
            
           
           
               
               
            
               
                   
                 OUT_DIG stage1;OUT_DIG stage2;OUT_DIG stage3; 
               
               
                   
                 OUT_DIG stage4;OUT_DIGstage5; 
               
            
           
           
               
               
               
            
               
                   
                 OUT_FLT 
                  stgStatusOut; 
               
               
                   
                 OUT_FLT_SAV 
                   offsets; 
               
               
                   
               
            
           
         
       
     
     The parameters may include: 
                                            UBYTE  leadLag;   //lead/lag type           UBYTE  maxStgs;    //maximum number of stages                         The StageDriverLoopStatic structure is defined as:           UINT16 old_seconds; UINT16 oldnumstages;           UINT16 seqEndPtr; UINT16 seqStartPtr                    
From iteration to iteration, the Function Block keeps track of theses items. On power up/reset these are cleared. The memory index for Stage Status and Stage runtimer is calculated as follows.
 
                                        //baseStageStatus = VID_ControlDigitalBase + offsetStageStatus;           //baseStageRuntimer= VID_ControlNonVolatileBase +           offsetStageRuntimer;                    
where offsetStageStatus is the lower byte of offsets and offsetStageRuntime is the upper byte of offsets.
 
     The Inputs may include the following. The nStagesActive (IN_ONLY) is the input number of stages to be distributed to on/off values to individual stages. 
     The runtimeReset (IN_ONLY) is the stage number runtime to be reset to 0 if the lead-lag parameter is set to LL_RUNTIME. 0 or unconnected will result in no reset occurring. This value must be returned to 0 to allow the reset stage number to resume counting. It might only be valid if leadLag set to LL_RUNTIME. The stage runtime values may be only allocated and updated if the leadLag config is set to LL_RUNTIME. The runtime for each stage may be stored as a floating point number in intervals of 1 minute. The stages may be sampled once a minute and if the stage is on, then the stage runtime accumulator number for that stage can be incremented by one minute. The range of values for an integer number stored as a float, may be from −16,777,216 to 16,777,216. If the runtime is stored in minutes starting at 0 to 16,777,216, then the range of runtime may be from 0 to 31.92 years of runtime. 
     The Outputs may include the following. Stage 1 , stage 2 , stage 3 , stage 4 , and stage 5  (OUT_DIG) can be individual outputs that represent on or off values. These are outputs that may be turned on in different order depending on the leadLag strategy. 
     The stgStatusOut (OUT_FLT) may be connected from StageDriver to the StageDriverAdd block and give a floating point number combined to hold two pieces of information, which are an offset in the Common Memory to the StageBitStatus values and maximum number of stages available. This information may be used by the StageDriverAdd to find the correct offset to command which stages to turn on or off. The floating value may be converted to an integer and ANDed with 0xFF, and may give the value of the stageStatus Offset. The floating value stgStatusOut converted to an integer and right shifted 8 bits may give the byte value of the maxStages. These values may be needed to allow the StageDriverAdd to work properly. The values in stgStatusOut may be created by the StageDriver stage and no tool calculation is required. 
     The Offsets (OUT_FLT_SAV) may be noted. One may Store the public Variable ID to a float a value created by the tool to allocate storage memory and reference for stage status in digital memory and stage runtime in nonvolatile memory. There may be two offsets stored inside the float value, one for runtime, and one for stage status. The offset float value right shifted 8 bits may give the number of nonvolatile float values from the beginning nonvolatile index (offset) where the runtime values are stored (one runtime value offset for each stage configured), and the offset ANDED with 0xff may give the number of digital values from the base where the stagestatus is stored (one byte per up to 8 stages configured). Each digital memory location may take up 1 byte storage in calculating the offset. 
     For example, if 3 nonvolatiles were already assigned and 4 digital outputs were already assigned before adding a stagedriver stage of 9 stages with runtime accumulation, then the offset float value may be 256*3+4=772.0. That means the tool may have 8 nonvolatile runtime locations starting at offset  3  from the base of nonvolatile memory and the tool may allocate digital memory of two bytes for the stage status starting at offset of 4 from the base of digital memory. The tool may set this float value for offsets and allocate the memory, and then stagedriver may use this information to know where to look for stagestatus and stage runtime information. This value should not be displayed to the end user. 
     The Float value that stores Offsets may be composed of two values. The offsetStageRuntimer (byte) may be float value converted to an integer and shifted 8 bits—specifies the variable quantity offset to be applied to the beginning of nonvolatile memory variable number that indicates the starting variable number used to store the individual stage runtime values. This number may be calculated by the configuration tool and is not necessarily changeable. 
     The offsetStageStatus (byte) may be float value converted to an integer and ANDed with 0xFF—may specify the variable number offset to be applied to the beginning of digital memory area that indicates the starting variable number used to store the individual stage on/off values. This number may be calculated by the configuration tool and is not necessarily changeable. This value may be exported to other stages through the stageBitStatus output. 
     The parameters may be the following. The leadLag (Byte param:UBYTE) may specify whether the staging strategy should be first on last off (LL_STD=0—standard), first on first off (LL_FOFO=1—Rotating), run time accumulation where next on is lowest runtime and next off has highest runtime (LL_RUNTEQ=2—Runtime Accumulation). Runtime Accumulation selection may require the tool to allocate Nonvolatile memory and Set the Offsets value. For example, in a boiler control system configured for a maximum number of stages of 4, LL_STD may take the number of stages active and activate the stages in the following order: stage  1  on, then stage 1  and stage  2  on, then stage  1  on stage 2  on stage 3  on, then stage  1  on stage 2  on stage 3  on and stage  4  on. When one stage is removed then it will be stage  1  on stage  2  on stage  3  on. If one more stage is removed then it may be stage  1  on stage  2  on. If one more stage is removed then stage  1  on, and finally if one more stage is removed then there may be only one stage on. And finally if one more stage is removed then no stages are necessarily on. Stage  1  may always come on first and always be the last stage to turn off. If one takes this same example and implements as a LL_FOFO which is rotating or First on first off, then the boiler may keep track of where the starting stage is from the last cycle. Say, for example, there are no stages on and a stage is added. Then adding one stage will turn on stage 1 . If another stage is added, then stage 1  is on and stage 2  is on. If one more stage is added then stage 1  is on, stage 2  is on and stage  3  is on. Now one may say that the number of stages goes from 3 to 2 so now it is time to remove a stage. Because of LL_FOFO, the first stage one turned on may be the first stage to turn off so stage  1  would go off and only stage  2  and stage  3  would be on. Then, if one were to turn off one more stage, stage  2  would go off and only stage  3  would be on. Now if one added one more stage, stage  4  would turn on in addition to stage  3 . If One more stage were added (numstages=3), then stage  3  is on, stage  4  is on, and now stage  1  may turn on too. For a final example, one may take the example of LL_RUNTEQ for a sequence. Each stage may now have a runtime accumulation in minutes. So one may assume that the 4 stages turn on for 12 minutes. Each stage for stage 1 , stage 2 , stage 3 , and stage  4  may be on and accumulate 12 minutes of runtime. Now it may be time to turn off one stage so all the “ON” stages are evaluated for the highest runtime and since they may be all the same; the last stage that is on that is evaluated may have the highest runtime so stage  4  is turned off so stage  1  on stage 2  on and stage 3 =on. Now one may run the boilers for 2 more minutes. Now stage  1  has 14 minutes runtime, stage  2  has 14 minutes runtime, stage  3  has 14 minutes runtime, and stage  4  has 12 minutes runtime. Now the number of stages requested may drop to 2 stages so stage  3  is turned off and now stage  1  on, stage  2  on, stage  3  off, and stage  4  off. So now the boilers may be run for 2 more minutes. The runtimes may now be stage  1  on=16 minutes, stage  2  on=16 minutes, stage  3 =off=14 minutes, and stage  4 =off=12 minutes. Now one may add one more stage so number of stages goes from 2 to 3. Now all the stages that are off may be evaluated for lowest runtime. Stage  4  may have the lowest runtime of 12 minutes so now stage  4  is turned on. 
     The maxStages (Byte param:UBYTE) may specify how many total stages nStagesActive can reach. MaxStages can go up to a total of 255 stages. 
     The Common Memory Resources (not accessible by user but accessible by function block) may include the following. The stageRunTimer may be (STATIC_FL) per individual stage*number of stages. If stagingType=RUNTEQ, then individual stages runtimes values may be stored in nonvolatile memory. This memory may be allocated by the configuration tool. The runtimes for each stage may represent the accumulated ON time in hours and be stored in this separate area of nonvolatile STATIC_FL variable memory. The public variable ID for this block of timers may be designated by the tool. The Parameter runtimeMemOffset may specify the variable number offset to the starting STATIC_FL memory to access this block. The total number of bytes allocated in Common memory may be maxStages time 4 bytes (STATIC_FL), so for 10 stages it would be 10 floats or 40 bytes. Each runtime value may be stored as a FLOAT and is sequentially stored starting with RuntimeStage 1 . 
     The stageStatus (UBYTE per 8 stages) may be a set of digital memory variable allocated by the configuration tool. The total number of bytes allocated in this stageStatus memory area may be the rounded up value of maxStages divided by 8, plus 8 bits so 18 stages would require 26 bits or 4 bytes rounded up. The stageStatus memory area may be accessed by both StageDriver and StageDriverFollower to determine if a particular stage should be on. 
     As noted herein,  FIG. 35  is a block diagram of the stage driver (StageDriver)  401  with leadlag maxStgs. It may have inputs nStagesActive  402  and runtimeReset  403 . The stage outputs may include Stage 1   411 , Stage 2   412 , Stage 3   413 , Stage 4   414  and Stage 5   415 . Other outputs may include stgStatusOut  416  and offsets  417 . 
       FIG. 36  is a diagram of a stage driver system  418 . In the Stagedriver block  441 , nvinStgActive may be an input  452  that requests the number of stages to turn on. nviTimeReset may be an input  453  used to reset the individual stage runtimes. A selection for the Stagedriver algorithm may allow the choice of Standard, First On/First Off (Rotating), and Runtime equalization. StageDriver Block  1  ( 441 ) may have individual stages outputs  1 - 5  on outputs labeled number  1 - 5 . The Maximum stage parameter may be set to 21 stages. Output  6  may be stgStatusOut and be used to communicate the base memory location for the individual stage status (on/off) memory and also the maximum number of stages. 
     The algorithm for the StageDriver block  441  may determine which stages should be added or deleted based on the Standard, First on/First off, and runtime equalization selection. The StageDriver block may store the results of the individual stages in the stage status memory location, using 1 bit per stage. Individual Stage Driving block such as StageDriver or Stagedriver add may access the individual bit status from the stage status memory location. In the case of Runtime equalization, there may be a separate nonvolatile memory area that is used by the algorithm in the StageDriver block that stores the runtime total. Individual runtimes may be reset by using the reset input. 
     StageDriverAdd Block  2  ( 442 ) may take the StgStatusOut information and the starting stage number for this stage (set to 6 in this example) and give individual outputs for stages  6 - 13 . StageDriverAdd Block  3  ( 443 ) may take the StgStatusOut information and the starting stage number for this stage (set to 14 in this example) and give individual outputs for stages  14 - 21 . 
       FIG. 37  is a table  431  of analog inputs for stage driver  401 . It shows the input name, Cfg, a low and high of the range, the input value and the description for each input.  FIG. 38  is a table  432  of analog outputs of stage driver  401 . It shows the output name, Cfg, a low and high of the range, and the description for each output. 
     Aspects of the configuration may include the following. The user may specify the maximum number of stages (maxStgs) from 1 to 255. The user may specify the lead lag (leadlag): LL_STD=0—first on last off. LL_FOFO=1—first on first off. LL_RUNEQ=2—runtime equalization for lowest runtime. If the leadlag is outside of the range of 0-2 then Stages may be initialized to off and not commanded. 
     The stage driver addition (StageDriverAdd)  420  may be noted in  FIG. 39 . An input (stgStatusIn)  419  may go to the stage driver addition (firstStageNum). The outputs of block  420  may include Stage 1   421 , Stage 2   422 , Stage 3   423 , Stage 4   424 , Stage 5   425 , Stage 6   426 , Stage 7   427  and Stage 8   428 . 
     The StageDriverAdd function may take input command from StageDriver and determine which stages to energize or de-energize based on the lead/lag strategy chosen. StageDriverAdd may work with StageDriver to distribute stages. For example, if StageDriver controls stage  1 - 6 , then the first connection to StageDriverAdd may be configured to handle stages  7 - 14  and the second StageDriverAdd may be configured to handle stages  15 - 22 . 
     Inputs may be noted. The stgStatusIn (IN_ONLY) may be the float value to be distributed to on/off values to individual stages. This input should come from the output of the StageDriver. The float should first be converted to a two byte unsigned integer. The upper byte (value right shifted 8 bits) may give the maximum number of stages used, and the lower byte (value times 0xff) may give the offset of number of digital values to the start of the stage status location. 
     Parameters may include the following. The firstStageNum (BYTE_PARAM) may be the starting stage number of this block. For example if StageDriverMaster commands stages  1 - 5 , then firstStageNum for the next connected StageDriverFollower would be 6. The default value of the first StageDriveAdd Block&#39;s parameter firstStageNum should be 6. It is possible to have the first stage number in the StageDriverAdd overlap the stages controlled by StageDriver. For example, by setting firstStageNum to 1 on A StageDriverAdd may duplicate the stage  1 - 5  functionality of StageDriver. 
     Outputs may include the following items. Stage 1 , stage 2 , stage 3 , stage 4 , stage 5 , stage 6 , stage 7 , and stage 8  (OUT_DIG) may be individual outputs that represent on or off values. These may be outputs that are turned on in different order depending on the leadLag strategy.  FIG. 40  is a table  433  of the analog input. The table shows the input name, Cfg, the low and high of the range, the input value and description of the input.  FIG. 41  is a table  434  of the analog outputs. The table may show the output name, Cfg, the low and high of the range, and a description of the output. An aspect of the configuration (Cfg) may be noted in that the user may specify the First Stage number (firstStageNum) from 1 to 255. 
       FIG. 42  shows a stage driver  501  with outputs to at least two stage driver add blocks  502  and  503 . Inputs to driver  501  may include n stages active and runtime reset. Driver  501  may include tool sets offsets with offset stage status and offset stage run timer. The outputs may include offsets. Another output may include stgStatusOut which may be inputs to stage driver add blocks  502  and  503 . The stgStatusOut may equal maxStgs×256+offset Stage Status. 
     A block diagram of a stage driver is shown in  FIGS. 43 ,  44 ,  45 ,  46 ,  47  and  48 , sequentially. These Figures reveal a series of items  511 ,  512 ,  513 ,  514 ,  515 ,  516 ,  517 ,  518  and  519 , in a serial fashion. The “no” line  545  may connect item  514  to item  516 .  FIG. 49  is a diagram of the stage driver add with an item  520 . 
       FIGS. 43-49  show the components of the Stage Driver and StageDriverAdd algorithm.  FIGS. 43-48  show the StageDriver routine, and  FIG. 49  shows the StageDriverAdd algorithm. 
     In  FIG. 43 , the StageDriver algorithm may start with the individual StageStatus and Stage Runtime Information pieces may be extracted from the offsets variable. The value in the offsets variable may be assigned by the configuration tool at design time. The stgStatusOut value used by other StageDriverAddStages may be combined from the MaxStage parameter and the OffsetStageStatus derived from the previous calculation. 
       FIG. 44  shows the standard Lead/lag procedure which turns on stages up to the input number of stages and leaves the rest off. The actual on/off commands may be stored in the stage status memory location with one stage stored per bit. The function SetStageStatus may have the offset, stagenumber (i), and command (cmd) called for each stage. Additionally, if the value of the stages is from 1 to 5, the individual stage may be commanded to the command value stored from the previous step. 
       FIG. 45  shows the First on/first off (rotating) algorithm. An individual Start Pointer (SeqStartPtr) may be used to keep track of the first stage beginning point and as stages are added, the sequence End Pointer (seqEndPtr) may go up and as stages are deleted the SeqStartPtr may go up. The Stages between SeqStartPtr and SeqEndPtr may be on, and there may be wrap around behavior based on the maximum stages requested. 
       FIGS. 46-48  show the Runtime equalization algorithm. An individual runtime value may be used to store the individual stage runtime value, using one float value per individual stage. As the algorithm goes through each individual stage, the value of each stage runtime may be compared to the highest stage runtime and lowest stage runtime found so far. If the individual stage is on (determined by a function Get StageStatus), then the runtime for that on stage may be compared against the highest stage runtime found so far. After all the stages have been cycled through, the stage with the highest runtime may be the candidate to be turned off. Similarly, all the stages that are off may be cycled through and each individual stage runtime may be compared against the lowest stage runtime found so far. After all the stages have been cycled through, the stage with the lowest runtime may be the candidate to be turned off. One stage per execution can change status with the runtime selection. 
     A runtime reset routine may allow an individual stage to be set to zero from the function block. Other memory access methods may allow individual setting of the runtime values. 
       FIG. 49  shows the Stagedriver Add routine. This routine may determine the individual stage status offset values where the stage information is stored and the max stages information from the stgStatusIn which is a connected valued from the StageStatus block. Individual stages on and off information may be determined from the GetStageStatus Function call. Each individual stage value may be commanded through the PutFVal function call. 
     For a stage driver block setup, one may have a configuration tool. The configuration tool should keep track of resources allocated in the stage driver block design, such as in a present example (i.e.,  FIG. 36 ). 
     Stage driver  1  block may use resources as in the following. 
     
       
         
           
               
               
               
             
               
                   
               
             
            
               
                   
                 # Control Floats = 2 
                   FVALS = 2 
               
               
                   
                 # Control Digitals = 25 
                 DVALS = 26 
               
               
                   
                 # Control NonVolatiles = 1 
                 SetPoints = 1 
               
               
                   
                 # Flash Constants = 0 
                 CONST 0 
               
               
                   
                 # Bytes Loop Static = 8 
                   
               
               
                   
                 # Function Blocks = 3 
                 LSTAT = 8 
               
               
                   
                 # User NVIs = 1 
                   
               
               
                   
                 # UserNVOs = 16 
                 # FB = 3 
               
               
                   
               
            
           
         
       
     
     The following information may consist of a project summary for the stage driver. 
     
       
         
           
               
             
               
                   
               
               
                 Device Name StageDriver 
               
               
                   
               
             
            
               
                 Resource Useage 
               
            
           
           
               
               
               
            
               
                   
                 # Control Floats = 2 
                   
               
               
                   
                 # Control Digitals = 25 
                   
               
               
                   
                 # Control NonVolatiles = 23 
                   
               
               
                   
                 # Flash Constants = 0 
                   
               
               
                   
                 Bytes RAM pool Used = 116 
                   
               
               
                   
                 Bytes Loop Static = 8 
                   
               
               
                   
                 # Function Blocks = 3 
                   
               
               
                   
                 # User NVIs = 1 
                   
               
               
                   
                 # User NVOs = 16 
               
               
                   
               
            
           
           
               
            
               
                 Function Block Data 
               
            
           
           
               
               
            
               
                 Type 
                 Name 
               
               
                 STAGEDRIVER 
                 STAGEDRIVER1 
               
            
           
           
               
               
               
               
               
            
               
                 Wrd 
                 Name 
                 PVID (hex) 
                 PVID (dec) 
                 Value 
               
               
                   
               
               
                 0 
                 nStgActive 
                 8000 
                 32768 
                 0 
               
               
                 1 
                 runtimeReset 
                 8203 
                 33283 
                 0 
               
               
                 2 
                 stage1 
                 8204 
                 33284 
                 0 
               
               
                 3 
                 stage2 
                 8205 
                 33285 
                 0 
               
               
                 4 
                 stage3 
                 8206 
                 33286 
                 0 
               
               
                 5 
                 stage4 
                 8207 
                 33287 
                 0 
               
               
                 6 
                 stage5 
                 8208 
                 33288 
                 0 
               
               
                 7 
                 stgStatusOut 
                 8001 
                 32769 
                 0 
               
               
                 8 
                 offsets 
                 8116 
                 33046 
                 0 
               
               
                   
               
               
                 Byt 
                 Name 
                 Value 
               
               
                   
               
               
                 0 
                 leadLag 
                 2 
                   
                   
               
               
                 1 
                 maxStgs 
                 22  
                   
                   
               
               
                 2 
                 spare 
                 0 
               
               
                   
               
            
           
           
               
               
            
               
                 Type 
                 Name 
               
               
                 STAGEDRIVER_ADD 
                 STAGEDRIVER_ADD2 
               
            
           
           
               
               
               
               
               
            
               
                 Wrd 
                 Name 
                 PVID (hex) 
                 PVID (dec) 
                 Value 
               
               
                   
               
               
                 0 
                 stgStatusIn 
                 8001 
                 32769 
                 0 
               
               
                 1 
                 stage1 
                 8209 
                 33289 
                 0 
               
               
                 2 
                 stage2 
                 820A 
                 33290 
                 0 
               
               
                 3 
                 stage3 
                 820B 
                 33291 
                 0 
               
               
                 4 
                 stage4 
                 820C 
                 33292 
                 0 
               
               
                 5 
                 stage5 
                 820D 
                 33293 
                 0 
               
               
                 6 
                 stage6 
                 820E 
                 33294 
                 0 
               
               
                 7 
                 stage7 
                 820F 
                 33295 
                 0 
               
               
                 8 
                 stage8 
                 8210 
                 33296 
                 0 
               
               
                   
               
               
                 Byt 
                 Name 
                 Value 
               
               
                   
               
               
                 0 
                 firstStgNum 
                 6 
                   
                   
               
               
                 1 
                   
                 0 
                   
                   
               
               
                 2 
                 spare 
                 0 
               
               
                   
               
            
           
           
               
               
            
               
                 Type 
                 Name 
               
               
                 STAGEDRIVER_ADD 
                 STAGEDRIVER_ADD3 
               
            
           
           
               
               
               
               
               
            
               
                 Wrd 
                 Name 
                 PVID (hex) 
                 PVTID (dec) 
                 Value 
               
               
                   
               
               
                 0 
                 stgStatusIn 
                 8001 
                 32769 
                 0 
               
               
                 1 
                 stage1 
                 8211 
                 33297 
                 0 
               
               
                 2 
                 stage2 
                 8212 
                 33298 
                 0 
               
               
                 3 
                 stage3 
                 8213 
                 33299 
                 0 
               
               
                 4 
                 stage4 
                 8214 
                 33300 
                 0 
               
               
                 5 
                 stage5 
                 8215 
                 33301 
                 0 
               
               
                 6 
                 stage6 
                 8216 
                 33302 
                 0 
               
               
                 7 
                 stage7 
                 8217 
                 33303 
                 0 
               
               
                 8 
                 stage8 
                 8218 
                 33304 
                 0 
               
               
                   
               
               
                 Byt 
                 Name 
                 Value 
               
               
                   
               
               
                 0 
                 firststgNum 
                 14  
                   
                   
               
               
                 1 
                   
                 0 
                   
                   
               
               
                 2 
                 spare 
                 0 
               
               
                   
               
            
           
           
               
            
               
                 User NV Configuration Data 
               
            
           
           
               
               
               
               
               
            
               
                 NV Name 
                 Field Name 
                 PVID (hex) 
                 PVID (dec) 
                 Value 
               
               
                   
               
               
                 nviNStgActive 
                 Field1 
                 8000 
                 32768 
                 0 
               
               
                 Stage6 
                 Field1 
                 8209 
                 33289 
                 N/A 
               
               
                 Stage7 
                 Field1 
                 820A 
                 33290 
                 N/A 
               
               
                 Stage8 
                 Field1 
                 820B 
                 33291 
                 N/A 
               
               
                 Stage9 
                 Field1 
                 820C 
                 33292 
                 N/A 
               
               
                 Stage10 
                 Field1 
                 820D 
                 33293 
                 N/A 
               
               
                 Stage11 
                 Field1 
                 820E 
                 33294 
                 N/A 
               
               
                 Stage12 
                 Field1 
                 820F 
                 33295 
                 N/A 
               
               
                 Stage13 
                 Field1 
                 8210 
                 33296 
                 N/A 
               
               
                 Stage14 
                   
                 8211 
                 33297 
                 N/A 
               
               
                 Stage15 
                 Field1 
                 8212 
                 33298 
                 N/A 
               
               
                 Stage16 
                 Field1 
                 8213 
                 33299 
                 N/A 
               
               
                 Stage17 
                 Field1 
                 8214 
                 33300 
                 N/A 
               
               
                 Stage18 
                 Field1 
                 8215 
                 33301 
                 N/A 
               
               
                 Stage19 
                 Field1 
                 8216 
                 33302 
                 N/A 
               
               
                 Stage20 
                 Field1 
                 8217 
                 33303 
                 N/A 
               
               
                 Stage21 
                 Field1 
                 8218 
                 33304 
                 N/A 
               
               
                   
               
            
           
           
               
            
               
                 Control Constants 
               
            
           
           
               
               
               
            
               
                 PVID(Hex) 
                 PVID(Dec) 
                 Value 
               
               
                   
               
            
           
         
       
     
       FIGS. 50-56  relate to stage drivers discussed herein. 
     One may note a “flexible resource stage rotation linking appliance”. In the design of programmable controls in the commercial HVAC industry, there may appear a need to dynamically assign stage outputs from a single input such as number of stages requested. Traditional block approaches and memory resources may require a fixed area that is an integer multiple of the maximum size of the block, for example, if 16 outputs are required, then a block of 16 or an elaborate scheme to share the information of staging and memory resources are required. There appears a need to dynamically allocate resource and stages in a resource efficient manner that is tied in with a flexible block architecture. 
     The system may solve the design and implementation issue through the efficient use of two function blocks that work with HVAC systems such as CVAHU, VAV, and other stage utilization algorithms. 
     As more stages are set up during design, the configuration tool may calculate the starting address for both stage status and runtime and allocate the memory and calculate the offset from the base index that is the starting address for the runtime area and the stage status area in their respective memories. 
     A system may be also regarded as an “incremental stager linking with dynamic resource adaptation”. In the design of programmable controls in the commercial HVAC industry, there appears a need to assign individual on/off stage outputs from a single input such as number of stages requested. The actual stages that turn on are dependent on the configuration of the stager such as first on/first off, first on last off (rotating), and runtime accumulation switching. Other configuration information may include the number of total stages maximum allowed. Furthermore, there appears the need to optimize this stage driver to use low cost microprocessor controls that have a small amount of memory and processor resources. Traditional block approaches and memory resources may require a fixed area that is an integer multiple of the maximum size of the block, for example, if 16 outputs are required, then a block of 16 or an elaborate scheme to share the information of staging and memory resources are required. The issue that this invention may address may be the ability to configure a single or multiple stages in a modular function fashion that optimizes the use of memory resources. 
     This invention may solve this problem though the use of connection between the source stage block and the additional stage blocks plus the use of a common memory area allocated by an intelligent tool. Furthermore, this invention may use a memory allocation scheme that dynamically assigned needed memory resources so that very little footprint beyond the minimum required is necessary. Additional stage blocks may have little knowledge or dependence on the original primary source stage block and have additional flexibility to start or duplicate stage coverage. 
     The StageDriver Master function takes input number of stages active and determines which stages to energize or de-energize based on the lead/lag strategy chosen. StageDriver works with StageDriverAdd to distribute additional stages above 7 stages. StageDriver drives digital output stages  1 - 6 . It also maintains a nonvolatile runtime total and digital stage status information for each stage. 
     The configuration tool may set a runtime and stage stages offset in a single offsets variable. The offsets variable is not necessarily a Public Variable ID. The lower byte may store the offset in digital memory to reference the starting stage status memory index, and the upper byte may store the offset in nonvolatile memory to reference the starting runtime memory index. stgStatusOut is the offset to digital stage status that is used by connected StageDriverAdd blocks. 
     As more stages are set up during design, the configuration tool may calculate the starting address for both stage status and runtime and allocate the memory and calculate the offset from the base index that is the starting address for the runtime area and the stage status area in their respective memories. 
     Inputs may include the following. 
     nStagesActive (IN_ONLY) is the input number of stages to be distributed to on/off values to individual stages. 
     Outputs may include the following. 
     Stage 1 , stage 2 , stage 3 , stage 4 , stage 5 , and stage 6  (OUT_DIG) are individual outputs that represent on or off values. These are outputs that are turned on in different order depending on the leadLag strategy. 
     stageStatusOut (OUT_FLT) is connected from StageDriver to the StageDriverFollower block and gives offset in the Common Memory to the StageBitStatus values. This information is used by the StageDriverAdd to find the correct offset to command which stages to turn on or off. 
     Offsets (OUT_FLT) is used directly as a offset the Public variable ID to store two offsets, one for runtime, and one for stage status. The Actual OUT_FLT value is not necessarily used, just the two byte value stored in the Public Variable ID space. This value does not appear to refer to a Public Variable ID. 
     The Structure content of the 2 byte offset references for Offsets may be included the following. 
     offsetStageRuntimer (byte) specifies the variable quantitative offset to be applied to the beginning of nonvolatile memory variable number that indicates the starting variable number used to store the individual stage runtime values. This number may be calculated by the configuration tool and is not necessarily changeable. 
     offsetStageStatus (byte) specifies the variable number offset to be applied to the beginning of digital memory area that indicates the starting variable number used to store the individual stage on/off values. This number may be calculated by the configuration tool and is not necessarily changeable. This value is exported to other stages through the stageBitStatus output. 
     Parameters may include the following. 
     leadlag (Byte param:UBYTE) specifies whether the staging strategy should be first on last off (LL_STD=0—standard), first on first off (LL_FOFO=1—Rotating), run time accumulation where next on is lowest runtime and next off has highest runtime (LL_RUNTEQ=2—Runtime Accumulation). 
     maxStages (Byte param:UBYTE) specifies how many total stages nStagesActive can reach. MaxStages can go up to a total of 255 stages. 
     Common Memory Resources (not accessible by user but accessible by function block) 
     stageRunTimer (STATIC_FL per individual stage*number of stages−If stagingType=RUNTEQ, then individual stages runtimes values are stored in nonvolatile memory. This memory may be allocated by the configuration tool. The runtimes for each stage represent the accumulated ON time in hours and are stored in this separate area of nonvolatile STATIC_FL variable memory. The public variable ID for this block of timers is designated by the tool. The Parameter runtimeMemOffset specifies the variable number offset to the starting STATIC_FL memory to access this block. The total number of bytes allocated in Common memory is maxStages time 4 bytes (STATIC_FL), so for 10 stages it would be 10 floats or 40 bytes. Each runtime value may be stored as a FLOAT and be sequentially stored starting with RuntimeStage 1 . 
     stageStatus (UBYTE per 8 stages) is a set of digital memory variable allocated by the configuration tool. The total number of bytes allocated in this stageStatus memory area may be the rounded up value of maxStages divided by 8, plus 8 bits so 18 stages would require 26 bits or 4 bytes rounded up. The stageStatus memory area may be accessed by both StageDriver and StageDriverFollower to determine if a particular stage should be on. 
     The StageDriverAdd function may take input command from StageDriver and determine which stages to energize or de-energize based on the lead/lag strategy chosen. StageDriverAdd works with StageDriver to distribute stages. For example if StageDriver controls stage  1 - 6 , then the first connection to StageDriverAdd could be configured to handle stages  7 - 14  and the second StageDriverAdd could be configured to handle stages  15 - 22 . 
     Inputs may include the following. stgStatusIn (IN_ONLY) is the offset value to the to be distributed to on/off values to individual stages. This input must come from the output of the StageDriver. 
     Parameters may include the following. firstStageNum (BYTE_PARAM) is the starting stage number of this block. For example if StageDriverMaster commands stages  1 - 6 , then firstStageNum for the next connected StageDriverFollower would be 7. It is possible to have the first stage number in the StageDriverAdd overlap the stages controlled by StageDriver. For example by setting firstStageNum to 1 on A StageDriverAdd would duplicate the stage  1 - 6  functionality of StageDriver. 
     Outputs may include the following. Stage 1 , stage 2 , stage 3 , stage 4 , stage 5 , stage 6 , stage 7 , and stage 8  (OUT_DIG) are individual outputs that represent on or off values. These are outputs that are turned on in different order depending on the leadLag strategy. 
     Stage driver—The StageDriver Master function takes input number of stages active and determines which stages to energize or de-energize based on the lead/lag strategy chosen. StageDriver works with StageDriverAdd to distribute additional stages above 7 stages. StageDriver drives digital output stages  1 - 6 . It also maintains a nonvolatile runtime total and digital stage status information for each stage. 
     The configuration tool will set a runtime and stage stages offset in a single offsets variable. The offsets variable is not a Public Variable ID. The lower byte will store the offset in digital memory to reference the starting stage status memory index, and the upper byte will store the offset in nonvolatile memory to reference the starting runtime memory index. stgStatusOut is the offset to digital stage status that is used by connected StageDriverAdd blocks. 
     As more stages are set up during design, the configuration tool will calculate the starting address for both stage status and runtime and allocate the memory and calculate the offset from the base index that is the starting address for the runtime area and the stage status area in their respective memories. 
     The runtime area is stored in non volatile floats (4 bytes). The stage status area uses a digital byte (1 bytes) so 8 bits or 1 byte of information storage is used for each 8 stages assigned. The tool must assign a 1 byte extra buffer to ensure correct stage driver add functionality. 
     The stage status information is accessible to drive additional stages. 
     Additional StageDriverAdd function blocks are use to drive stages 7 up to 255. 
     The StageDriver ram structure is defined as: 
     
       
         
           
               
               
             
               
                   
               
             
            
               
                   IN_ONLY 
                 nStgActive; 
               
            
           
           
               
            
               
                   OUT_DIG stage1;OUT_DIG Stage2;OUT_DIG stage3;OUT_DIG 
               
               
                 stage4;OUT_DIG stage5;OUT_DIG stage6; 
               
            
           
           
               
               
            
               
                   OUT_DIG 
                 stgStatusOut; 
               
               
                   OUT_FLT 
                 offsets; 
               
            
           
           
               
               
            
               
                   UBYTE   leadLag; 
                 //lead/lag type 
               
               
                   UBYTE   maxStgs; 
                 //maximum number of stages 
               
               
                   
               
            
           
         
       
     
     The StageDriverLoopStatic structure may be defined in the following. 
     UINT16 oldnumstages; UINT16 seqEndPtr; UINT16 seqStartPtr; 
     The memory index for Stage Status and Stage runtimer is calculated in the following. 
     
       
         
           
               
             
               
                   
               
             
            
               
                   //baseStageStatus = VID_ControlDigitalBase +  
               
               
                 offsetStageStatus; 
               
               
                   //baseStageRuntimer=VID_ControlNonVolatileBase + 
               
               
                 offsetStageRuntimer; 
               
               
                   
               
            
           
         
       
     
     where offsetStageStatus is the lower byte of offsets and offsetStageRuntime is the upper byte of offsets. 
     Inputs may include the following. 
     nStagesActive (IN_ONLY) is the input number of stages to be distributed to on/off values to individual stages. 
     Outputs may include the following. 
     Stage 1 , stage 2 , stage 3 , stage 4 , stage 5 , and stage 6  (OUT_DIG) are individual outputs that represent on or off values. These are outputs that are turned on in different order depending on the leadlag strategy. 
     stageStatusOut (OUT_FLT) is connected from StageDriver to the StageDriverFollower block and gives offset in the Common Memory to the StageBitStatus values. This information is used by the StageDriverAdd to find the correct offset to command which stages to turn on or off. 
     Offsets (OUT_FLT) is used directly as a offset the Public variable ID to store two offsets, one for runtime, and one for stage status. The Actual OUT_FLT value is not used, just the two byte value stored in the Public Variable ID space. This value does not refer to a Public Variable ID. 
     The Structure content of the 2 byte offset references for Offsets may include the following. 
     offsetStageRuntimer (byte) specifies the variable quantitative offset to be applied to the beginning of nonvolatile memory variable number that indicates the starting variable number used to store the individual stage runtime values. This number is calculated by the configuration tool and is not changeable. 
     offsetStageStatus (byte) specifies the variable number offset to be applied to the beginning of digital memory area that indicates the starting variable number used to store the individual stage on/off values. This number is calculated by the configuration tool and is not changeable. This value is exported to other stages through the stageBitStatus output. 
     Parameters may include the following. 
     leadlag (Byte param:UBYTE) specifies whether the staging strategy should be first on last off (LL_STD=0—standard), first on first off (LL_FOFO=1—Rotating), run time accumulation where next on is lowest runtime and next off has highest runtime (LL_RUNTEQ=2—Runtime Accumulation). 
     maxStages (Byte param:UBYTE) specifies how many total stages nStagesActive can reach. MaxStages can go up to a total of 255 stages. 
     Common Memory Resources (not necessarily accessible by user but may be accessible by function block) 
     stageRunTimer (STATIC_FL per individual stage*number of stages−If stagingType=RUNTEQ, then individual stages runtimes values are stored in nonvolatile memory. This memory is allocated by the configuration tool. The runtimes for each stage represent the accumulated ON time in hours and are stored in this separate area of nonvolatile STATIC_FL variable memory. The public variable ID for this block of timers is designated by the tool. The Parameter runtimeMemOffset specifies the variable number offset to the starting STATIC_FL memory to access this block. The total number of bytes allocated in Common memory is maxStages time 4 bytes (STATIC_FL), so for 10 stages it would be 10 floats or 40 bytes. Each runtime value is stored as a FLOAT and is sequentially stored starting with RuntimeStage 1 . 
     stageStatus (UBYTE per 8 stages) is a set of digital memory variable allocated by the configuration tool. The total number of bytes allocated in this stageStatus memory area is the rounded up value of maxStages divided by 8, plus 8 bits so 18 stages would require 26 bits or 4 bytes rounded up. The stageStatus memory area is accessed by both StageDriver and StageDriverFollower to determine if a particular stage should be on. 
     Note  FIGS. 52 and 53 . 
     Stage driver add—The StageDriverAdd function takes input command from StageDriver and determines which stages to energize or de-energize based on the lead/lag strategy chosen. StageDriverAdd works with StageDriver to distribute stages. For example if StageDriver controls stage  1 - 6 , then the first connection to StageDriverAdd could be configured to handle stages  7 - 14  and the second StageDriverAdd could be configured to handle stages  15 - 22 . 
     Inputs may include the following. 
     stgStatusIn (IN_ONLY) is the offset value to the to be distributed to on/off values to individual stages. This input must come from the output of the StageDriver. 
     Parameters may include the following. 
     firstStageNum (BYTE_PARAM) is the starting stage number of this block. For example if StageDriverMaster commands stages  1 - 6 , then firstStageNum for the next connected StageDriverFollower would be 7. It is possible to have the first stage number in the StageDriverAdd overlap the stages controlled by StageDriver. For example by setting firstStageNum to 1 on A StageDriverAdd would duplicate the stage  1 - 6  functionality of StageDriver. 
     Outputs may include the following. 
     Stage 1 , stage 2 , stage 3 , stage 4 , stage 5 , stage 6 , stage 7 , and stage 8  (OUT_DIG) are individual outputs that represent on or off values. These are outputs that are turned on in different order depending on the leadLag strategy. 
     Note  FIGS. 54 ,  55  and  56 . 
     An Appendix A herein provides further support of the description of the systems herein. 
     In the present specification, some of the matter may be of a hypothetical or prophetic nature although stated in another manner or tense. 
     Although the invention has been described with respect to at least one illustrative example, many variations and modifications will become apparent to those skilled in the art upon reading the present specification. It is therefore the intention that the appended claims be interpreted as broadly as possible in view of the prior art to include all such variations and modifications.