US20060253835A1

Movatterモバイル変換

Info

Publication number: US20060253835A1
Application number: US11/396,864
Authority: US
Inventors: Hans Saelens
Original assignee: Spraying Systems Co
Current assignee: Spraying Systems Co
Priority date: 2001-05-09
Filing date: 2006-04-03
Publication date: 2006-11-09
Also published as: US7024285B2; US20040260429A1

Abstract

A method and system for implementing a spray controller uses object-oriented software code and an interrupt-driven operating system for processing and interpreting the code.

Description

CROSS-REFERENCE TO RELATED APPLICATIONS

This patent application is a divisional of copending U.S. application Ser. No. 10/463,164, filed Jun. 17, 2003, now U.S. Pat. No. 7,024,285, which is a nonprovisional of PCT Application No. PCT/IUS02/14873, filed May 9, 2002, which application claims the benefit of U.S. Provisional Application No. 60/289,830, filed May 9, 2001. Each of said applications is incorporated herein by reference in its entirety.

FIELD OF THE INVENTION

This invention relates generally to spray control systems, and more particularly, to an operating system and environment for controlling a spraying system implemented using object-oriented programming techniques.

BACKGROUND OF THE INVENTION

Spray control systems are used in variety of applications, such as for applying paints and other coating compositions to plastic, metal, and optical components. In many of these applications, it is beneficial if not important to achieve a uniform thickness of coating material. Consequently, spray control systems typically utilize closed loop control to regulate the flow of coating fluid and/or fluid pressure provided to the spray gun or other applicator. These closed loop control schemes use the error between the measured flow and/or pressure and setpoints corresponding to desired flow and pressure to provide negative feedback that drives the flow toward the setpoint. PID (proportional plus integral plus derivative) control is common among these control schemes.

In other applications, such control systems may be employed in agricultural environments to regulate the application of liquids and chemicals such as water or fertilizer, to crops, plants and soil. In these applications, the spraying control system allows users to easily measure and monitor desired plant or crop characteristics such as temperature or soil density, control and modify the flow rate and pressure of the liquid or chemical being distributed, and adjust spray settings according to differing levels of plant/crop growth and activity. The capabilities afforded by such systems promote increased plant/crop production and better efficiency.

In these applications, the spray controller performs numerous logical operations based on the receipt of input information to provide overall monitoring and control of operating parameters of the system. For example, in the case of a mobile spraying system, the controller may receive various signals from input devices, such as sensors that detect system pressure, flow rate, spray application rate, and/or ground speed. Other input components may include a user keypad for entering desired setpoints, functional switches for altering application modes/settings or a barcode reader for receiving user input commands and instructions. In response to the input information, the spray controller operates in a logical fashion to provide output signals to various output components, such as flow valve actuators and the like.

The input and output components and devices interact with one another to perform the various functions of the controller under the control of a central processing unit (CPU). The CPU is capable of processing the logical instructions and/or algorithms that regulate how the components interact, and controls the overall operation of the spray system. These instructions and algorithms are stored in a programmable memory device resident within the controller circuitry or within the CPU memory directly. Commonly, the instructions/algorithms are designed using relay ladder logic and other conventional programmable logic languages.

In these known systems, the user has limited ability to modify the control and operation of the controller according to the specific requirements of his or her application. That is, while the user can alter the desired setpoints for the control system, the more intrinsic logical and procedural operations as defined by the instructions/algorithms within the controller memory cannot be directly modified. The ability of the user to accommodate spraying requirements that extend beyond the capabilities of the pre-programmed user settings/modes is impractical in most conventional spray controllers and systems.

Although the controller program code can be modified or customized for the user by the system manufacturer to meet a specific set of requirements, this level of customization can be costly to the user, especially when only small quantities of customized controllers are needed. Furthermore, users already having existing spray controllers that call for only simple modifications must either incur the expense of reprogramming the controller, or replace their existing controllers with a different one. These options are inconvenient and costly.

SUMMARY OF THE INVENTION

The present invention overcomes the limitations of the prior art by providing a spray controller that may be readily modeled, modified and/or reprogrammed, depending on the needs of the user. In this way, the user can alter the logical operation of the spray controller, as well as modify the interaction between the various components of the controller to meet specific application requirements. The invention also relates to a method and system for implementing the physical and logical properties of the spray controller using object-oriented software code, and an interrupt-driven operating system having instructions for processing and interpreting the code to control the various operating parameters of the spraying system.

Specifically, a plurality of software objects are accessible from a function block software library residing within the program memory of a computer by a configuration program/application that executes on the computer. The software objects are implemented as data structures representative of the various physical and logical properties of the spray controller. The configuration program operates to interconnect the plurality of objects to create a desired functional block representation of the spray controller. Once the functional block representation is created, an application file is generated. In one embodiment, the application file is a binary representation of the functional block diagram, and is transferred from the computer to the controller via a remote transfer or other suitable communication channel. The application file is then loaded into the controller memory.

During execution of the controller, a runtime software engine interprets and processes the application file. The runtime engine is an interrupt-driven operating system and environment that executes within the controller. Function block code containing specific instructions for implementing the functionality of the plurality of data structures/software objects is also stored within the controller memory. For each data structure specified in the application file, the runtime engine executes a corresponding set of function block code to perform the specified logical or physical operation of the controller. The runtime engine also facilitates the exchange of commands or data between the various data structures according to uniquely assigned data references and logical address locations. This allows the various data structures and consequently, the various components of the controller, to interact with one another accordingly. In accordance with one feature of the invention, the runtime engine is capable of handling interrupts generated in response to a stimulus detected by a physical component of the spray controller. This allows the controller to experience increased response times to external events.

BRIEF DESCRIPTION OF THE DRAWINGS

While the appended claims set forth the features of the present invention with particularity, the invention, together with its objects and advantages, may be best understood from the following detailed description taken in conjunction with the accompanying drawings of which:

FIG. 1 is a block diagram generally illustrating an exemplary spray controller used in an agricultural application;

FIG. 2 is a diagram illustrating a generalized representation of a function block for implementing the spray controller ofFIG. 1;

FIGS.3(a) through3(d) illustrate exemplary software objects to be used for implementing the functionality of the spray controller ofFIG. 1;

FIG. 4 illustrates a configuration program to be used for creating a functional block representation of the spray controller;

FIG. 5 illustrates a display window initiated by the configuration program ofFIG. 4 for receiving data input from a user;

FIG. 6(a) illustrates the functional block representation created using the configuration program ofFIG. 4;

FIG. 6(b) illustrates a composite block function to be used for creating a functional block representation of the spray controller;

FIG. 7 illustrates the software architecture of the spray controller shown inFIG. 1;

FIG. 8 is a block diagram generally illustrating the primary tasks of a runtime engine according to the present invention;

FIGS.9(a) through9(e) are flowcharts illustrating the logical sequence implemented by the runtime engine to control the behavior of the spray controller;

FIG. 10 is illustrative of two interconnected objects exchanging data in accordance with the invention;

FIG. 11 is a flowchart illustrative of the interrupt processing procedure implemented by the runtime engine; and

FIG. 12 illustrates the interrupt processing procedure ofFIG. 11 with respect to a plurality of interconnected software objects.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

The present invention generally relates to a method and system for implementing the logical and physical operations of an electronic spray controller using object-oriented programming techniques. In this way, the invention provides a convenient way to implement the functionality of an industrial spray controller without knowledge of the underlying complexities of each logical and physical property of the system.

The invention also relates to an interrupt-driven operating system and environment for controlling the various features and mechanisms of the spray controller. As described herein, an electronic spray controller generally relates to a system for controlling and automating the application of fluid in any industrial or agricultural application. Thus, for example, the invention may be used in a control system for applying chemicals and other material resources to plants, crops, shrubbery, foliage, pathways, etc. Those skilled in the art should understand that the invention also extends to other types of spray control systems, such as those used in various other industrial applications such as in the application of paint or other fluids such as resinous compositions and the like.

As described herein, the term “object-oriented programming” (OOP) generally refers to a type of programming that views programs as performing operations on a set of objects. The operations are performed with the use of message passing back and forth between independent objects. In general, the objects themselves correspond to entities, either conceptual or physical, of interest in the spraying system. The concept of an object combines the attributes of procedures and data such that there is a collection of some private data and a set of operations that can access that data. Objects store data in variables and respond to messages by executing procedures or methods.

Accordingly, an object will generally refer to a self-contained software entity that includes both data and procedures to manipulate the data. The properties of an object are defined according to a unique object class, or hierarchy of classes, created by a computer programmer. The class also defines the various interfaces such that, when an object is instantiated, allow the object to exchange data with other objects. The process by which objects may be accessed without knowledge of the internal data and mechanisms of the object is known as data encapsulation. In this way, objects can communicate with other objects according to the methods of that object's interface.

Anexemplary spray controller20, as shown inFIG. 1, includes a plurality of physical and logical properties for implementing its primary tasks and procedures (e.g., via hardware or firmware logic). In accordance with the present invention, a plurality of software objects are configured to represent at least certain of the physical and logical properties. These software objects are stored in a function block library that resides within an accessible storage medium maintained by a computer30 (e.g. core memory, hard disk, etc.). The one or more software objects, referred to also as function blocks, are preferably retrieved from the function block library using a GUI based software application and then logically interconnected to yield a functional block representation of thespray controller20. An application file is then generated from the block representation that can be transferred via acommunication channel33 to the internal controller memory.

Generally, aspray control system20 includes auser interface panel22 for supplying input data and providing various operation parameters. Thepanel22 includes a plurality of input control switches24 such as for regulating material application modes/settings, akeypad26 for user data entry (input), and a digital (LCD)display28 for conveying information to the user (output). Thecontroller20 also has aconnector port32, such as a serial, parallel or infrared port for allowing the data to be exchanged between thecontroller20 and an external computing device such as a personal computer (PC)30. Theconnector port32 provides a general data transfer interface, which allows application data, system logs, and other information related to the spraying system to be easily retrieved from the controller memory (not shown) by thePC30 over acommunication channel33. The data transfer interface also allows program data containing executable instructions related to the operation of the controller to be downloaded from thePC30 over thechannel33, and stored within the controller memory.

Thespray controller20 also comprises

multiple input connectors

34 and36 for communicating with external devices. Such devices may include aflow meter38 for measuring the flow rates of low and high viscosity liquids, apressure sensor40 for detecting liquid pressure, and anoptical sensor42 for monitoring the spray density. Each of the devices can be connected to the spray controller using aconnector cable44, as shown inFIG. 1. Also, an external power supply orbattery source45 can be connected to the controller to provide auxiliary or primary power to thecontroller20 as it is in operation.

Similarly, output devices are connected to the controller viaoutput connector46 and

connector cable

50 and51 to control and regulate liquid outputs. External output devices can include analarm52 or indicator siren/lamp54, apressure regulator56, and a plurality ofvalves58 and relays60 that operate aspray gun62. Overall, the various input and output devices of thespray controller20 interact with each other according to a set of programmed instructions that are stored within the controller memory. These instructions are processed by a central processing unit (CPU) located within the controller circuitry that implements the instructions to control the operation of the spray system.

Those having skill in the art will recognize that the exemplary control system ofFIG. 1 can be designed to exhibit various operation characteristics. For purposes of illustration, however, the overall control system operation is as follows. The user selects setpoints representing a desired flow rate and/or pressure for the fluid to be applied. Upon activation of the spray gun, liquid supplied from a vessel (not shown) is forced through a nozzle (not shown) of the spray gun due to pressurization of the liquid. The flow rate of the liquid may be controlled by a flow control valve and is measured using theflow meter38. The measured flow rate, as well as the detected pressure, are provided as feedback to thecontroller20 and are compared to the selected setpoints. The control valve is then adjusted until the measured flow rate and pressure are equal to the setpoints. Thereafter, these data are used to provide closed loop regulation of flow rate about the selected setpoint once the spray gun is actuated and flow is detected.

In accordance with the present invention, OOP techniques are used to generate computer executable code for implementing the logical and physical operations of the spray controller. This code is interpreted and processed by an interrupt-driven operating system.

In particular, the programmatic instructions that are read frommemory118 and processed by the CPU116 to manage the operation of thecontroller20 are implemented with object-oriented software code. That is, the various logical and arithmetic operations of thecontroller20, and also the characteristics of the physical components of the controller, are defined according to a plurality of software objects. In one embodiment, these objects fall into three main categories, namely input objects, function objects, and output objects. Each object is a software representation corresponding to a physical input component (e.g. a tachometer, a flow meter, a proximity sensor, etc.), a function or algorithm (e.g. add, subtract, alarm function, PID regulation), or a physical output component (e.g., a nozzle, a pressure regulator, an LCD-display).

FIG. 2 shows an abstraction of a function block object or software object120 that is used to build an application program according to the invention. A software object120 is a graphical representation of a function block—a specialized control feature stored within memory of the controller—that corresponds to a specific property of the controller. More specifically, each software object is implemented as a data structure representative of a specific logical or physical component of the controller. The data structure120 comprises different types of data that define its characteristics. This includesinternal data122, which is data that is supplied by the user of thecontroller system20 or the system manufacturer at design time. The internal data of an object is static, and therefore cannot typically be changed during the processing or execution of the data structure120.Internal data122 can include properties specific to the particular hardware component or function represented by the software object120.

By way of example, internal data may include the physical address of an output component (e.g., a flow meter), or a maximum/minimum value of an input or output parameter for a hardware component. Internal data may also include component or application specific instructions and algorithms that are necessary for the proper operation of the controller. For instance, a scaling function, linearization factor or power regulation function may be stored within theinternal data122 to regulate or control the behavior of an actuator. Virtually any data, including algorithms, complex instruction sets, data tables, logical address locations, etc., can be stored asinternal data122 that is associated with a particular software object.

The data structure120 also comprises one ormore input124 andoutput126 lines. These lines are the primary external interface points of the function block120 for receiving and/or transmitting data and commands. The data lines128 receive the data necessary for the object's internal operation, and the data outputs130 yield the output produced by the object as a result of its execution. Likewise,command inputs132 andcommand outputs134 allow commands to be received and events to be triggered by a software object, respectively. The

lines

124 and126 permit commands and data to be stored into, and subsequently retrieved from, the data structure120.

As illustrated inFIG. 2, theinternal data122 varies significantly from theinput data124. Theinternal data122, unlike theinput data124, cannot typically be altered. Rather, the internal data includes information that is specific to the operation of the controller, and thus cannot be changed. Theinput data124, on the other hand, represents data that can be received in various ways, such as from one or more databases that are accessible by thecomputer30, or as a result of direct user input via akeyboard35. As such, theinput data124 may be readily modified or altered to affect thecorresponding output126. Thus, each function block object120, provides a well defined interface for accessing the control features of the controller, while maintaining hidden internal data and algorithms; effectively eliminating the complexity associated with designing a control program for the controller. This aspect of the invention will be discussed in greater detail in later sections of the detailed description. In the following paragraphs, the various software objects or function block objects to be utilized for implementing/programming the physical and logical properties of the controller will be discussed.

Numerous logical functions and physical components may be used to characterize an industrial spray system, including spray nozzles, valves, and timing functions. One example of a commonly used component of an industrial spray system is a Proportional-Integral-Derivative (PID) regulator. PID regulators are used widely within feedback systems for various applications to provide an enhanced level of automated control. In both synchronous and asynchronous control systems, smooth operation, exact precision and relative stability of the system are desired control characteristics. This is especially true in spray control systems, where precision application of material resources to a designated target is desired. To accommodate this level of control, PID regulators include a proportional control factor P, which allows for constant gain control of the system at varying frequencies. Also included is integral control I for improving steady state performance, and derivative control D for enhancing the transient properties of the system. A PID regulator is simply a physical component that operates according to the mathematical control function shown below:
D(s)=K[1+1/T_Is+T_Ds]

D(s)=characteristic transfer function of PID controller

K=gain constant

T_I=integral or reset time

T_D=derivative time

To define the behavior of the PID regulator, the engineer need merely adjust the constants K, T_Iand T_Dto arrive at acceptable performance.

While PID control is of particular interest to the industrial control systems industry, traditional control system programming languages, such as relay ladder logic (RLL), do not offer an easy way to provide PID control. In fact, other more complex repetitive mathematical control functions, such as for time or amplitude scaling, lead or lag compensation, Smith tuning, and/or Ziegler-Nichols functions, are also not easily programmed using conventional languages. Programming a controller using RLL for instance would require the designer to force fit these functions into the ladder design. While an experienced RLL programmer can certainly accomplish this, the time and energy expended would decrease design productivity. In accordance with the invention however, such intricate functions are easily implemented as a plurality of software objects. For example, a software abstraction for aPID regulator140 is shown in FIGS.3(a) and3(c).

The generally simplified PID regulator function block controls the process with an analog output signal (analog output) or with a digital pulse width modulated signal (PWM output). For performing this function, the PID function block scales a received input value (such as a process output) and a target value (a process setpoint) using an input scaling range. The output is scaled in accordance with an output range.

The PID function block also performs various fault operation and detection functions. For example, in one embodiment, a fault signal is generated when the process output does not converge to the setpoint within a preset convergence time. As shown generally inFIG. 3(c), this block may also perform advanced PID features such as proportional (B factor) and differential (C factor) setpoint weighting, feed forward and tracking. In addition, for flow control, this block may receive inhibit input (regulate) to hold the output control signal at a certain value. This prevents the pressure (analog output) from increasing if the spray gun is not spraying. In this example, a flow sensor is used as a process input. In addition, the PID block may operate using a configured period time base.

The PID regulator function block object140 (data structure) comprises multiple input terminals for receiving data, including the proportional (P)142, integral (I)143 and derivative (D)144 control factors for regulating flow control. Other inputs include thereference input value145, the target (desired)value146 that the input is to be regulated to, theinput value range140, and aconverge time input148. The converge time results in afault signal149 being generated in the event that the process output does not converge to a designated setpoint with the specified (converge) time. As another added feature, the fault signal can be set to a specifiedmaximum value150 to vary the level of sensitivity. More advanced PID features, such as a proportional (B factor)151 and differential (C factor)152 setpoint weighting, feed forward153 and tracking154, are conveniently provided as well.

Especially for flow control, the PID has an inhibit input (regulate)164 that can be used to temporarily hold the control signal to a certain level. This can prevent the pressure, oranalog output165, from rising in instances where the PID is used to regulate an inactive but connected output device, such as a spray gun (e.g. by manipulating the analog output range169). A defined period setting167 is also provided, which allows the regulator to operate using a configured period as a time base. The PID regulator object also comprises a PWM (pulse width modulated)output168 to allow for digital signal control. Also, the PID regulator includesinternal data122 including the logical address information of the output value or any special control options.

By design, thePID regulator object140 provides a convenient programming interface for implementing the PID mathematical function shown above (e.g. for altering the K, T_Iand T_Dvalues). In this way, the intricacies of the function itself are hidden from the user, which minimizes the time and skill required to implement PID regulation within thecontroller20. The implementation of the PID regulator described inFIG. 3(a) is only one possible implementation. Indeed, the PID regulator object, and all of the software objects representative of the various aspects of the controller, can be designed to meet specific applications.

FIGS.3(b) and3(d) illustrate anothersoftware object172 corresponding to a commonly used component within aspray controller20, namely, an abstraction of aspray gun62 or a plurality of spray guns such as those arranged in parallel relation. Thespray gun62 serves as the primary mechanism that allows material resources, such as water, paint or fertilizer, to be applied to an intended target (e.g., surface to be painted). Typically, a spray gun includes a plurality of nozzles, valves and pressure regulators, which interact to provide precision spraying capability. The purpose of the spray gun function block is to perform timing control operations of various outputs that drive the spray gun (or several guns in parallel). For performing this function, typically the following actuators are controlled: (1) open-close control of the gun to start or stop spraying such as through a cylinder output or, in the case of electrical operated guns, a PWM signal with fast on-off control may be used to change the liquid flow rate applied by the gun via the PWM bridge output; (2) open-close control for atomizing air such as via an anticipator or follower output; and (3) open-close control for fan air such as through a second anticipator follower output. In accordance with the invention, the spray gun function block handles various timing relating to these outputs. The spray gun block itself contains the hardware specification for the PWM bridge output as an example. Other digital outputs may be connected to the spray gun block when necessary in that, in the preferred embodiment, the spray gun block includes a dedicated command output or outputs for this purpose. Based on a target flow rate and maximum target flow rate input parameters, the spray gun function block calculates the necessary PWM duty cycle.

In summary, the spray gun function block performs the functions of on-off switching of the spray gun based on timing information. In particular, the spray gun function block starts and stops spraying of the gun based on various commands received in the command control input, as shown inFIG. 3(a). The timing is related to the moment of receiving start or stop commands. When a delayed spray command is received, an internal timer may be used to create a delay.

In addition to switching based on timing information, the spray gun function block may perform on-off switching of the spray gun based on distance information. In this instance, the spray gun function block starts and stops the spraying of the gun based on the commands received in the command control input. The timing in this instance is related to the moment of receiving the start or stop command. When a delayed spraying command is received, then a tack-based timer is initiated to create a distance delay. A frequency input (TACHY) is used as a timing reference. In this case, timing is expressed in a number of pulses from the frequency input rather than a number of milliseconds. The spray gun function block performs duty cycle handling of the pulse width modulated (PWM) gun output. To do this, the spray gun function block uses a target flow rate, a maximum flow rate, a minimum duty cycle, a maximum duty cycle, and frequency inputs to calculate the desired duty cycle and frequency to drive the PWM output to the gun.

The spray gun control block performs anticipator follower on-off timing for atomizing in fan air outputs. That is, the spray gun function block uses the anticipator delay parameter T_aand follower delay T_finputs to drive two or more anticipator follower outputs with correct timing information. In other words, the outputs are switched on before the actual gun is switched on (with the delay T_a) and the outputs are switched off after the gun is switched off (with the delay T_f).

The spray gun function block also performs hardware fault checking such as hardware bridge faults, on-off feedback faults, and the like. To perform these functions, the spray gun block checks possible hardware faults in PWM driver circuitry for short circuit or overload conditions, or the like, in the system, as would be understood by those skilled in the art. The spray gun block generates a command that may be used to trigger a screen fault message. There are also on-off feedback faults that may be detected. A switch fault is checked by the spray gun using a switch input and switch time, as shown inFIG. 3(d). This input is active when the spray gun is actually spraying within a time tolerance given by the parameter “switch time.” The switch input may be connected through flow detection sensors which may detect the presence of flow through the spray gun. A valve gun open fault may be checked by the spray gun function block using a “valve gun open input” and “valve gun open time.” These inputs normally follow the PWM signal at the spray gun within a time tolerance given by the input value “valve gun open time.”

For actually implementing the spray gun function block shown inFIG. 3(b), that block may be cascaded with a multi-dimensional table function block. This block may perform various calculations to determine a maximum flow rate for a spray nozzle based on a measured liquid in atomizing air pressure. To perform this function, the multi-dimensional table function block contains a multi-dimensional table and performs an interpolation method in accordance with certain algorithms. By way of example, the interpolation algorithm may be one of the following known algorithms: (1) linear interpolation; (2) “take lower value” methodology; (3) “take higher value” methodology; (4) quadratic interpolation; (5) inverse quadratic interpolation; (6) “polynome through points in the table” interpolation; and (7) “quadratic polynome through three points” interpolation. In the preferred embodiment, different interpolation methods may be used when different dimensions of a performance data table are required. Thus, for example, a linear interpolation may be used for air pressure variations and a quadratic interpolation may be used for liquid pressure variations in certain instances. Table I below illustrates a typical example for the performance data concerning a spray nozzle which is accessed by the multi-dimensional table function block.

In one example, the liquid capacity (in liters per hour) is dependent on liquid pressure and atomizing air pressure. The multi-dimensional table block permits incomplete table values (e.g.,3 points at 0.7 bar liquid pressure exist, while 7 points exist for 1.5 liquid pressure). As noted, the multi-dimensional table is used to calculate the maximum flow rate of a spray nozzle based on the measured liquid and atomizing air pressure. The spray gun object then uses this maximum flow rate value together with the flow rate setpoint value to set a duty cycle output for the gun. The actual applied flow rate is available on the spray gun function block and can be shown on a display.

Another important use of the multi-dimensional table may be to check the performance of a nozzle. In the above example, the flow rate may be calculated based on measured liquid in air pressure. If a flow sensor in the system is then used to calculate actual flow rate, then the calculated flow rate may be compared with the measured flow rate and when the difference exceeds a certain value, an indication is made.

As shown inFIG. 3(d), the spray gun object or block172 includes a plurality ofinput terminals173 including acontrol input171,anticipator time176, andfollower time177. The anticipator time and follower time, as well as thetime delay187 andautostart185 inputs allow data relevant to timing control to be stored into the data structure. Timing can also be set according to an external time base via thetachometer input186,distance delay input188 andmax tachometer speed189 inputs. These various timing inputs influence the two anticipator/follower outputs190, thecylinder output191 and optionally, a pulse width modulated (PWM) output that corresponds to a designated physical address. Also included are inputs necessary for controlling the power usage of the spray gun. For instance, the duty cycle can be controlled manually via theduty cycle input174 and theduty cycle178 range, or automatically using thetarget175 andmax flow rate180 data at a specifiedfrequency179.

Other output parameters for thespray gun object172 include the gun on/offoutputs192,flow rate197,duty cycle198 andstatus output199 for indicating the activity or condition of the spray controller. Also, three different systems for detecting faults within the spray process are provided. These are thebridge fault194,switch fault195 and valve/gunopen fault196.

The fault system outputs operate according to the certain logical conditions. For example, if the hardware detects a short-circuit on the pulse width modulated outputs (e.g., corresponding to the PWM output located at the physical address or for a connected pressure regulator), then abridge fault194 is generated. The system may also utilize theswitch input181 and the switchtime data input182 to generate a fault on the switch fault output. This may occur when the switch input fails to follow the timing and the pulse width generated signal within theset switch time182, then thefault195 is generated. The system also generates a valve/gunopen fault output196 when the valve/gunopen input183 and the valve/gun opentime data input184 are indicative of certain conditions. Such afault196 may be generated when the valve/gunopen input183 does not follow the timing within the set valve/gunopen time184.

In accordance with the invention, the logical conditions described above are not necessarily programmed directly by the spray controller designer, as required by more conventional control system programming languages. The logical conditions themselves can be hidden from the user to ease the task of programming the controller. Theinternal data122, which includes the physical address information and any other special control options, can be set to account for these logical scenarios. By having a singlespray gun object172, the user is able to quickly program the desired applicator characteristics for the controller without having to assemble multiple lines of code, or a plurality of various nozzles, pressure regulators and the like. The user need only enter the applicable input data into the data structure.

ThePID regulator object140, shown inFIG. 3(a), and thespray gun object172 shown in3(b), are two examples of objects used to implement thespray controller20. Of course, numerous other types of software objects may be used to model thespray controller20. This can include, but is not limited to, a parameter object, digital and analog input/output objects, frequency inputs, tables, timing functions, menu line functions, switches, and other functional and physical components. In particular, there are as many software objects as there are physical and logical properties of the spraying system. Those skilled in the art will recognize also that various implementations of the software objects can be abstracted, and that none of the objects illustrated above are meant to be limiting as to the scope of the invention. Because the objects are implemented as data structures, they can be easily modified to accommodate varying application or user specific needs.

The invention has thus far been described with respect to the plurality of software objects that graphically and programmatically represent the logical and physical properties of the system. In order to characterize the system using these objects, an object-oriented software program is used to interconnect the pluralities of software objects in accordance with the intended or desired functionality of the controller. The objects are then executed in accordance with this characterization by the controller. This aspect of the invention is described further in the subsequent paragraphs.

For ensuring the functional interaction of the plurality of objects that comprise the system, the software objects are interconnected using aconfiguration program200, as shown inFIG. 4. In one embodiment, the configuration program is an object-oriented application that executes on thecomputer30, and has facilities for accessing the plurality of software objects from a function block library residing within the memory of the computer, or other storage medium. Theconfiguration program200 has a graphical user interface (GUI) that comprises adrawing board202 which can be spread across multiple pages. The pages are accessed via tabs such astab203 shown inFIG. 4. The configuration program also presents toolbars/palettes for selecting the various types offunction objects204, input objects206, output objects208, andbasic menu items210 for application control. For added convenience, these various toolbars, palettes and controls may be activated using a mouse device, scroll ball, touch pad or standard function keys provided by the keyboard. Any computer operating system having the appropriate APIs and function calls for processing user input commands (e.g. mouse or keyboard entry) and rendering graphics to a computer display screen is suitable for executing the configuration program.

Software objects are selected and then placed on thedrawing board202 and logically interconnected usingconnector lines212 to create afunctional block representation218 of thecontroller20.Connector lines212 are extended between the one or more input/output lines124/126 of the objects being connected, such as by calling the drawline function within the Microsoft Windows operating system. This results in a graphical line being generated on the display, which can be extended and adjusted across the drawing board accordingly using the mouse, or similar cursor placement mechanism.

Thefunctional block representation218 is similar to a circuit diagram, where pluralities of integrated circuits are represented as being connected to each other via signal lines. Because the controller system is represented graphically, the user of the configuration program need not have programming experience to implement the functionality of thecontroller20. The user merely needs a basic knowledge of the features of the controller hardware, and an understanding of the process to be implemented. Unlike some conventional programming methodologies, such as ladder logic, the intricacies of the operation to be executed need not be explicitly programmed by the user. Rather, the plurality of objects made available to the configuration program from the function block library, contain internal mechanisms for performing these operations. This again decreases the amount of time required to generate an operable spray control program.

In an effort to further increase a user's ability to program the controller, theconfiguration program200 also includes various iconographic controls for performing common user tasks. This includes various buttons/controls for opening an existing or saved functional block representation, exporting and importing files between thePC30 and thecontroller20, saving a created representation, and refreshing any file content. Another important feature of the configuration program is the data validation control, which analyzes the data that is provided as input into each object. This feature reduces the time to debug and develop a spray controller program by identifying invalid data, instructions or command inputs instantly. The validation control feature is further explained with reference toFIG. 5.

FIG. 5 shows a display window248 for receiving user input for aspray gun object172. Each of thelines262 anddata fields264 shown in the display window248 corresponds to one or more of the spray gun object input terminals173 (seeFIG. 3(b)). For instance,Line2263 anddata entry field265 correspond to the applicationrate input terminal175 of thespray gun object172. The user enters the data for each input into the corresponding data field(s)264. By activating the validation control, theconfiguration program200 analyzes the data entered, and rejects any invalid input. Theconfiguration program200 can then assign default values automatically, or optionally, alert the user of the configuration program of the changes that are needed. This feature further guides the user during the design process, and enhances ease of use of the configuration program.

With reference now toFIG. 6(a), thefunctional block representation218 as shown on thedrawing board202 ofFIG. 4 is illustrated in greater detail. Each of the software objects are interconnected by extending aconnector line212 from a transmission line220 (e.g. output) to a receiving line222 (e.g., input). Lines are the primary connection points of an object for exchanging data and commands between interconnected objects, and are specifically defined according to the object's interface design. As discussed earlier, each object exposes its internal procedures and data to other objects according to a unique interface. An object interface is created using OOP techniques to correspond to the distinct characteristics of the physical or logical component that the object depicts. Thus, the number of input and output terminals of an object will vary depending on the type of physical or logical component being represented. For example, object224 is a function object for performing division that is comprised of two

input terminals

222 and226. These terminals serve as inputs for receiving a dividend and divider data respectively. However, theanalog input object221,nozzle object223, andparameter object225, also shown in theFIG. 6, comprise only single input terminals due to their differing function and interface design

For defining the intrinsic properties of an object,internal data122 is specified during the creation of thefunctional block representation218 by the user of theconfiguration program200. In other instances, the manufacturer of the spray controller can preset the internal data according to a specific component type or application requirement. This includes data such as theunique name135 of a given object, the maximum/minimum values of any input or output data, any special control options, and other characteristic data. While general object-oriented methods result in the modification or alteration of data during the execution of an object, the internal data remains static throughout. Also, in addition to internal data, each object is assigned one or more unique logical values for being referenced by other objects, and for controlling the flow of data between interconnected objects. Because each object is assigned a unique logical value, data and commands can be easily transferred and received by each object.

Logical addresses

238,239,240 and241 are assigned to

objects

221,225,224 and223 respectively. Preferably, the logical values of an object are assigned automatically by theconfiguration program200, and are hidden from the user during the creation of thefunctional block representation218. By way of example, thedivision object224, specifieslogical address238 for its dividend input ‘a’, and address239 for its divider input ‘b’ (see230). As such, the result ‘r’220 of theanalog input object221 havinglogical address238, and the result ‘r’220 of theparameter object225 havinglogical address239 is provided as input. Likewise, the result ‘r’ of thedivision object224 logically flows into thenozzle object223 as indicated. The logical flow of data between objects is therefore ensured through the assignment of the logical addresses.

In addition to logical address designations, each of the objects that represent hardware must refer to that hardware component with a physical address. The physical address is made up of a circuit board or bus address value and optionally a port number that the corresponding component is physically connected to. Hardware configurations suitable for connecting the external components of thecontroller20 together according to a physical addressing scheme can include, but are not limited to, a CAN (controller area network) interface connector, a signal block device having multiple I/O terminals, a port connector, or any standard bus interface device. By referring to a physical address, each software object representative of hardware can be mapped to its corresponding physical component to allow for its control and manipulation. Preferably, the user specifies the physical addresses during the creation of thefunction block representation218 by selecting them from an address list provided by theconfiguration program200. Alternatively, the addresses can be assigned automatically by the configuration program.

For providing convenient programming of the spray controller, a spray controller configuration wizard may optionally be utilized in conjunction with theconfiguration program200. Commonly used in software applications that employ a GUI, a wizard is a utility associated with an application that helps a user of the application perform a specific task with greater ease. For example, a “letter wizard” within a word processing application leads a user through the steps of producing various types of written correspondence. The user need only provide the basic input parameters and/or input data required to yield the end result (the letter), such as the primary mailing address or recipient information. The wizard typically facilitates the data collection process by prompting the user to enter the data in response to a series of questions. Based on the information provided, and the requirements of the user, the wizard generates the desired user output.

This same approach may also be applied to the design of afunctional block representation218, wherein a wizard guides the user through thespray controller20 configuration process. The wizard obtains basic input information from the user, such as the desired application rate of the controller, pressure and flow rates, etc. The wizard preferably permits user access to a database of nozzle or spray gun characteristics to increase the user's ease of programming. Such characteristics would include application flow/pressure, fluid drop sizes and spray application patterns, pressure/atomizing air pressure, and other basic characteristics, and are commonly available as would be understood by those skilled in the art. The user would simply need to select from the list of available characteristics based on their particular application. This selection process is facilitated using a graphical window, such as a dialog box, having a pull-down menu feature for selecting a desired characteristic. Based on the user selections, the wizard extrapolates the information accordingly and assemble the corresponding functional block representations to achieve the desired result. Such a utility would significantly minimize the time required to design and program complex spray controller systems having multiple control characteristics.

As yet another feature of the invention, theconfiguration program200 provides access to composite function blocks to further speed the control program development process. Composite function blocks are groups of individual function blocks that are interconnected and grouped to represent a single function block. These blocks can either be created by the user, or provided by the function block library by the manufacturer of the spray controller. When the user creates the composite function block, the user has the ability to manipulate the internal connections, data and other pertinent information within the composite function block. In this way, they may develop customized blocks to meet specific control requirements. These blocks can then be assigned a unique function block name, and saved in memory for later usage.

A generalized example ofcomposite function block232 is shown inFIG. 6(b). In this example, objects A242,B243,C244 andD245 are interconnected via their respective input and output lines to provide some logical or physical operation. The composite function block is comprised of

INPUTS

1 and2,250 and251 respectively, as well as OUTPUTS1-3,252-254. As such, the inputs to the various objects that comprise thecomposite function block232, namely256-258, act as inputs for the composite function block as well. The outputs259-261 also define the outputs of the composite function block. Thus, when selecting the composite function block for use in the design of afunctional block representation218, the user need only provide the necessary input and output data to the composite block interface. As discussed previously, the internal complexities of the program (e.g., interconnections of objects A-D) are hidden from the user, making it easier to design a control program. Composite functions blocks enable a modular approach to programming the controller, which significantly advances the ability to design a complete representation of the system.

The function block library, which contains all of the various components of the controller system, can be used in connection with any spray controller system. Regardless of the particular hardware arrangement of the controller, it can be readily programmed using theconfiguration program200 described above as long as a function block library containing the appropriate component implementations/representations and data for the controller is provided. Thus, the configuration program is not limited to any specific spray controller implementation. Rather, the manufacturer of the spray controller can provide the appropriate software objects—implemented as data structures—that correspond to their particular system.

The operation of thecontroller20 is shown inFIG. 7. More specifically, the method of the invention by which thefunctional block representation218 is translated into actual instructions for implementing the functionality of thespray controller20 will be described.

Once a completefunctional block representation218 is formed, anapplication file304 is created, as shown inFIG. 7. Theapplication file304 is a binary version of thefunctional block representation218 that is generated by theconfiguration program200. As a result, the application file specifies all of theobjects305, characteristic data and logical instructions indicated by thefunctional block representation218. The functionality of the controller is therefore defined by the data in theapplication file304. After the application file is generated, it can be easily transferred from thePC30 to thecontroller20 over thecommunication channel33, and stored intocontroller memory118. Alternatively, the application file can be saved to a portable storage medium, such as adiskette31, and then uploaded into thecontroller memory118. Any means by which the file is transferred from thePC30 to thecontroller20 is within the scope of the invention.

According to another aspect of the invention, a run-time engine interprets and processes the data contents (e.g., software objects, internal data, logical instructions) of the application file. The run-time engine300 is an interrupt-driven operating system that executes within thecontroller20. The run-time engine300 acts as the intermediary mechanism that integrates the data and logical instructions contained in theapplication file304 with a set offunction block code306 stored inmemory118. Thefunction block code306 is a collection of programmed instructions that characterize each of the plurality of data structures/software objects305. For each of theobjects305 indicated in theapplication file304, theruntime engine300 executes a corresponding set offunction block code306 that performs the specified logical or physical operation of thecontroller20. The term “set,” as used herein, refers to one or more lines of computer-executable instructions. Each set corresponds to an individual property of the controller. Thus, there are as many sets of function block code as there are logical and physical components that comprise the controller system. This code is created by the controller manufacturer using a high-level programming language such as C, and stored into thecontroller memory118. Overall, the function block code provides the fundamental characteristics of the controller, and is designed to control the input and output characteristics of thecontroller hardware302 directly, or interact with theOS308.

With reference now toFIG. 8, the primary tasks of the runtime engine are shown. In addition to interpreting the contents of theapplication file304, theruntime engine300 is also responsible for initializing400 and executing402 thefunction block code306 corresponding to eachsoftware object305. The runtime engine is also responsible for processing thecommands404 anddata406 specified in theapplication file304. Moreover, theruntime engine300 interacts with the other integral mechanisms of thespray controller20 to provide the various features of the system. One of these mechanisms is the real time operating system (OS)308 of the controller (if present), shown inFIG. 7. Theruntime engine300 can interact with the OS to schedule and synchronize (time)system events408, handleinformation display410, performnetworking capabilities412, and other general computing tasks.

Those skilled in the art will recognize that theruntime engine300 can operate within thecontroller20 independently of the realtime operating system308. The realtime operating system308 need not be present within the controller to carry out the primary functions of theruntime engine300 as described above. However, theruntime engine300 of the present invention is implemented such that the processing, timing, and management activities of the controller can be handled correspondingly in situations where bothsystems300/308 are present; eliminating the need for full conversion of existing systems from one primary system to another. In general, a realtime operating system308 relates to a software driven mechanism that performs basic computing tasks, such as recognizing input from a user keypad, sending output to a display screen, keeping track of files and directories on the within memory, and controlling peripheral devices that are coupled to the system. Theruntime engine300 disclosed herein can perform these basic mechanisms. Moreover, theruntime engine300 is capable of operating in conjunction with the controller CPU to perform its tasks according to relative clock speeds and processing rates.

Flowcharts9(a) and9(b) illustrate the procedural steps taken by theruntime engine300 for performing functionblock code initialization400 and mainloop process execution402. Theinitialization procedure400 is carried out when the user first activates the controller in order to ready the function block code for processing by theruntime engine300. Once the code is initialized, it is executed as often as possible according to themain loop procedure402 of theruntime engine300. Also, flowcharts9(c),9(d) and9(e) show the procedural steps performed by the runtime engine for performingcommand processing404,data processing406 andtiming processing408 respectively.Command processing404 enables the runtime engine to facilitate the exchange of commands between objects indicated in theapplication file304. As discussed previously, objects can send commands to be carried out by other objects by referencing that object. This process allows the objects to interact with one another to trigger external and internal events within the controller. Similarly, the runtime engine is also able to exchange data between objects according to thedata processing procedure406. This process is illustrated by way of example inFIG. 10, which shows two

interconnected objects

500 and506.

As shown,object500 is representative of a menu line function that is displayed to theLCD display28 of the controller. It is comprised of aninput data line502, and an enable input503. Also, themenu line object500 is comprised ofinternal data504, which includes a caption to be written to thedisplay505, display options andsettings507, and numerical settings511. Theconnected object506 is representative of an analog pressure input component comprising asensor span input509, andminimum input value510, and afilter value512 for affecting the actual output of theobject506. Theanalog input object506 also specifiesinternal data514 that defines its intrinsic settings. As illustrated, the input to object500 is provided by theoutput508 ofobject506. Thus, during the execution of the controller, theruntime engine300 requests theoutput value508 of the referencedobject506, checks the validity of the data being obtained, converts the data accordingly, and transfers this information to object500 via theinput data line502. The result, in this example, is the output value of the analog input being printed to thedisplay28 by the display menu function as the pressure in PSI (the information is output to the corresponding physical address of the controller display).

InFIG. 9(e), the procedure carried out by the runtime engine for enablingtiming processing408 is shown. This procedure enables the function block code corresponding to a particular object to be executed at a pre-defined time.

In accordance with one important feature of the invention, the runtime engine is also capable of handling interrupts generated during runtime execution. Referring toFIG. 11, the various software objects that are indicated in the application file are capable of generating events on their own without being called by the runtime engine (e.g., without invoking the corresponding function block code for that object). This behavior is caused by an interrupt that is generated by the CPU (event602) as a result of an external influence (event600) detected by a hardware component of the controller. Such influences can include a specific pressure value detected by apressure sensor40, the value of ananalog input component506, or other detector/sensor components. When an interrupt is generated, the function block code being executed by theruntime engine300 at the time is halted (event604). Then, the function block code for the hardware component that triggered the interrupt is run instead (event606). After its code is fully executed, control is returned back to the halted function block code and execution is resumed immediately (event608). The interrupt handling capability offered by theruntime engine300 allows the controller to respond rapidly to external events (<1 ms response time). Also, the ability to respond to interrupts provides a unique advantage to spraycontrollers20 that employ programmable logic, as this is not present in conventional spraying systems and other PLC devices.

InFIG. 12, a functional block representation613 comprised of three interconnected objects is illustrated to provide an example of the interrupt handling capabilities afforded by theruntime engine300. The three

interconnected objects

610,612 and614 represent a digital input, timer function, and digital output respectively. According to the functional block representation613, thedigital input object610 is capable of receiving commands via itsinput terminals615 for triggering high-to-low616 or low-to-high618 digital input signals. The commands can be received from an external hardware component such as asensor40/42 or auser keypad entry26. When the input signal is indicated as low-to-high618, this phenomenon is indicated to thecontroller20 microprocessor/CPU and an interrupt is generated. As a result, theruntime engine300 in conjunction with the CPU stops its currently running function block code and starts the code for thedigital input object610. As those skilled in the art will appreciate, the code for the object responsible for triggering the interrupt—the digital input in this case—need not be in execution by theruntime engine300 at the time the interrupt is generated. Because of this capability, interrupts can be triggered anytime during the runtime of thecontroller20 without impeding its overall performance and operation.

The logical flow of the functional block representation613 is to thetimer function object612. Once the function block code for thedigital input object610 is started, theruntime engine300 is invoked to relay a START command620 to thetimer object612. The timer is a function object that serves as a timed trigger or release for activating other objects or processes within the controller. Upon execution, the timer function adds the value indicated at itstime connection input622 to the current time recorded since the initial interrupt. This value is then saved in the timer's queue of events. In accordance with the sequential interrupt code indicated inFIG. 11, control is then returned to the program that was running before the interrupt was generated.

Once the amount of time stored in the timer queue has elapsed, an interrupt is again generated and theruntime engine300 executes the timer function block code. The resulting action of the timer in this case is to send an ON command to thedigital output object614. Accordingly, theruntime engine300 executes the function block code for thedigital output timer614, which places the digitaloutput status terminal624 in the ON state. The internal data of thedigital output object626 includes the appropriate information for mapping the software object with its corresponding physical component within the controller circuitry. The result of this particular functional block representation613 when executed by theruntime engine300 is the activation of thedigital output signal614 of thecontroller20.

The example illustrated inFIG. 12 provides only one example of a functional block representation for characterizing the operation of thecontroller system20. One of skill in the art will recognize that various implementations of the controller system are possible, and that the overall interaction between objects is established by the user of the configuration program according to the functional block representation613 and characteristic data provided. Likewise, the interrupt scheme described above provides only a single example of how interrupts can be generated in response to external events, and then handled by theruntime engine300. The interrupt properties of the controller are ultimately dependent upon the characteristics of the microprocessor(s)/CPU associated with the controller, and is not limited to the above-described implementation.

Overall, the invention provides a convenient way for a user to modify or completely redesign the functionality of a spray controller to meet specific design requirements. The usage of a GUI based configuration program provides a higher level of user friendliness, and accommodates those users who have no programming expertise. All that is necessary to program the spray controller is a basic knowledge of the features of the controller hardware, and an understanding of the process or system to be implemented. With this knowledge, the user can easily design afunctional block representation218 of the system to meet their specific requirements. Also, the configuration program can provide default input values for the various objects, and can reject invalid inputs that are entered by the user. This guides the user along during the creation of thefunctional block representation218.

To promote further understanding of the advantages offered by the invention, it is important to clearly distinguish between thefunction block code306 and thefunctional block representation218. Thefunction block code306 provides the actual building blocks that define the intrinsic properties of the spray controller. These building blocks are pre-programmed in the controller, and typically cannot be altered by the user. In contrast, thefunctional block representation218 is a user-defined template that influences how each of the building blocks interact with each other, and the type of data that they require. Without the functional block diagram218, theruntime engine300 cannot execute thefunction block code306 in any meaningful way. Hence, thefunctional block representation218 provides the data and logical instructions needed by thefunction block code306 to ensure that each logical or physical property of thecontroller20 is implemented in a desired way. As those skilled in the art will recognize, this is clearly advantageous over conventional systems where the ability of the user to control, manipulate, or modify the functionality of the controller is limited to only the pre-defined user modes or settings.

Accordingly, an object-oriented environment and system meeting the aforestated objectives has been described. The invention permits a user to readily configure a spray controller without an in-depth knowledge of the programming steps involved. Instead, the user may provide information concerning the process being controlled and the basic features of the hardware being employed. In operation, the application is executed using an interrupt-driven run-time environment to enable the use of lower cost components.

In view of the many possible embodiments to which the principles of this invention may be applied, it should be recognized that the embodiment described herein with respect to the drawing figures is meant to be illustrative only and should not be taken as limiting the scope of invention. For example, those of skill in the art will recognize that the elements of the illustrated embodiment shown in software may be implemented in hardware and vice versa or that the illustrated embodiment can be modified in arrangement and detail without departing from the spirit of the invention. Therefore, the invention as described herein contemplates all such embodiments as may come within the scope of the following claims and equivalents thereof.

Claims

1-17. (canceled)

18. A method for implementing the logical and physical properties of a spray system using an object-oriented configuration program having a graphical user interface, the spray system including a plurality of spray nozzles, a fluid supply, and a spray controller having a processing unit and memory, the memory having stored therein a set of function block code corresponding to each of a plurality of software objects provided by the configuration program, the method comprising the steps of:

placing one or more of the plurality of software objects onto a drawing area provided by the graphical user interface, each object being implemented as a data structure for storing data that characterizes the physical and logical properties of the spraying system;

interconnecting the one or more software objects to create a functional block representation of the spray system; and

generating an application file specifying the one or more data structures, the application file being a binary representation of the functional block representation.

19. The method ofclaim 18 wherein the step of placing includes retrieving the one or more software objects from a function block library that resides within a memory storage medium.

20. The method ofclaim 19 wherein the memory storage medium is accessible by a computer upon which the configuration program is executed.

21. The method ofclaim 18 wherein the step of placing further includes storing characteristic data into the one or more software objects by a user of the configuration program.

22. The method ofclaim 18 further comprising the step of creating a functional block representation using a configuration wizard, the configuration wizard prompting the user of the configuration program for information descriptive of the physical and logical properties of the spray system, the information being extrapolated and interpreted by the wizard to generate a functional block representation of the spray system corresponding to the information provided by the user.

23. A computer-readable medium having computer-executable components comprising:

an object-oriented configuration program having a graphical user interface for developing a functional block representation of a spray system including a plurality of spray nozzles, a fluid supply, and a spray controller having a processing unit and memory, the block representation comprising a plurality of software objects that are interconnected to represent the physical and logical properties of the spray system, each object being implemented as a data structure for storing data that characterizes the physical and logical properties of the spray system; and

a function block library for storing the plurality of software objects, each object being accessible from the library by a user of the configuration program.

24. The computer-readable medium ofclaim 23 further comprising a set of default characteristic data, the characteristic data being supplied to the plurality of software objects by the configuration program for enhancing the ability of the user to create the functional block representation.

25. The computer-readable medium ofclaim 23 wherein the configuration program converts the block representation into a binary application file for being interpreted and executed by a runtime engine residing on the spray system, the application file comprising one or more data structures and associated parameters that are representative of the physical and logical properties of the spray controller.

26. The computer-readable medium ofclaim 23 wherein at least certain of the plurality of software objects stored within the function block library are capable of generating output data in response to a data input, the data being generated during execution of the runtime engine.

27. The computer-readable ofclaim 23 wherein at least certain of the plurality of software objects stored within the function block library are capable of invoking an action to be carried out by the spray controller in response to data representing a command input.

28. The computer-readable medium ofclaim 23 further comprising a runtime engine for execution upon the spray system, the runtime engine having instructions for interpreting and executing the application file generated by the configuration program.

29. The computer-readable medium ofclaim 28 wherein the runtime engine executes a set of function block code corresponding to the one or more data structures and associated parameters that are representative of the physical and logical properties of the spray controller as specified in the application file.

30. The system ofclaim 28 wherein the runtime engine facilitates the exchange of data between one or more of the plurality of software objects according to a unique reference value assigned to the data, the data and corresponding reference value being specified in the application file.

31. The system ofclaim 28 wherein the runtime engine facilitates the exchange of commands between one or more of the plurality of software objects according to a unique reference value assigned to the command, the command and corresponding reference value being specified in the application file.

38. A method for implementing a spray system using a graphical user interface with a plurality of appearance objects, the spray system including a plurality of spray nozzles, a fluid supply, and a spray controller having a processing unit and memory, the memory having stored therein a set of instructions corresponding to each of the plurality of appearance objects, the method comprising the steps of:

placing one or more of the plurality of appearance objects onto an area provided by the graphical user interface, wherein at least one of the appearance objects contains data that characterizes the physical and logical properties of a piping and instrumentation control mechanism;

manipulating the one or more appearance objects to create a functional representation of the spray system;

generating a control program from the functional representation of the spray system; and

executing the control program by the spray controller to operate the spray system.

39. The method ofclaim 38 wherein the step of placing includes retrieving the one or more appearance objects from a function block library that resides within a memory storage medium.

40. The method ofclaim 39 wherein the function block library comprises a plurality software objects, one or more of the software objects representing composite function objects.

41. The method ofclaim 40 wherein the composite function object is comprised of a group of interconnected function objects for representing a specific physical or logical property of the spray controller.

42. The method ofclaim 38 wherein the memory storage medium is accessible by a computer, separate from the spray controller, upon which a configuration program is executed.

43. The method ofclaim 42 further comprising the step of creating a functional block representation using a configuration wizard, the configuration wizard prompting the user of the configuration program for information descriptive of the physical and logical properties of the spray system, the information being extrapolated and interpreted by the wizard to generate a functional block representation of the spray system corresponding to the information provided by the user.