EP1386217A2 - Systeme d'exploitation oriente objet pour regulateur de pulverisation - Google Patents

Systeme d'exploitation oriente objet pour regulateur de pulverisation

Info

Publication number
EP1386217A2
EP1386217A2 EP02769402A EP02769402A EP1386217A2 EP 1386217 A2 EP1386217 A2 EP 1386217A2 EP 02769402 A EP02769402 A EP 02769402A EP 02769402 A EP02769402 A EP 02769402A EP 1386217 A2 EP1386217 A2 EP 1386217A2
Authority
EP
European Patent Office
Prior art keywords
data
spray
objects
controller
application file
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Withdrawn
Application number
EP02769402A
Other languages
German (de)
English (en)
Other versions
EP1386217A4 (fr
Inventor
Hans Saelens
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Spraying Systems Co
Original Assignee
Spraying Systems Co
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Spraying Systems Co filed Critical Spraying Systems Co
Publication of EP1386217A2 publication Critical patent/EP1386217A2/fr
Publication of EP1386217A4 publication Critical patent/EP1386217A4/fr
Withdrawn legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G05—CONTROLLING; REGULATING
    • G05B—CONTROL OR REGULATING SYSTEMS IN GENERAL; FUNCTIONAL ELEMENTS OF SUCH SYSTEMS; MONITORING OR TESTING ARRANGEMENTS FOR SUCH SYSTEMS OR ELEMENTS
    • G05B19/00—Programme-control systems
    • G05B19/02—Programme-control systems electric
    • G05B19/04—Programme control other than numerical control, i.e. in sequence controllers or logic controllers
    • G05B19/042—Programme control other than numerical control, i.e. in sequence controllers or logic controllers using digital processors
    • G05B19/0426—Programming the control sequence
    • B—PERFORMING OPERATIONS; TRANSPORTING
    • B05—SPRAYING OR ATOMISING IN GENERAL; APPLYING FLUENT MATERIALS TO SURFACES, IN GENERAL
    • B05B—SPRAYING APPARATUS; ATOMISING APPARATUS; NOZZLES
    • B05B12/00—Arrangements for controlling delivery; Arrangements for controlling the spray area
    • G—PHYSICS
    • G05—CONTROLLING; REGULATING
    • G05B—CONTROL OR REGULATING SYSTEMS IN GENERAL; FUNCTIONAL ELEMENTS OF SUCH SYSTEMS; MONITORING OR TESTING ARRANGEMENTS FOR SUCH SYSTEMS OR ELEMENTS
    • G05B2219/00—Program-control systems
    • G05B2219/30—Nc systems
    • G05B2219/45—Nc applications
    • G05B2219/45013—Spraying, coating, painting

Definitions

  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • an application file is generated.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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 of FIG. 1;
  • FIGS. 3(a) through 3(d) illustrate exemplary software objects to be used for implementing the functionality of the spray controller of FIG. 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 of FIG. 4 for receiving data input from a user
  • FIG. 6(a) illustrates the functional block representation created using the configuration program of FIG. 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 in FIG. 1;
  • FIG. 8 is a block diagram generally illustrating the primary tasks of a runtime engine according to the present invention
  • FIGS. 9(a) through 9(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;
  • FIG. 12 illustrates the interrupt processing procedure of FIG. 11 with respect to a plurality of interconnected software objects.
  • 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.
  • an electronic spray controller generally relates to a system for controlling and automating the application of fluid in any industrial or agricultural application.
  • the invention may be used in a control system for applying chemicals and other material resources to plants, crops, shrubbery, foliage, pathways, etc.
  • 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.
  • object-oriented programming 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.
  • 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.
  • 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.
  • An exemplary spray controller 20, as shown in FIG. 1, includes a plurality of physical and logical properties for implementing its primary tasks and procedures (e.g., via hardware or firmware logic).
  • 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 computer 30 (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 the spray controller 20.
  • An application file is then generated from the block representation that can be transferred via a communication channel 33 to the internal controller memory.
  • a spray control system 20 includes a user interface panel 22 for supplying input data and providing various operation parameters.
  • the panel 22 includes a plurality of input control switches 24 such as for regulating material application modes/settings, a keypad 26 for user data entry (input), and a digital (LCD) display 28 for conveying information to the user (output).
  • the controller 20 also has a connector port 32, such as a serial, parallel or infrared port for allowing the data to be exchanged between the controller 20 and an external computing device such as a personal computer (PC) 30.
  • PC personal computer
  • the connector port 32 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 the PC 30 over a communication channel 33.
  • the data transfer interface 32 also allows program data containing executable instructions related to the operation of the controller to be downloaded from the PC 30 over the channel 33, and stored within the controller memory.
  • the spray controller 20 also comprises multiple input connectors 34 and 36 for communicating with external devices.
  • Such devices may include a flow meter 38 for measuring the flow rates of low and high viscosity liquids, a pressure sensor 40 for detecting liquid pressure, and an optical sensor 42 for monitoring the spray density.
  • Each of the devices can be connected to the spray controller using a connector cable 44, as shown in FIG. 1.
  • an external power supply or battery source 45 can be connected to the controller to provide auxiliary or primary power to the controller 20 as it is in operation.
  • output devices are connected to the controller via output connectors 46, 48 and connector cable 50 and 51 to control and regulate liquid outputs.
  • External output devices can include an alarm 52 or indicator siren/lamp 54, a pressure regulator 56, and a plurality of valves 58 and relays 60 that operate a spray gun 62.
  • the various input and output devices of the spray controller 20 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.
  • CPU central processing unit
  • the exemplary control system of FIG. 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.
  • 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 the flow meter 38.
  • the measured flow rate, as well as the detected pressure, are provided as feedback to the controller 20 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.
  • 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.
  • the programmatic instructions that are read from memory 118 and processed by the CPU 116 to manage the operation of the controller 20 are implemented with object-oriented software code. That is, the various logical and arithmetic operations of the controller 20, 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, PLD regulation), or a physical output component (e.g., a nozzle, a pressure regulator, an LCD-display).
  • 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, PLD regulation
  • a physical output component e
  • FIG. 2 shows an abstraction of a function block object or software object 120 that is used to build an application program according to the invention.
  • a software object 120 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 structure 120 comprises different types of data that define its characteristics. This includes internal data 122, which is data that is supplied by the user of the controller system 20 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 structure 120. Internal data 122 can include properties specific to the particular hardware component or function represented by the software object 120.
  • 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 the internal data 122 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 as internal data 122 that is associated with a particular software object.
  • the data structure 120 also comprises one or more input 124 and output 126 lines. These lines are the primary external interface points of the function block 120 for receiving and/or transmitting data and commands.
  • the data lines 128 receive the data necessary for the object's internal operation, and the data outputs 130 yield the output produced by the object as a result of its execution.
  • command inputs 132 and command outputs 134 allow commands to be received and events to be triggered by a software object, respectively.
  • the lines 124 and 126 permit commands and data to be stored into, and subsequently retrieved from, the data structure 120. As illustrated in FIG. 2, the internal data 122 varies significantly from the input data 124.
  • the internal data 122 unlike the input data 126, cannot typically be altered.
  • each function block object 120 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.
  • PID Proportional-Integral-Derivative
  • 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.
  • 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.
  • 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).
  • 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 in FIG. 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 function block object 140 (data structure) comprises multiple input terminals 141 for receiving data, including the proportional (P) 142, integral (I) 143 and derivative (D) 144 control factors for regulating flow control.
  • Other inputs include the reference input value 145, the target (desired) value 146 that the input is to be regulated to, the input value range 147, and a converge time input 148.
  • the converge time results in a fault signal 149 being generated in the event that the process output does not converge to a designated setpoint with the specified (converge) time.
  • the fault signal can be set to a specified maximum value 150 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 forward 153 and tracking 154, are conveniently provided as well.
  • 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, or analog output 165, 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 range 169).
  • a defined period setting 167 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) output 168 to allow for digital signal control.
  • the PID regulator includes internal data 122 including the logical address information of the output value or any special control options.
  • the PID regulator object 140 provides a convenient programming interface for implementing the PID mathematical function shown above (e.g. for altering the K, T ⁇ and T D values). 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 the controller 20.
  • the implementation of the PID regulator described in FIG. 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) and 3(d) illustrate another software object 172 corresponding to a commonly used component within a spray controller 20, namely, an abstraction of a spray gun 62 or a plurality of spray guns such as those arranged in parallel relation.
  • the spray gun 62 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).
  • 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).
  • 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.
  • 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.
  • the spray gun function block performs the functions of on-off switching of the spray gun based on timing information.
  • the spray gun function block starts and stops spraying of the gun based on various commands received in the command control input, as shown in FIG. 3(a).
  • the timing is related to the moment of receiving start or stop commands.
  • an internal timer may be used to create a delay.
  • the spray gun function block may perform on-off switching of the spray gun based on distance information.
  • 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.
  • 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 c>cle, 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.
  • the spray gun function block uses the anticipator delay parameter T a and follower delay T f inputs to drive two or more anticipator follower outputs with correct timing information.
  • 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.
  • a switch fault is checked by the spray gun using a switch input and switch time, as shown in FIG. 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 in FIG.
  • 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.
  • the multi-dimensional table function block contains a multi- dimensional table and performs an interpolation method in accordance with certain algorithms.
  • the interpolation algorithm may be one of the following known algorithms: (1) linear inte ⁇ olation; (2) “take lower value” methodology; (3) “take higher value” methodology; (4) quadratic inte ⁇ olation; (5) inverse quadratic inte ⁇ olation; (6) “polynome through points in the table” inte ⁇ olation; and (7) "quadratic polynome through three points" inte ⁇ olation.
  • different inte ⁇ olation methods may be used when different dimensions of a performance data table are required.
  • a linear inte ⁇ olation may be used for air pressure variations and a quadratic inte ⁇ olation may be used for liquid pressure variations in certain instances.
  • Table I illustrates a typical example for the performance data concerning a spray nozzle which is accessed by the multi-dimensional table function block.
  • 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 (in Table I above, 3 points at .7 bar liquid pressure exist, while 7 points exist for 1.5 liquid pressure).
  • 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 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.
  • 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 made.
  • the spray gun object or block 172 includes a plurality of input terminals 173 including a control input 171, anticipator time 176, and follower time 177.
  • the anticipator time and follower time, as well as the time delay 187 and autostart 185 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 the tachometer input 186, distance delay input 188 and max tachometer speed 189 inputs. These various timing inputs influence the two anticipator/follower outputs 190, the cylinder output 191 and optionally, a pulse width modulated (PWM) output that corresponds to a designated physical address 175.
  • PWM pulse width modulated
  • Also included are inputs necessary for controlling the power usage of the spray gun. For instance, the duty cycle can be controlled manually via the duty cycle input 174 and the duty cycle 178 range, or automatically using the target 175 and max flow rate 183 data at a specified frequency 180.
  • Other output parameters for the spray gun object 172 include the gun on/off outputs 192 and status output 199 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 the bridge fault 194, switch fault 195 and valve/gun open fault 196.
  • 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 195 or for a connected pressure regulator), then a bridge fault 194 is generated.
  • the system may also utilize the switch input 181 and the switch time data input 182 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 the set switch time 182, then the fault 195 is generated.
  • the system also generates a valve/gun open fault output 196 when the valve/gun open input 183 and the valve/gun open time data input 184 are indicative of certain conditions.
  • Such a fault 196 may be generated when the valve/gun open input 183 does not follow the timing within the set valve/gun open time 184.
  • 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.
  • the internal data 122 which includes the physical address information and any other special control options, can be set to account for these logical scenarios.
  • the PID regulator object 140 shown in FIG. 3(a), and the spray gun object 172 shown in 3(b), are two examples of objects used to implement the spray controller 20.
  • numerous other types of software objects may be used to model the spray controller 20. 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.
  • 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.
  • 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.
  • the software objects are interconnected using a configuration program 200, as shown in FIG. 4.
  • the configuration program is an object-oriented application that executes on the computer 30, 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.
  • the configuration program 200 has a graphical user interface (GUI) that comprises a drawing board 202 which can be spread across multiple pages. The pages are accessed via tabs such as tab 203 shown in FIG. 4.
  • GUI graphical user interface
  • the configuration program also presents toolbars/palettes for selecting the various types of function objects 204, input objects 206, output objects 208, and basic menu items 210 for application control.
  • 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.
  • Connector lines 212 are extended between the one or more input/output lines 124/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.
  • the functional block representation 218 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 the controller 20. 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.
  • the configuration program 200 also includes various iconographic controls 240 for performing common user tasks. This includes various buttons/controls for opening 242 an existing or saved functional block representation, exporting 244 and importing 246 files between the PC 30 and the controller 20, saving 248 a created representation, and refreshing 250 any file content.
  • Another important feature of the configuration program is the data validation control 252, 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 to FIG. 5.
  • FIG. 5 shows a display window 260 for receiving user input for a spray gun object 172.
  • Each of the lines 262 and data fields 264 shown in the display window 260 corresponds to one or more of the spray gun object input terminals 173 (see FIG. 3(b)).
  • Line2 263 and data entry field 265 correspond to the application rate input terminal 175 of the spray gun object 172.
  • the user enters the data for each input into the corresponding data field(s) 264.
  • the configuration program 200 analyzes the data entered, and rejects any invalid input.
  • the configuration program 200 can then assign default values automatically, or optionally, alert the user of the configuration program of the changes that are needed.
  • each of the software objects are interconnected by extending a connector line 212 from a transmission line 220 (e.g. output) to a receiving line 222 (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.
  • 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.
  • object 224 is a function object for performing division that is comprised of two input terminals 222 and 226. These terminals serve as inputs for receiving a dividend and divider data respectively.
  • analog input object 221, nozzle object 223, and parameter object 225, also shown in the FIG. 6, comprise only single input terminals due to their differing function and interface design
  • internal data 122 is specified during the creation of the functional block representation 218 by the user of the configuration program 200. In other instances, the manufacturer of the spray controller can preset the internal data according to a specific component type or application requirement.
  • Logical addresses 238, 239, 240 and 244 are assigned to objects 221, 225, 224 and 223 respectively.
  • the logical values of an object are assigned automatically by the configuration program 200, and are hidden from the user during the creation of the functional block representation 218.
  • the division object 224 specifies logical address 238 for its dividend input 'a', and address 239 for its divider input 'b' (see 230).
  • the result 'r' 220 of the analog input object 221 having logical address 238, and the result V 220 of the parameter object 225 having logical address 239 is provided as input.
  • the result V of the division object 224 logically flows into the nozzle object 223 as indicated 232.
  • 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 the controller 20 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.
  • a physical address each software object representative of hardware can be mapped to its corresponding physical component to allow for its control and manipulation.
  • the user specifies the physical addresses during the creation of the function block representation 218 by selecting them from an address list provided by the configuration program 200.
  • the addresses can be assigned automatically by the configuration program.
  • a spray controller configuration wizard may optionally be utilized in conjunction with the configuration program 200.
  • a wizard is a utility associated with an application that helps a user of the application perform a specific task with greater ease.
  • 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.
  • a wizard guides the user through the spray controller 20 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.
  • 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.
  • the configuration program 200 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.
  • FIG. 6(b) A generalized example of composite function block 232 is shown in FIG. 6(b).
  • objects A 242, B 243, C 244 and D 245 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 and 2, 250 and 251 respectively, as well as OUTPUTS 1-3, 252-254.
  • the inputs to the various objects that comprise the composite function block 232 namely 256- 258, act as inputs for the composite function block as well.
  • the outputs 259-261 also define the outputs of the composite function block.
  • the internal complexities of the program e.g., interconnections of objects A-D
  • 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 the configuration program 200 described above as long as a function block library containing the appropriate component implementations/representations and data for the controller is provided.
  • 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 the controller 20 is shown in FIG. 7. More specifically, the method of the invention by which the functional block representation 218 is translated into actual instructions for implementing the functionality of the spray controller 20 will be described.
  • an application file 304 is created, as shown in FIG. 7.
  • the application file 304 is a binary version of the functional block representation 218 that is generated by the configuration program 200.
  • the application file specifies all of the objects 305, characteristic data and logical instructions indicated by the functional block representation 218.
  • the functionality of the controller is therefore defined by the data in the application file 304.
  • the application file can be easily transferred from the PC 30 to the controller 20 over the communication channel 33, and stored into controller memory 118.
  • the application file can be saved to a portable storage medium, such as a diskette 31, and then uploaded into the controller memory 118. Any means by which the file is transferred from the PC 30 to the controller 20 is within the scope of the invention.
  • a run-time engine inte ⁇ rets and processes the data contents (e.g., software objects, internal data, logical instructions) of the application file.
  • the run-time engine 300 is an interrupt-driven operating system that executes within the controller 20.
  • the run-time engine 300 acts as the intermediary mechanism that integrates the data and logical instructions contained in the application file 304 with a set of function block code 306 stored in memory 118.
  • the function block code 306 is a collection of programmed instructions that characterize each of the plurality of data structures/software objects 305. For each of the objects 305 indicated in the application file 304, the runtime engine 300 executes a corresponding set of function block code 306 that performs the specified logical or physical operation of the controller 20.
  • set refers to one or more lines of computer-executable instructions. Each set corresponds to an individual property of the controller.
  • function block code is created by the controller manufacturer using a high-level programming language such as C, and stored into the controller memory 118.
  • the function block code provides the fundamental characteristics of the controller, and is designed to control the input and output characteristics of the controller hardware 302 directly, or interact with the OS 308.
  • the runtime engine 300 is also responsible for initializing 400 and executing 402 the function block code 306 corresponding to each software object 305.
  • the runtime engine is also responsible for processing the commands 404 and data 406 specified in the application file 304.
  • the runtime engine 300 interacts with the other integral mechanisms of the spray controller 20 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 in FIG. 7.
  • the runtime engine 300 can interact with the OS to schedule and synchronize (time) system events 408, handle information display 410, perform networking capabilities 412, and other general computing tasks.
  • the runtime engine 300 can operate within the controller 20 independently of the real time operating system 308.
  • the real time operating system 308 need not be present within the controller to carry out the primary functions of the runtime engine 300 as described above.
  • the runtime engine 300 of the present invention is implemented such that the processing, timing, and management activities of the controller can be handled correspondingly in situations where both systems 300/308 are present; eliminating the need for full conversion of existing systems from one primary system to another.
  • a real time operating system 308 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.
  • the runtime engine 300 disclosed herein can perform these basic mechanisms.
  • the runtime engine 300 is capable of operating in conjunction with the controller CPU to perform its tasks according to relative clock speeds and processing rates.
  • Flowcharts 9(a) and 9(b) illustrate the procedural steps taken by the runtime engine 300 for performing function block code initialization 400 and main loop process execution 402.
  • the initialization procedure 400 is carried out when the user first activates the controller in order to ready the function block code for processing by the runtime engine 300. Once the code is initialized, it is executed as often as possible according to the main loop procedure 402 of the runtime engine 300.
  • flowcharts 9(c), 9(d) and 9(e) show the procedural steps performed by the runtime engine for performing command processing 404, data processing 406 and timing processing 408 respectively.
  • Command processing 404 enables the runtime engine to facilitate the exchange of commands between objects indicated in the application file 304.
  • object 500 is representative of a menu line function that is displayed to the LCD display 28 of the controller. It is comprised of an input data line 502, and an enable input 503. Also, the menu line object 500 is comprised of internal data 504, which includes a caption to be written to the display 505, display options and settings 507, and numerical settings 509.
  • the connected object 506 is representative of an analog pressure input component comprising a sensor span input 509, and minimum input value 510, and a filter value 512 for affecting the actual output of the object 506.
  • the analog input object 506 also specifies internal data 514 that defines its intrinsic settings.
  • the input to object 500 is provided by the output 508 of object 506.
  • the runtime engine 300 requests the output value 508 of the referenced object 506, checks the validity of the data being obtained, converts the data accordingly, and transfers this information to object 500 via the menu line object 502.
  • the result in this example, is the output value of the analog input being printed to the display 28 by the display menu function 502 as the pressure in PSI (the information is output to the corresponding physical address of the controller display).
  • FIG. 9(e) the procedure carried out by the runtime engine for enabling timing processing 408 is shown. This procedure enables the function block code corresponding to a particular object to be executed at a pre-defined time.
  • the runtime engine is also capable of handling interrupts generated during runtime execution.
  • 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 (event 602) as a result of an external influence (event 600) detected by a hardware component of the controller.
  • Such influences can include a specific pressure value detected by a pressure sensor 40, the value of an analog input component 506, or other detector/sensor components.
  • the function block code for the hardware component that triggered the interrupt is run instead (event 606). After its code is fully executed, control is returned back to the halted function block code and execution is resumed immediately (event 608).
  • the interrupt handling capability offered by the runtime engine 300 allows the controller to respond rapidly to external events ( ⁇ 1ms response time). Also, the ability to respond to interrupts provides a unique advantage to spray controllers 20 that employ programmable logic, as this is not present in conventional spraying systems and other PLC devices.
  • a functional block representation 613 comprised of three interconnected objects is illustrated to provide an example of the interrupt handling capabilities afforded by the runtime engine 300.
  • the three interconnected objects 610, 612 and 614 represent a digital input, timer function, and digital output respectively.
  • the digital input object 610 is capable of receiving commands via its input terminals 615 for triggering high-to-low 616 or low-to-high 618 digital input signals.
  • the commands 615 can be received from an external hardware component such as a sensor 40/42 or a user keypad entry 26.
  • the input signal is indicated as low-to-high 618, this phenomenon is indicated to the controller 20 microprocessor/CPU and an interrupt is generated.
  • the runtime engine 300 in conjunction with the CPU stops its currently running function block code and starts the code for the digital input object 610.
  • the code for the object responsible for triggering the interrupt need not be in execution by the runtime engine 300 at the time the interrupt is generated. Because of this capability, interrupts can be triggered anytime during the runtime of the controller 20 without impeding its overall performance and operation.
  • the logical flow of the functional block representation 613 is to the timer function object 612.
  • the runtime engine 300 is invoked to relay a START command 620 to the timer object 612.
  • the timer is a function object that serves as a timed trigger or release for activating other objects or processes within the controller.
  • the timer function adds the value indicated at its time connection input 622 to the current time recorded since the initial interrupt. This value is then saved in the timer's queue of events.
  • control is then returned to the program that was running before the interrupt was generated.
  • an interrupt is again generated and the runtime engine 300 executes the timer function block code.
  • the resulting action of the timer in this case is to send an ON command to the digital output object 614.
  • the runtime engine 300 executes the function block code for the digital output timer 614, which places the digital output status terminal 624 in the ON state.
  • the internal data of the digital output object 626 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 representation 613 when executed by the runtime engine 300 is the activation of the digital output signal 614 of the controller 20.
  • FIG. 12 provides only one example of a functional block representation for characterizing the operation of the controller system 20.
  • 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 representation 613 and characteristic data provided.
  • 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 the runtime engine 300.
  • 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.
  • 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 a functional block representation 218 of the system to meet their specific requirements.
  • 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 the functional block representation 218.
  • the function block code 306 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.
  • the functional block representation 218 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 diagram 218, the runtime engine 300 cannot execute the function block code 306 in any meaningful way.
  • the functional block representation 218 provides the data and logical instructions needed by the function block code 306 to ensure that each logical or physical property of the controller 20 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.
  • 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.

Abstract

L'invention concerne un procédé et un système pour mettre en oeuvre un régulateur de pulvérisation, faisant appel à un code de logiciel orienté objet et à un système d'exploitation guidé par interruption pour le traitement et l'interprétation dudit code.
EP02769402A 2001-05-09 2002-05-09 Systeme d'exploitation oriente objet pour regulateur de pulverisation Withdrawn EP1386217A4 (fr)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US28983001P 2001-05-09 2001-05-09
US289830P 2001-05-09
PCT/US2002/014873 WO2002091134A2 (fr) 2001-05-09 2002-05-09 Systeme d'exploitation oriente objet pour regulateur de pulverisation

Publications (2)

Publication Number Publication Date
EP1386217A2 true EP1386217A2 (fr) 2004-02-04
EP1386217A4 EP1386217A4 (fr) 2008-11-26

Family

ID=23113287

Family Applications (1)

Application Number Title Priority Date Filing Date
EP02769402A Withdrawn EP1386217A4 (fr) 2001-05-09 2002-05-09 Systeme d'exploitation oriente objet pour regulateur de pulverisation

Country Status (6)

Country Link
EP (1) EP1386217A4 (fr)
JP (1) JP2004534997A (fr)
AU (1) AU2002340972A1 (fr)
BR (1) BRPI0206342A2 (fr)
CA (1) CA2432191C (fr)
WO (1) WO2002091134A2 (fr)

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
FR2922651B1 (fr) * 2007-10-17 2010-03-19 Millipore Corp Systeme d'analyse microbiologique
FR2922453B1 (fr) 2007-10-17 2011-01-14 Millipore Corp Procede de decontamination et systeme le mettant en oeuvre

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO1999060487A1 (fr) * 1998-05-15 1999-11-25 Tridium, Inc. Systeme et procedes de commande orientee objet de divers systemes electromecaniques utilisant un reseau informatique

Family Cites Families (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5576946A (en) * 1993-09-30 1996-11-19 Fluid Air, Inc. Icon based process design and control system
US5591409A (en) * 1995-08-15 1997-01-07 Watkins; Carl J. Providing aromas
US6282458B1 (en) * 1996-09-17 2001-08-28 Ricoh Company, Ltd. Methods and systems for controlling olfactory stimuli
US6445969B1 (en) * 1997-01-27 2002-09-03 Circuit Image Systems Statistical process control integration systems and methods for monitoring manufacturing processes
US5927603A (en) * 1997-09-30 1999-07-27 J. R. Simplot Company Closed loop control system, sensing apparatus and fluid application system for a precision irrigation device
US6460070B1 (en) * 1998-06-03 2002-10-01 International Business Machines Corporation Mobile agents for fault diagnosis and correction in a distributed computer environment
US6199000B1 (en) * 1998-07-15 2001-03-06 Trimble Navigation Limited Methods and apparatus for precision agriculture operations utilizing real time kinematic global positioning system systems
US6345212B1 (en) * 1998-11-20 2002-02-05 Manufacturing Data Systems, Inc. Automatic variable linkage mechanism for integrating third party software components
WO2001030404A1 (fr) * 1999-10-29 2001-05-03 E. One Co., Ltd. Procede et dispositif de diffusion d'odeurs

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO1999060487A1 (fr) * 1998-05-15 1999-11-25 Tridium, Inc. Systeme et procedes de commande orientee objet de divers systemes electromecaniques utilisant un reseau informatique

Non-Patent Citations (3)

* Cited by examiner, † Cited by third party
Title
JOBLING C P ET AL: "Object-oriented programming in control system design: a survey" AUTOMATICA UK, vol. 30, no. 8, August 1994 (1994-08), pages 1221-1261, XP002499886 ISSN: 0005-1098 *
See also references of WO02091134A2 *
SUH S-H ET AL: "PROTOTYPE INTEGRATED ROBOTIC PAINTING SYSTEM: SOFTWARE AND HARDWARE DEVELOPMENT" JOURNAL OF MANUFACTURING SYSTEMS, SOCIETY OF MANUFACTURING ENGINEERS, DEARBORN, MI, US, vol. 12, no. 6, 1 January 1993 (1993-01-01), pages 463-473, XP000448773 ISSN: 0278-6125 *

Also Published As

Publication number Publication date
WO2002091134A2 (fr) 2002-11-14
CA2432191C (fr) 2011-03-15
BRPI0206342A2 (pt) 2016-10-25
WO2002091134A8 (fr) 2003-12-24
CA2432191A1 (fr) 2002-11-14
JP2004534997A (ja) 2004-11-18
EP1386217A4 (fr) 2008-11-26
WO2002091134A3 (fr) 2003-07-31
AU2002340972A1 (en) 2002-11-18

Similar Documents

Publication Publication Date Title
US7024285B2 (en) Object-oriented operating system for a spray controller
CN101995860B (zh) 使用模板的系统配置
CA2222235C (fr) Systemes de commande de mouvement
US5801942A (en) Process control system user interface including selection of multiple control languages
US5862052A (en) Process control system using a control strategy implemented in a layered hierarchy of control modules
US8151196B2 (en) Abstracted display building method and system
US7509249B2 (en) Event-driven component mirroring method and system
US8898123B2 (en) Method and system for interface configuration via device-side scripting
US8639491B2 (en) Emulator for general purpose viewer configurable interface
US8918733B2 (en) Interface method and system for enhanced data and memory management
US20020013629A1 (en) Process control system using a process control strategy distributed among multiple control elements
US20120041570A1 (en) Efficient Design and Configuration of Elements in a Process Control System
US20060095855A1 (en) HMI reconfiguration method and system
US20040148037A1 (en) System and method for model based control of a mechanical device
JP4628634B2 (ja) 汎用運動制御システム
US20080004744A1 (en) Method for Adapting Parameters of a Control or Regulating Device
CA2432191C (fr) Systeme d'exploitation oriente objet pour regulateur de pulverisation
US7574267B2 (en) Controller for a machine-tool or production machine
CN111344642B (zh) 计算机支持地提供计算机代码形式的信息的方法和设备
Wang et al. Time Windows: Automated Abstraction of Continuous-Time Models into Discrete-Event Models in High Autonomy Systems∗
CN111308961A (zh) 一种运动控制器的人机界面组态开发方法
Diedrich et al. Field device integration in DCS engineering using a device model
EP3889700A1 (fr) Systèmes et procédés de fonctionnement et de conception de système industriel
Weber Applying visual basic for human machine interface applications
Bader Utilizing multi-language international software standards for distributed process control

Legal Events

Date Code Title Description
PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

17P Request for examination filed

Effective date: 20031127

AK Designated contracting states

Kind code of ref document: A2

Designated state(s): AT BE CH CY DE DK ES FI FR GB GR IE IT LI LU MC NL PT SE TR

AX Request for extension of the european patent

Extension state: AL LT LV MK RO SI

RIN1 Information on inventor provided before grant (corrected)

Inventor name: SAELENS, HANS

A4 Supplementary search report drawn up and despatched

Effective date: 20081028

17Q First examination report despatched

Effective date: 20090115

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE APPLICATION IS DEEMED TO BE WITHDRAWN

18D Application deemed to be withdrawn

Effective date: 20090526