System and method for programming a logic control unit

Abstract

A system and process for generating a control program for execution by a programmable logic control unit including the steps of: providing a variable editing user interface allowing a user to define and edit variables including input variables and output variables; providing a program level editing user interface allowing the user to edit a program level; providing a state editing user interface allowing a user to define and edit a plurality of states of the control program; providing a condition editing user interface allowing a user to define and edit at least one condition for each of the states of the control program; and generating the control program as a function of associative relationships of the variables, states, and conditions.

Claims

What is claimed is:

1. A process for generating a control program for execution by a programmable logic control unit having a plurality of input ports for receiving input signals from components of an external system under control, and a plurality of output ports for providing output signals to components of the external system, the program listings being easily read and understood by one not trained in the arts of software engineering, comprising the steps of:

(ai) providing a variable editing user interface allowing a user to select and edit existing variables stored in a file and including input variables associated with corresponding ones of the input signals, and output variables associated with corresponding ones of the output signals, and to define new variables;

(aii) displaying a list of previously defined variables;

(aiii) selecting a type of variable from a predetermined set of types of variables;

(aiv) selecting and editing an existing variable of the selected type, or defining a new variable of the selected type by entering a variable name identifying the variable, and specifying particular characteristics of the new variable; and

(av) storing the edited or defined variable in said file and returning to step (aii) until all desired variables have been edited and/or defined;

(bi) providing a program level editing user interface allowing the user to edit a program level stored in said file, said program level including a plurality of states defining a sub-process of said control program for asynchronous execution by the programmable control unit, or to define a new program level;

(bii) selecting and editing an existing program level, or defining a new program level by assigning a level value, level type and level description thereto; and

(biii) storing the edited or new program level in said file and returning to step (bii) until all desired program levels have been edited and/or defined;

(ci) providing a state editing user interface allowing a user to select and edit an existing state stored in said file, or to define a new state having at least one variable associated therewith, said variable being assigned a data value upon transition of said control program to the corresponding state during execution of said control program by the programmable control unit;

(cii) selecting and editing an existing state, or defining a new state and assigning at least one variable thereto; and

(ciii) storing the edited or new state in said file;

(di) providing a condition editing user interface allowing a user to select and edit a condition associated with a particular state and stored in said file, or to add a new condition to a selected state said condition specifying a transition from an associated state as a source state to a corresponding selected destination state upon satisfaction of said condition during execution of said control program by the programmable control unit;

(dii) selecting a stored condition for editing, or defining a new condition for a particular state by assigning thereto a condition address, a condition name, a destination state address, and a destination state name, said destination address specifying, for said condition, a transition from its associated state, as a source state, to a selected destination state when said condition is true during execution of said control program; and

(diii) storing said edited or new condition in said file; and

(e) generating said control program as a function of the associative relationships of said stored variables, states, and conditions stored in said file.

2. A process for generating a control program as recited in claim 1 wherein said program levels include:

at least one task program level; and

at least one subroutine program level which may be called by a corresponding calling program level having a plurality of states, said plurality of states of said corresponding calling program level including at least one state having a call condition associated therewith, said call condition specifying a transition from an associated state of a calling program level to a corresponding selected destination state of a corresponding subroutine program level;

said plurality of states of said corresponding subroutine program level including at least one state having a return condition associated therewith, said return condition specifying that said control program is to transition to a return state of said corresponding calling program level upon satisfaction of said return condition during execution of said control program.

3. A process for generating a control program as recited in claim 2 wherein a return state is indicated by a return state field associated with a calling condition of a corresponding calling program level.

4. A process for generating a control program as recited in claim 2 wherein each said subroutine program level and said corresponding calling program level are executed by the programmable control unit in a single thread.

5. A process for generating a control program as recited in claim 1 wherein:

each of said program levels has a program level value field associated therewith, said program level value field for carrying a value uniquely identifying said program level;

each of said states of each said program level has a state address field associated therewith for carrying a state address defined by a program level value of a corresponding program level, and a state value uniquely identifying said state; and

each of said conditions has a condition field associated therewith, each said condition field including,

a condition address field for carrying a condition address indicative of said condition, said condition address being formed by the program level value of a corresponding program level, the state value of a corresponding state, and a condition value uniquely identifying the condition, and

a destination state address field carrying the state address of the selected destination state to which said process is to transition if the condition is determined to be true during execution of the control program by the programmable control unit.

6. A process for generating a control program as recited in claim 5 wherein:

each said program level has a program level name field associated therewith for receiving a user specified character string descriptive thereof;

each said state of each said program level has a state name field associated therewith for receiving a user specified character string descriptive thereof; and

each said condition field further includes a condition name field for receiving a user specified character string descriptive thereof.

7. A process for generating a control program as recited in claim 5 wherein said state values and said condition values are automatically generated sequentially by said process as the user defines said states and said conditions via said state editing user interface and said condition editing user interface respectively.

8. A process for generating a control program as recited in claim 1 wherein said set of types of variables includes memory location variables including:

at least one program variable for which an associated program variable data field is to be allocated by said programmable control unit upon execution of said control program; and

at least one digital variable for which an associated digital variable data field is to be allocated by said programmable control unit upon execution of said control program.

9. A process for generating a control program as recited in claim 1 wherein said input variables include

analog input variables associated with corresponding analog input signals received from corresponding ones of said components of said external system; and

digital input variables associated with corresponding digital input signals received from corresponding ones of said components of said external system.

10. A process for generating a control program as recited in claim 1 wherein said output variables include

analog output variables associated with corresponding analog output signals provided to corresponding ones of said components of said external system; and

digital output variables associated with corresponding digital output signals provided to corresponding ones of said components of said external system.

11. A process for generating a control program as recited in claim 1 wherein said conditions include condition statements for determining whether a transition from an associated source state to a corresponding destination state is to occur, said condition statements including check-state condition statements specifying that a selected check state and a source state must be active for the associated condition to be satisfied, the selected check state and source state being associated with different ones of said program levels.

12. A process for generating a control program as recited in claim 1 wherein selected limited ones of the program levels are limited to be executed by the programmable control unit only when corresponding selected limiting states are active, each said limiting state being associated with a program level other than the corresponding limited program level.

13. A process for generating a control program as recited in claim 1 wherein said program levels include at least one task program level.

14. A process for generating a control program as recited in claim 1 wherein said program levels include:

at least one subroutine program level which may be called by a corresponding calling program level having a plurality of states, said plurality of states of said corresponding calling program level including at least one state having a call condition associated therewith, said call condition specifying a transition from an associated state of a calling program level to a corresponding selected destination state of a corresponding subroutine program level;

said plurality of states of said corresponding subroutine program level including at least one state having a return condition associated therewith, said return condition specifying that said control program is to transition to a return state of said corresponding calling program level upon satisfaction of said return condition during execution of said control program.

15. A process for generating a control program as recited in claim 1 wherein said program levels include at least one task program level.

16. A process for generating a control program as recited in claim 1 wherein said program levels include:

at least one subroutine program level which may be called by a corresponding calling program level having a plurality of states, said plurality of states of said corresponding calling program level including at least one state having a call condition associated therewith, said call condition specifying a transition from an associated state of a calling program level to a corresponding selected destination state of a corresponding subroutine program level;

said plurality of states of said corresponding subroutine program level including at least one state having a return condition associated therewith, said return condition specifying that said control program is to transition to a return state of said corresponding calling program level upon satisfaction of said return condition during execution of said control program.

17. A process for generating a control program as recited in claim 1 wherein said variables include

analog input variables, analog output variables, digital input variables, digital output variables, program variables, digital variables, panel light-emitting diode (panel LED) variables, panel switch variables, timer variables, and proportional integral derivative (PID) variables.

18. A process for generating a control program as recited in claim 1 wherein said program level value and state name are numerical values, and further comprising the step of;

generating a flow chart having a left hand column and a right hand column, the left hand column listing in order according to program level value and state name each odd numbered state and its associated conditions, and the right hand column listing in order according to program level value and state name each even numbered state and its associated conditions, the associative relationships between the several states and conditions being indicated by connecting lines.

19. A process for generating a control program as recited in claim 18 wherein each said state is identified by a unique pair of numbers the first of which indicates program level and the second of which indicates state name.

20. A process for generating a control program as recited in claim 19 wherein each said condition is identified by a unique set of at least three numbers the first of which indicates program level, the second of which indicates state name, and the third of which indicates condition name.

21. A machine readable storage device having stored therein encoding instructions for executing a process for generating a control program for execution by a programmable control unit having a plurality of input ports for receiving input signals from components of an external system under control, and a plurality of output ports for providing output signals to components of the external system, the program listings being easily read and understood by one not trained in the arts of software engineering, said process comprising the steps of:

(ai) providing a variable editing user interface allowing a user to select and edit existing variables stored in a file and including input variables associated with corresponding ones of the input signals, and output variables associated with corresponding ones of the output signals, and to define new variables;

(aii) displaying a list of previously defined variables;

(aiii) selecting a type of variable from a predetermined set of types of variables;

(aiv) selecting and editing an existing variable of the selected type, or defining a new variable of the selected type by entering a variable name identifying the variable, and specifying particular characteristics of the new variable; and

(av) storing the edited or defined variable in said file and returning to step (aii) until all desired variables have been edited and/or defined;

(bi) providing a program level editing user interface allowing the user to edit a program level stored in said file, said program level including a plurality of states defining a sub-process of said control program for asynchronous execution by the programmable control unit, or to define a new program level;

(bii) selecting and editing an existing program level, or defining a new program level by assigning a level value, level type and level description thereto; and

(biii) storing the edited or new program level in said file and returning to step (bii) until all desired program levels have been edited and/or defined;

(ci) providing a state editing user interface allowing a user to select and edit an existing state stored in said file, or to define a new state having at least one variable associated therewith said variable being assigned a at a value upon transition of said control program to the corresponding state during execution of said control program by the programmable control unit;

(cii) selecting and editing an existing state, or defining a new state and assigning at least one variable thereto; and

(ciii) storing the edited or new state in said file;

(di) providing a condition editing user interface allowing a user to select and edit a condition associated with a particular state and stored in said file, or to add a new condition to a selected state said condition specifying a transition from an associated state as a source state to a corresponding selected destination state upon satisfaction of said condition during execution of said control program by the programmable control unit;

(dii) selecting a stored condition for editing, or defining a new condition for a particular state by assigning thereto a condition address, a condition name, a destination state address, and a destination state name, said destination address specifying, for said condition, a transition from its associated state, as a source state, to a selected destination state when said condition is true during execution of said control program; and

(diii) storing said edited or new condition in said file; and

(e) generating said control program as a function of the associative relationships of said stored variables, states, and conditions stored in said file.

22. A machine readable storage device having stored therein encoding instructions for executing a process for generating a control program as recited in claim 21 wherein said program levels include: at least one task program level; and at least one subroutine program level which may be called by a corresponding calling program level having a plurality of states, said plurality of states of said corresponding calling program level including at least one state having a call condition associated therewith, said call condition specifying a transition from said associated state of a calling program level to a corresponding selected destination state of a corresponding subroutine program level: said plurality of states of said corresponding subroutine program level including at least one state having a return condition associated therewith, said return condition specifying that said control program is to transition to a return state of a corresponding calling program level upon satisfaction of said return condition during execution of said control program.

23. A machine readable storage device having stored therein encoding instructions for executing a process for generating a control program as recited in claim 22 wherein a return state is indicated by a return state field associated with a calling condition of a corresponding calling program level.

24. A machine readable storage device having stored therein encoding instructions for executing a process for generating a control program as recited in claim 22 wherein each said subroutine program level and said corresponding calling program level are executed by the programmable control unit in a single thread.

25. A machine readable storage device having stored therein encoding instructions for executing a process for generating a control program as recited in claim 21 wherein:

each of said program levels has a program level value field associated therewith, said program level value field for carrying a value uniquely identifying said program level;

each of said states of each said program level has a state address field associated therewith for carrying a state address defined by a program level value of a corresponding program level, and a state value uniquely identifying said state; and

each of said conditions has a condition field associated therewith, each said condition field including,

a condition address field for carrying a condition address indicative of said condition, said condition address being formed by the program level value of a corresponding program level, the state value of a corresponding state, and a condition value uniquely identifying the condition, and

a destination state address field carrying the state address of the selected destination state to which said process is to transition if the condition is determined to be true during execution of the control program by the programmable control unit.

26. A machine readable storage device having stored therein encoding instructions for executing a process for generating a control program as recited in claim 21 wherein:

each said program level has a program level name field associated therewith for receiving a user specified character string descriptive thereof;

each said state of each said program level has a state name field associated therewith for receiving a user specified character string descriptive thereof said corresponding state; and

each said condition field further includes a condition name field for receiving a user specified character string descriptive thereof.

27. A machine readable storage device having stored therein encoding instructions for executing a process for generating a control program as recited in claim 21 wherein said state values and said condition values are automatically generated sequentially by said process as the user defines said states and said conditions via said state editing user interface and said condition editing user interface respectively.

28. A machine readable storage device having stored therein encoding instructions for executing a process for generating a control program as recited in claim 21 wherein said set of types of variables includes memory location variables including:

at least one program variable for which an associated program variable data field is to be allocated by said programmable control unit upon execution of said control program; and

at least one digital variable for which an associated digital variable data field is to be allocated by said programmable control unit upon execution of said control program.

29. A machine readable storage device having stored therein encoding instructions for executing a process for generating a control program as recited in claim 21 wherein said input variables include:

analog input variables associated with corresponding analog input signals received from corresponding ones of said components of said external system; and

digital input variables associated with corresponding digital input signals received from corresponding ones of said components of said external system.

30. A machine readable storage device having stored therein encoding instructions for executing a process for generating a control program as recited in claim 21 wherein said output variables include:

analog output variables associated with corresponding analog output signals provided to corresponding ones of said components of said external system; and

digital output variables associated with corresponding digital output signals provided to corresponding ones of said components of said external system.

31. A machine readable storage device having stored therein encoding instructions for executing a process for generating a control program as recited in claim 21 said conditions include condition statements for determining whether a transition from an associated source state to a corresponding destination state is to occur, said condition statements including check-state condition statements specifying that a selected check state and a source state must be active for the associated condition to be satisfied, the selected check state and source state being associated with different ones of said program levels.

32. A machine readable storage device having stored therein encoding instructions for executing a process for generating a control program as recited in claim 21 wherein selected limited ones of the program levels are limited to be executed by the programmable control unit only when corresponding selected limiting states are active, each said limiting state being associated with a program level other than the corresponding limited program level.

33. A machine readable storage device having stored therein encoding instructions for executing a process for generating a control program as recited in claim 21 wherein said variables include analog input variables, analog output variables, digital input variables, digital output variables, program variables, digital variables, panel light-emitting diode (panel LED) variables, panel switch variables, timer variables, and proportional integral derivative (PID) variables.

Description

BACKGROUND OF THE INVENTION

1. Field of the Invention

This invention relates generally to systems and methods for configuring logic control units in distributed process control systems, and more particularly to a computer implemented programming process used to program a logic control unit based on a form of state machine theory.

2. Description of the Prior Art

Distributed process control systems are widely used in many applications including machine tools, material handling, assembling systems, molding and casting machines, and robotics systems. Such systems typically include a logic control unit (LCU) such as a commercially available programmable logic controller (PLC) which is a specialized data processor. A PLC typically includes a plurality of input ports for receiving analog and digital input signals from components of the system under control, a plurality of output ports providing digital and analog output signals to components of the system, a microprocessor, and memory for storing a control program. The PLC operates by repetitively scanning the signals present at the input ports to determine input data, analyzing the input data using the control program stored in memory to determine the corresponding output data, and providing output signals based on the output data at the output ports in order to control the system.

In accordance with one prior art method for configuring a PLC, a control program is created using a "ladder logic" programming method. A ladder logic program typically includes a plurality or ladder logic statements commonly referred to as "rungs". Each ladder logic statement defines a relationship between variables such as between an output variable and an input variable. A simple ladder logic statement might indicate that a particular output variable is ON if and only if variables A and B are both ON. For easier comprehension by ladder logic programmers, ladder logic editors use ladder logic statements, and programs are often expressed in terms of ladder logic graphs including input symbols, line segments, and variable names.

Ladder logic programs are created and edited using a programming computer system separate from the PLC such as a personal computer or mini computer. A complete ladder logic program is recorded on magnetic tape or disk, and uploaded from the programming computer system into the memory of the PLC.

An important problem with prior art methods for programming logic control units, such as those using a ladder logic editor, is that a skilled ladder logic programmer is needed to create a ladder logic program. In accordance with a typical prior art PLC development cycle, development begins with a hardware applications engineer who designs and builds the hardware for the system under control. A PLC programmer then interfaces with the hardware application engineer who describes specifications of the system to the programmer. The programmer then begins software development. Typically the hardware engineer cannot read the ladder logic program listing either in the form of ladder logic instructions or in the ladder logic graph form. Therefore it is common that numerous problems with the control system are discovered by the hardware engineer only after executing the software over the PLC. When the application engineer begins to evaluate the performance of the system as controlled by the configured PLC, the engineer determines problems with the system which must then be communicated to the programmer. The programmer then reads the ladder logic graphs or statements in order to determine which rungs of the diagrams correspond with the problems in the implemented system which have been communicated to the programmer by the hardware application's engineer. Although this repetitive communication between the programmer and applications engineer is awkward and time consuming, it is necessary because the hardware applications engineer is typically not skilled in the art of programming PLC's using a ladder logic editor.

What is needed is a system and method for programming a logic control unit wherein the time required to develop and test the control program is reduced.

What is also needed is a system and method for programming a logic control unit wherein the programming process provides an interface which is easily understood by an applications engineer who is not trained in the arts of software engineering ladder logic instructions, or ladder logic graphs.

SUMMARY OF THE INVENTION

It is an object of the present invention to provide a system and method for programming a logic control unit wherein the time required to develop and test the control program is reduced.

It is also an object of the present invention to provide a system and method for programming a logic control unit wherein the programming process provides an interface which is easily understood by an applications engineer who is not trained in the arts of software engineering ladder logic instructions, or ladder logic graphs.

It is a further object of the present invention to provide such a system and method which is capable of generating programming listings describing the operation of the programmed process, the program listings being easily read and understood by an applications engineer who is not trained in the arts of software engineering.

It is yet another object of the present invention to provide a method of programming a logic controller wherein it is easy to effect and accommodate changes in the system under control. Further objects of the present invention include the provision of automatic flow chart generation, self-documenting functions, and improved quality of the controlling process.

The present invention provides a process for generating a control program for execution by a logic control unit having a plurality of input ports for receiving input signals from components of an external system under control, and a plurality of output ports for providing output signals to components of the external system. The process includes the steps of; providing a variable editing user interface allowing a user to define and edit variables including input variables associated with corresponding ones of the input signals, and output variables associated with corresponding ones of the output signals; and storing the variables in an internal file.

The process also includes the steps of; providing a state editing user interface allowing a user to define and edit a plurality of states of the control program, wherein selected ones of the variables are associated with corresponding ones of the states, and wherein each selected variable is assigned a corresponding selected data value upon transition of the control program to the selected corresponding state during execution of the control program by the logic control unit; and storing the states in the internal file. The process further includes the steps of; providing a condition editing user interface allowing a user to define and edit at least one condition for each of the states of the control program, each condition specifying a transition from an associated state as a source state to a corresponding selected destination state of the control program upon satisfaction of the condition during execution of the control program by the logic control unit; storing the conditions in the internal file; and generating the control program as a function of the associative relationships of the variables, the states, and the conditions stored in the internal file.

In a preferred embodiment, the process further includes the step of providing a program level editing user interface allowing the user to define and edit a plurality of program levels each including a corresponding plurality of the states, each program level for defining a sub-process of the control program, each program level for asynchronous execution by the logic control unit. The program levels include: at least one task program level; and at least one subroutine program level which may be called by a corresponding calling one of the program levels, the plurality of states of the corresponding calling program level including at least one state having a call condition associated therewith, the call condition specifying a transition from the associated state of the calling program level to a corresponding selected destination state of the corresponding subroutine program level. The plurality of states of the corresponding subroutine program level including at least one state having a return condition associated therewith, the return condition specifying that the control program is to transition to a return state of the corresponding calling program level upon satisfaction of the return condition during execution of the control program. The return state is indicated by a return state field associated with the calling condition of the corresponding calling program level. Each subroutine program level and corresponding calling program level are executed by the logic control unit in a single thread. Each of the program levels has a program level value field associated therewith, the program level value field for carrying a corresponding program level value uniquely identifying the program level.

Each of the states of each program level has a state address field associated therewith, the state address field for carrying a corresponding state address defined by the program level value of the corresponding program level, and a corresponding state value uniquely identifying the state. Each of the conditions has condition fields associated therewith, the condition fields including, a condition address field for carrying a corresponding condition address indicative of the conditions the condition address being formed by the program level value of the corresponding program level, the state value of the corresponding state, and a corresponding condition value uniquely identifying the corresponding condition, and a destination state address field carrying the state address of the corresponding selected destination state to which the process is to transition if the condition is determined to be true during execution of the control program by the logic control unit.

Each of the program levels has a program level name field associated therewith, the program level name field for receiving a user specified character string descriptive of the corresponding program level. Each of the states of each program level has a state name field associated therewith, the state name field for receiving a user specified character string descriptive of the corresponding state. The condition fields further include a condition name field for receiving a user specified character string descriptive of the corresponding condition.

The state values and the condition values are automatically generated sequentially by the programming process as the user defines the states and the conditions via the state editing user interface and the condition editing user interface respectively. The variables further comprise memory location variables including: at least one program variable for which an associated program variable data field is to be allocated by the logic control unit upon execution of the control program; and at least one digital variable for which an associated digital variable data field is to be allocated by the logic control unit upon execution of the control program.

The input variables include: analog input variables associated with corresponding analog input signals received from corresponding ones of the components of the external system; and digital input variables associated with corresponding digital input signals received from corresponding ones of the components of the external system. The output variables include: analog output variables associated with corresponding analog output signals provided to corresponding ones of the components of the external system; and digital output variables associated with corresponding digital output signals provided to corresponding ones of the components of the external system.

The conditions include condition statements for determining whether the transition from the associated source state to the corresponding destination state is to occur, the condition statements comprising check-state condition statements specifying that a selected check state one of the states must be active for the associated condition to be satisfied, the selected check state and the source state being associated with different ones of the program levels. Selected limited ones of the program levels are limited to be executed by the logic control unit only when corresponding selected limiting states are active, each limiting state being associated with a program level other then the corresponding limited program level.

The forgoing and other objects, features, and advantages of the present invention will be apparent from the following detailed description of the preferred embodiment which makes reference to the several figures of the drawing.

IN THE DRAWINGS

FIG. 1 is a schematic block diagram of a distributed process control system including a logic control unit (LCU) configured by a programming system which executes a programming process in accordance with the present invention;

FIG. 2 is a schematic block diagram of a universal controller (UCB) which is a preferred embodiment of the LCU of FIG. 1;

FIG. 3A is a logical flow diagram generally illustrating functional relationships between modules of the programming process of the present invention which is used to generate and upload a user specified control program into the LCU of FIG. 1;

FIG. 31B is a functional block diagram generally illustrating software modules for receiving and interpreting a control program in the UCB of FIG. 2;

FIGS. 4A through 4I are block diagrams generally illustrating fields of variables used in the programming process of the present invention;

FIG. 5 is a flow diagram illustrating a series of steps for implementing a main menu of a user interface of the programming process of the present invention;

FIG. 6 is a flow diagram illustrating a sub-process providing a user with options for editing different types of variables used in the programming process of the present invention;

FIGS. 7-16 are flow diagrams illustrating sub-processes of the programming process of the present invention for editing variables including analog input and output variables, digital input and output variables, program variables, digital variables, front panel LED variables, panel switch variables, timer variables, and proportional integral derivative (PID) variables;

FIG. 17 is a flow diagram illustrating a sub-process for generating a listing of variables previously defined for a particular control program created using the programming process;

FIG. 18 is a flow diagram illustrating a sub-process for creating and editing program levels, states, and conditions of a user-specified control program in the programming process of the present invention;

FIG. 19 is a flow diagram illustrating a program level editing sub-process for editing a selected program level of the control program;

FIG. 20 is a flow diagram illustrating a state editing sub-process for implementing a user interface allowing the user to define and edit states of a program level of the control program;

FIG. 21 is a flow diagram illustrating steps of the state editing sub-process for implementing a user interface allowing the user to define values to be assigned to selected variables upon transition to a particular state of the control program;

FIG. 22 is a flow diagram illustrating steps of the programming process for implementing a user interface allowing the user to configure a timer, associated with a timer variable, to run or stop while the control program operates in a particular state;

FIG. 23 is a flow diagram illustrating a sub-process for implementing a user interface allowing the user to define a formula associated with a state of the control program;

FIG. 24 is a flow diagram illustrating steps of the programming process for implementing a user interlace allowing a user to enter a log message associated with a state of the control program;

FIG. 25 is a flow diagram illustrating a limit editing sub-process for implementing a user interface allowing the user to define limits for a program level of the control program;

FIG. 26 is a flow diagram illustrating a condition editing process for implementing a user interface allowing, a user to define and edit conditions for transition of the control program from one state to another;

FIG. 27 is a flow diagram illustrating further steps of the condition editing process of FIG. 25;

FIG. 28 is a flow diagram illustrating a sub-process of the condition editing process of FIG. 25 for generating a check-state condition statement which is a function of the present active state of a program level other than the present program level;

FIG. 29 is a flow diagram illustrating a sub-process of the condition editing process for generating a condition statement which is a function of the present value of an analog input variable, analog output variable, or program variable;

FIGS. 30A, 30B and 31 are flow diagrams illustrating sub-processes of the condition editing process for generating various types of condition statements which are functions of the current values of an analog input variable, analog output variable, or digital variable;

FIG. 32 is a flow diagram illustrating a sub-process of the condition editing process for generating a logic type condition statement which is a function of the current value of a digital variable, digital input variable, digital output variable, front panel LED variable, or panel switch variable;

FIG. 33 is a flow diagram illustrating steps of a sub-process for generating program listings of program levels, states, conditions, and variables according to the present invention;

FIG. 34 is a block diagram of an exemplary instruction listing generated using the programming system of the present invention;

FIG. 35 is a flow diagram illustrating steps of a process of generating the instruction listing of FIG. 34 in the programming system of the present invention;

FIGS. 36, 37, and 38 are block diagrams of an exemplary flow chart listing of three program levels of a control program created using the programming system of the present invention;

FIG. 39 is a flow diagram illustrating a process of generating the flow chart listing of FIGS. 36, 37, and 38 in the programming system of the present invention;

FIGS. 39, 40, and 41 are flow diagrams illustrating a first phase of a process of generating the flow chart listing of FIGS. 36, 37, and 38 in the programming system of the present invention, the first phase generating arrays of position coordinates for each program level, state, and condition of a control program;

FIGS. 42, 43, 44, and 45 are flow diagrams illustrating a second phase of the process of generating the flow chart listing of FIGS. 36, 37, and 38 wherein the flow chart listing is rendered using the arrays of position coordinates generated in the first phase;

FIG. 46 is a block diagram of an exemplary cross reference listing generated using the programming system of the present invention; and

FIGS. 47-50 show a flow diagrams depicting a process for generating a cross-reference listing.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

The present invention provides a programming system and process for configuring a logic control unit (LCU), based on a modified state machine theory, the LCU being configured for use in a distributed process control system. The programming system of the present invention enables programming of an LCU in accordance with a user friendly graphic interface designed for use by or under the supervision of process control engineers who need not be programming experts.

Referring now to the drawing, FIG. 1 shows a schematic block diagram of a distributed process control system 10 which may be used in practicing the present invention. The system 10 includes a logic control unit (LCU) 12 having; a plurality of digital input ports 14 for receiving digital input signals from a component of a system under control (not shown); a plurality of digital output ports 16 for providing digital output signals to components of the system under control; a serial bus port 18; a digital interlock port 20; a plurality of timer/counter input ports 22; a plurality of timer/counter output ports 24; a front panel port 26; a port 28; and a control program installation port 30.

In a preferred embodiment, each of the digital input ports 14 and each of the digital output ports 16 includes eight bits. Also, in the preferred embodiment, the front panel port 26 and graphics port 29 are both RS232 type serial communication ports, and the LCU 12 includes all hardware required for each RS232 port. Further in the preferred embodiment, the serial bus port 18 is a synchronous serial input/output port. In an embodiment, the LCU 12 may include additional RS232 type ports (not shown) for coupling with additional logic control units or with a network hub.

The depicted control system 10 also includes: an analog input/output extension unit 31 having a port 32 coupled with serial bus port 18 of the LCU 12, a plurality of analog input ports 33 for receiving analog input signals from components of the system under control, and a plurality of analog output ports 34 for providing analog output signals to components of the system under control; and a digital input/output extension unit 35 having a port 36 also coupled with serial bus port 18 of the LCU 12, a plurality of additional digital input ports 37, and a plurality of additional digital output ports 38. The serial bus port 18 of the LCU 12 may provide serial communication with additional extension units such as robotics extension units (not shown), and PID extension units (not shown).

The depicted control system 10 further includes a digital input/output interlock unit 40 having a port 42 coupled with the digital interlock port 20 of the LCU 12, a plurality of digital interlock output ports 44 for providing digital interlock output signals to external equipment of the system under control indicating that the system under control is to be shut down due to an interlock condition, and a plurality of digital interlock input ports 46 for receiving digital interlock input signals from external equipment of the system under control indicating that the system under control is to be shut down due to an interlock condition.

The depicted control system 10 further includes an end user front panel unit 50 having; a port 51 connected with a plurality of the ports 14 of the LCU 12; a port 52 coupled with the front panel port 26 of the LCU; a panel control logic unit 53 having a port 54 connected with the front panel port 26 of the LCU via port 52 of the panel unit 50; a keyboard 55 coupled with the panel processor 53; a liquid crystal display unit (LCD unit) 56 coupled with the panel control logic unit 53 via a bus 57; all LED panel 58 having a port 59 coupled with the panel logic control unit via bus 57, and having, a plurality of light-emitting diodes (LED's) 60; and a switch panel 62 having a port 63 coupled with ports 14 of the LCU 12 via port 51 of the panel unit 50, and having a plurality of switches 64.

The depicted control system 10 further includes: an end user graphical user interface (end user GUI) 65 having a port 66 connected to port 28 of the LCU 12; a graphics controller unit 68 having a port 70 coupled for communication with port 28 of the LCU via port 66 of the end user GUI and a port 72; and a graphics display unit 74 having a port 76 coupled to port 72 of the graphics controller unit 68.

The end user front panel 50 provides an interface between an end user and the distributed process control system 10 during execution of a control program by the LCU 12. Each of the LED's 60 of the end user front panel 50 is individually addressable by the LCU 12 via the panel control logic unit 53 which is responsive to signals received via the RS232 communication channel coupled with the front panel port 26 of the LCU. The LCU 12 provides front panel LED output signals to the panel control logic unit 53, the signals carrying information indicating which of the LED's 6O are to he activated. For example, a front panel LED output signal may be used to carry information instructing the panel control logic unit 53 to activate a particular one of the LED's 60 to indicate to the end user that a pressure value has exceeded a threshold.

The switches 64 of the end user front panel provide front panel switch signals to particular digital inputs 14 of the LCU, the front panel switch signals carrying information indicative of which switches 64 are ON and which are OFF. For example, a front panel switch signal may be used to carry information indicating that a particular one of the switches 64 has been activated by the end user in order to decrease a pressure value.

In the preferred embodiment, the LED panel 58 includes 128 individually addressable LED's 60, and the switch panel 62 includes 4 rows of 40 switches 64. In the depicted embodiment, the analog input/output extension unit 31 and digital input/output extension unit 35 are non-intelligent cards. However, in an alternative embodiment, the extension units 31 and 35 may include additional processing capability and additional memory capacity.

In the preferred embodiment, the control system 10 further includes a programming computer system 80 for executing a programming process according to the present invention for configuring the LCU 12. The programming system 80, which may be a personal computer, work station, or other suitable computer, includes: a port 82 coupled with the programming port 32 of the LCU 12. a computer processing and memory unit 81, a display unit 83 coupled with the computer, an interlace device 84 such as a keyboard or mouse coupled with the computer, and a printer 85. As further explained below, the programming process according to the present invention provides a graphical user interface which allows the end user, usually a process engineer, to generate internal files including data and instructions for controlling a system based on a modified state machine theory. The internal files are compiled to generate a control program for uploading to the LCU 12 via a sequence of steps including compiling, data conversion, and loading as further explained below.

In varying embodiments, the programming process of the present invention may be implemented using any combination of computer programming software, firmware or hardware. As a preparatory step to practicing the invention or constructing an apparatus according to the invention, the computer programming code (whether software or firmware) according to the invention will typically be stored in one or more machine readable storage devices such as fixed (hard) drives, diskettes, optical disks, magnetic tape, semiconductor memories such as ROMs, PROMs, etc., thereby making an article of manufacture in accordance with the invention. The article of manufacture containing the computer programming code is used by either executing the code directly from the storage device, by copying the code from the storage device into another storage device such as a hard disk, RAM, etc. or by transmitting the code on a network for remote execution. The method form of the invention may be practiced by combining one or more machine readable storage devices containing the code according to the invention with appropriate standard computer hardware to execute the code contained therein. An apparatus for practicing the invention could be one or more computers and storage systems, such as the programming system 80, containing or having network access to computer program(s) coded in accordance with the present invention.

The end user GUI 65 displays the values of variables created by the programming process in a graphic form. The variables carry control information associated with analog and digital input/output signals, and various control program parameters. Each variable includes an access right field indicating whether or not the associated data field of the corresponding variable is accessible from the end user GUI 65 as a read only (RO) type value or as a read/write (R/W) type value. As further explained below, the access right value stored in the access right field of each variable is initially assigned when defining and editing the variable in the programming process. Also, in accordance with the programming process of the present invention, the access right value may be varied depending on the present state of the system under test during execution of the control program. The programming process provides for generating program listings including each variable and its associated access rights for use by the end user.

FIG. 2 shows a schematic block diagram of a preferred embodiment of the LCU 12 (FIG. 1) formed by a universal controller board (UCB) 88 including: a central processing unit (CPU) 90 having a first port 91, a second port 92 coupled with a serial bus 93, a third port 94, and a fourth port 95 coupled with a bus 96; a digital I/O hardware unit 98 coupled with the bus 96, and having a plurality of inputs coupled to receive digital input signals via digital input ports 14 of the LCU 12, a plurality of outputs coupled to provide the digital output signals via the digital output ports 16 of the LCU 12, and a plurality of digital interlock terminals coupled to provide digital interlock signals via the digital interlock port 20 of the LCU 12; a static RAM (SRAM) 100 coupled for communication via the bus 96; a memory card 102 having a RAM 103 and a parallel flash EPROM 104 each being coupled for communication via the bus 96; a synchronous serial I/O hardware unit 106 having a port 107 coupled for communication with the CPU 90 via the serial bus 93, and having a port coupled for communication with the extension units 31 and 35 (FIG. 1) via the serial bus port 18; a serial flash EPROM 108 coupled for communication with the synchronous serial I/O hardware unit 106 and the CPU 90 via the serial bus 93; a first RS232 hardware unit 109 having a port 110 coupled for communication with the third port 94 of the CPU 90, and having a port coupled for communication with the panel control logic unit 53 of the end user front panel 50 (FIG. 1) via the front panel port 26 of the LCU 12; a second RS232 hardware unit 112 coupled for communication with a dual universal asynchronous receiver/transmitter hardware unit (dual UART hardware unit) 113 via a bus 114, a first port coupled for communication with the programming computer system 80 (FIG. 1) via the installation port 30 of the LCU 12, and a second port coupled for communication with the end user GUI 65 (FIG. 1) via the graphics port 28 of the LCU 12. The dual UART 113 has a port 115 coupled for communication with the bus 96 (FIG. 19) and provides communication between the RS232 ports 28 and 30 and the bus 96.

The parallel flash EPROM 104 is used for storing software including: an operating system kernel; I/O device drivers for interfacing with external devices of the system under control providing and receiving I/O signals; and an interpreter for translating and executing instructions and data of the control program. The serial flash EPROM 108 is used for storing configuration data as further explained below. The SRAM 100 provides a working read/write memory for the UCB.

During the course of developing a control program for execution by the UCB 88 to control a specified process, it may be necessary for the user of the programming process to reconfigure the UCB by overwriting a previously stored control program. During execution of the control program by the UCB. the end user typically observes the calibration of various components (e.g., a transducer) which transmit and receive I/O signals to and from the LCU 12 (FIG. 1). Also, the end user may wish to modify certain parameters of components of the system under control, as further explained below, in order to calibrate the control system. For example, each analog input signal received from a device (not shown) via one of the analog input ports (FIG. 1) has a range of signal program level values defined by a minimum device value and a maximum device value included within the driver software. As further explained below, in the programming process of the present invention, when defining an analog input variable associated with a corresponding analog input signal, an initial value may be assigned for an engineering unit low and an engineering unit high values which correspond with the device low values and device high values, respectively. The end user GUI 65 (FIG. 1) or the end user front panel 50 may be used to change the engineering unit low value or engineering unit high value subsequent to uploading the control program to the UCB. Later, when a revised control program is uploaded to the UCB it is desirable that the operator-adjusted engineering unit low value or engineering unit high value not be overwritten. Therefore, in accordance with the programming process of the present invention, some parameters of the control program are defined as configuration data. Configuration data may only be overwritten during uploading of a revised control program if an option to do so is selected. Configuration data is maintained in the EPROM 100 separate from other data and instructions of the control program.

FIG 3A shows a logical flow diagram at 120 generally illustrating a process of configuring the LCU 12 (FIG. 1) according to the present invention. Configuration of the LCU 12 is specified by a user 124 who creates a control program using a graphical user interface of a programming process 128 implemented on the programming system 80 (FIG. 1). As further explained below, the programming process 128 of the present invention allows the user 124 to design a control program in terms of program levels, states and conditions based on a modified state machine theory. The interface of the programming process 128 is used to create internal files 132 including: a source file having source code defining a control program; variable files having information defining all variables used in the programming process as further explained below; an identity file; a state name file; a condition name file; and a text file.

In the preferred embodiment, the programming process is implemented in C language. As will be readily apparent to those skilled in the art of computer programming, the programming process may be implemented in a variety of other programming languages including C++, assembly language, or any other suitable programming language. The programming process 128 uses the internal files 132 to generate program listings 138 in accordance with the present invention which may be easily read and understood by an applications engineer who provides the specifications of the control program. As further explained below, the program listings 138 enable a dramatic reduction in the time required to configure a logic control unit.

The programming process 128 provides source code from the internal files 132 to a compiler 136 which compiles the source code to create a control program object file 140. The identity files, state name file, condition name file, and text file of the internal files 132 are not compiled and are not included in the object file 140.

An uploading module 142 provides conversion and uploading of the object file 140 to the LCU 12 (FIG. 1). For a control system using a programmable logic controller (PLC), the object file 140 is converted by a PLC format data converter 148 from the format of the programming system 80 (FIG. 1) (e.g., PC format) to a PLC format control program 152 which is then loaded by a PLC format loader 156 to a PLC 160 implementing the LCU 12. For a logic control system using the preferred UCB 88 (FIG. 2) according to the present invention, the object file 140 is converted by a UCB. format converter module 164 from the format of the programming system to a UCB format control program 168 which is loaded by a UCB format loader module 172 to the UCB 88 implementing the LCU 12. It will be apparent to those skilled in the art that the functions of data format conversion and uploading may be implemented in the present invention in accordance with any of a variety of well known methods. The uploading module 142 further includes diagnostic software 174 for simulating the control program and determining problems associated therewith.

FIG. 3B shows a functional block diagram generally illustrating modules of controller software 180 for receiving, interpreting, and executing a control program generated in accordance with the present invention. The control software 180 is stored in the parallel flash EPROM unit 98 (FIG. 2) and executed by the CPU 90 of the UCB of FIG. 2. The controller software 180 includes a multitasking operating system kernel (OS kernel) 182, a configurable I/O system 184, an interpreter 186.

The OS kernel 182 receives data and instructions of the control program from the parallel flash EPROM unit 98 (FIG. 2) and passes the data and instructions to the interpreter 186 which translates and then executes the instructions of the control program one at a time. The OS kernel 182 and interpreter 186 are stored in the parallel flash EPROM 104 (FIG. 3A). The configurable I/O system 184 includes a plurality of I/O drivers.

Creating and Editing Variables

Variables used in the programming process of the present invention may be classified as input/output device variables (I/O device variables), memory location variables, and timer variables. The I/O device variables include analog input variables, analog output variables, digital input variables, digital output variables, front panel LED variables, and front panel switch variables. The memory location variables include program variables and digital variables. As further explained below, each of the variables includes an identification field used in the programing process for storing ID values which uniquely identify the corresponding variable, and which specify a type of an associated data field to be allocated by the LCU 12 (FIG. 1) during execution of the formatted control program by the LCU 12 (FIG. 1), the type of the data field being appropriate for storing a data value associated with the corresponding variable.

Variables may be classified by the types of data fields to be allocated by the LCU for the different variables. Digital value type variables include digital input variables, digital output variables, panel switch variables, and panel LED variables. Float value type variables include analog input variables, analog output variables, and program variables. Long value type variables include timer variables. A digital value type data field is allocated by the LCU 12 (FIG. 1) for each of the digital value type variables. In the preferred embodiment of the present invention, eight bits are allocated by the LCU for each digital value type data field. A floating point value data field is allocated by the LCU 12 (FIG. 1) for each of the float value type variables. A long value type data field is allocated by the LCU 12 (FIG. 1) for each of the long value type variables. As further described below, the programming process uses count values stored in the variable files of the internal files 132 (FIG. 3) to assign the identity values to the variables. A digital type variable count value, stored in the variable files of the internal files, is increased each time a new digital type variable is created by the user. A float type variable count value, stored in the variable files of the internal files, is increased each time a new float type variable is created by the user. A long variable count value, stored in the variable files of the internal files, is increased each time a new long type variable is created by the user.

FIG. 4A shows a block diagram at 200 illustrating fields of an analog input variable used in the programming process of the present invention, the fields including: an identity field (ID field) 202 for receiving an ID value automatically assigned by the programming process, the ID value for uniquely identifying the corresponding analog input variable and also for specifying the length of an associated analog input data field (not shown) to be allocated by the LCU 12 (FIG. 1) for receiving a sampled value derived from a corresponding one of the analog input signals received at input ports 36 (FIG. 1) of the LCU; an analog input variable name field 203 for receiving a user-specified string of characters descriptive of the source of, or information carried by, the corresponding analog input signal; an input/output address field 204 for receiving a user-specified value indicative of a particular one of the analog input ports 36 (FIG. 1) of the analog I/O extension unit 33 (FIG. 1) at which the corresponding analog input signal is received; a device voltage/current mode field 205 for receiving a user-specified mode value indicative of whether the corresponding analog input signal is to be sensed by the logic control unit 12 (FIG. 1) in a voltage mode or in a current mode; a device low value field 206 for receiving a user-specified device low value indicative of a minimum voltage or current value (as specified by the corresponding mode value stored in the device mode field 205) of the corresponding analog input signal; and a device high value field 207 for receiving a user-specified device low value indicative of a maximum voltage or current value (as specified by the corresponding mode value) of the corresponding analog input signal. The values entered into the device low and high value fields 206 and 207 need not be passed to the UCB because the device drivers stored in the memory of the UCB includes device low and high values. However, user specified values stored in the device low and high value fields 206 and 207 are used in generating program listings as further explained below.

Fields of the analogy input variable illustrated at 200 also include a sample number field 208 for receiving a user specified sample number value, and a sample time field 209 for receiving a user specified sample time value. The sample number value and sample time value are used in a software implemented filtering scheme of the present invention for filtering noise disturbances in the corresponding analog input signal which may arise due to any of a wide variety of electrical and mechanical effects in the distributed process control system 10 (FIG. 1). The sample number value and sample time value specify a required number of consecutive samples during the specified sample time for which the corresponding analog input signal must have a signal program level within a predefined threshold in order to be considered as having settled. The threshold value is determined taking into account the manufacturer specifications of the device providing the analog input signal.

Fields of the analog input variable illustrated at 200 further include an engineering unit low field (EU LO field) 210, and an engineering unit high field (EU HI field) 211. The EU LO field 210 has a plurality of sub-fields including an EU low name field 217, an EU low value field 218, an EU low access right field 219, and an EU low configuration status field 220.

The EU HI field 211 has a plurality of sub-fields including an EU high name field 221, an EU high value field 222, an EU high access right field 223, and an EU high configuration status field 224. The EU low and EU high name fields 217 and 221 each receive a user-specified string of descriptive of an absolute minimum value and an absolute maximum value respectively of an allowable range of unit values carried by the corresponding analog input signal.

The sub-fields 217, 218, 219, and 220 of the EU low field 210 are used by the programming process of the present invention, as further explained below, to automatically create an EU low program variable 225 which is distinct from the analog input variable 200. The EU low program variable 225 includes: an ID field 226 for receiving a unique ID value which uniquely identities the EU low program variable 225; and the EU low sub-fields 217, 218, 219, and 220. Likewise, the sub-fields 221, 222, 223, and 224 of the EU high field 211 are used by the programming process of the present invention as further explained below, to create an EU high program variable 227 which is also distinct from the analog input variable 200 and EU low program variable 225. The EU high program variable 227 includes: an ID field 228 for receiving a program generated ID value which uniquely identifies that the EU high program variable 227; and the EU high sub-fields 221, 222, 223, and 224.

The low value field 218 receives a user-specified absolute minimum value expressed in appropriate engineering units (e.g., psi), which corresponds with the device low value entered in the device low field 206. The EU low access right field 219 carries a value indicative of whether the EU LO program variable 225 may be accessed as a read only value or as a read/write value by the end user GUI 65 (FIG. 1). The EU low configuration status field 220 carries a value indicative of whether the EU low program variable 225 is to be stored in the configuration data base in the serial flash EPROM unit 100 (FIG. 2) of the UCB, or in the main data base in the parallel flash EPROM unit 98 (FIG. 2). when the control program object file 140 (FIG. 3) is installed into the UCB 88.

The EU high value field 222 receives a user-specified absolute maximum value, indicative of a value expressed in appropriate units, which corresponds with the device high value entered in the device high field 207. The EU high access right field 223 receives a user-specified value indicative of whether the EU high program variable 227 may be accessed as a read only value or as a read/write value by the end user GUI 65 (FIG. 1). The EU high configuration status field 224 receives a user-specified value indicative of whether the EU high program variable 227 is to be stored in the configuration data base in the serial flash EPROM unit 100 (FIG. 2) of the UCB, or in the main data base in the parallel flash EPROM unit 98 (FIG. 2), when the control program object file 140 (FIG. 3) is installed into the UCB 88.

As all example, an analog input variable 200 may be used in the programming process of the present invention to represent an analog input signal provided by a pressure transducer (not shown) and received at one of the analog input ports 36 (FIG. 1) of the analog I/O extension unit of the LCU, 12 (FIG. 1). The analog input signal provided by the pressure transducer may have a range of 0 to 20 volts which represents pressure variations in a range between 5 and 100 psi. In this example; the device mode field 205 carries a value indicative of "voltage"; the low and device high fields 206, 207 carry values indicative of 0 and 20 volts respectively; the EU high and low names carried in fields 215 and 220 may be "psi", and the EU high and low values carried in fields 218 and 222 will be set to 5 and 100 respectively by the user of the programming process of the present invention. The EU high and low fields are passed to the UCB.

As further described below, the above described values for fields 203-211 are user specified in accordance with the programming process of the present invention. In the preferred embodiment, the analog input ID value specifies a length for an associated analog input data field (to be allocated by the LCU 12 of FIG. 1), which is adequate for storing a floating point number. The ID values stored in the ID fields 202 of the analog input variables are automatically assigned by the programming process which increases the float type variable counter value, stored in the corresponding identity files of the internal 132 (FIG. 3), each time a new float type variable is created by the user. As mentioned above, float type variables include analog input variables, analog output variables, and program variables.

As explained in further detail below, the fields 202, 204-209, 218-220, and 222-224 are all passed from the programming system 80 (FIG. 1) to the logic control unit 12 (FIG. 1) upon installation of the control program to the logic control unit 12. However, as is generally the case for all variables used in the programming process of the present invention, name fields (including fields 203, 217, and 221 for the depicted analog input variable) are not passed to the to the logic control unit. Also, the device low field and device high field are not passed to the to the logic control unit because, as mentioned above, the device low and device high values are included in the I/O drivers.

FIG. 4B shows a block diagram at 230 illustrating fields of an analog output variable used in the programming process of the present invention. Analog output variables are used to generate the analog output signals provided at each of the plurality of analog output ports 38 (FIG. 1) of the analog I/O extension board. The depicted analog output variable is similar to the analog input variable at 200 (FIG. 4A) in that fields of the analog output variable also include: an ID field for receiving an AO identity value automatically assigned by the programming process, the AO identity value for uniquely identifying the corresponding analog output variable and also for specifying the length of an associated analog output data field (not shown) to be allocated by the LCU 12 (FIG. 1) for receiving analog output values used in generating a corresponding one of the analog output signals provided at ports 38 (FIG. 1) of the LCU; an analog output variable name field for receiving a user-specified string of characters descriptive of information carried by the corresponding analog output signal; an input/output address field for receiving a user-specified value indicative of the particular one of the analog output ports 38 (FIG. 1) of the analog I/O extension unit 33 (FIG. 1) from which the corresponding analog output signal is provided; a device voltage/current mode field for receiving a user-specified mode value indicative of whether the corresponding analog output signal is to be controlled by the logic control unit 12 (FIG. 1) in a voltage mode or in a current mode; a device low field for receiving a user-specified device low value indicative of a minimum voltage or current value (as specified by the corresponding mode value stored in the device mode field 205) of the corresponding analog output signal; and a device high field for receiving a user-specified device low value indicative of a maximum voltage or current value (as specified by the corresponding mode value) of the corresponding analog output signal.

In the preferred embodiment, the analog output identity value specifies a length for the associated analog output data field (to be allocated by the LCU of FIG. 1) which is adequate for storing a floating point number. The depicted analog output variable 230 is also similar to the analog input variable 200 (FIG. 4A) in that the analog output variable 230 further includes: an engineering unit low field (EU low field) 232 having an EU low name sub-field, an EU low value sub-field, an EU low access right sub-field, and an EU low configuration status sub-field; and an engineering unit high field (EU high field) 240 having an EU high name sub-field, an EU high value subfield, an EU high access right sub-field, and an EU high configuration status sub-field.

The sub-fields of the EU low field 232 are used in the programming process of the present invention, as further explained below, to automatically create an EU low program variable 236 which is associated with but distinct from the analog output variable 230. The EU low program variable 236 includes an ID field 237 for receiving a unique ID value which uniquely identifies the EU low program variable 236, and the EU low sub-fields. Likewise, the sub-fields of the EU high field 234 are used in the programming process of the present invention as further explained below, to create an EU high program variable 238 which is also associated with but distinct from the analog output variable 230. The EU high program variable 238 includes: an ID field 239 for receiving a program generated ID value which uniquely identifies that the EU high program variable 238; and the EU high sub-fields.

However, unlike the analog input variable 200 (FIG. 4A), the depicted analog output variable does not include a sample number field or a sample time field. Additionally, the depicted analog output variable has an access right field 240 and a delay field 242, neither of which is included in the analog input variable. The access right field 240 of the analog output variable 230 receives a user-specified value indicative of whether the analog output variable may be accessed as a read only value or as a read/write value from the end user GUI 65 (FIG. 1) during execution of the control program. The delay filed 242 receives a user specified delay time value indicative of a delay time required for an external component of the system under test to be responsive to the corresponding analog output signal.

In the same manner as for the analog input variable at 200 (FIG. 4A), all of the depicted fields of the analog output variable except the name fields are passed to the LCU 12 (FIG. 1). Note that the analog input variable 200 (FIG. 4A) does not include an access right field. Access to analogy input variables from the end user GUI 65 (FIG. 1) defaults to read only, and therefore read/write access to the analog input variables from the end user GUI 65 (FIG. 1) is not allowed during execution of the control program.

FIGS. 4C shows a block diagram at 246 illustrating fields of a digital input variable used in the programming process of the present invention, the fields including: an identity field (ID field) for receiving a digital input identity value for uniquely identifying the corresponding digital input variable 246, and also for specifying the length of an associated digital input data field to be allocated try the LCU 12 (FIG. 1) for storing values derived from a corresponding one of the digital input signals received at the digital input ports 14 and 37 of the LCU; a digital input variable name field for receiving a user-specified string of characters descriptive of the source of, or information carried by the corresponding digital input signal received at a corresponding one of the plurality of digital input ports 14 (FIG. 1) of the logic control unit; and an input/output address field for receiving a user-specified value indicative of a particular one of the digital input ports 14 (FIG. 1) of the LCU 12 at which the corresponding digital input signal is received.

The fields of the digital input variable at 246 further include: an ON state logic program level field 248 for receiving a user specified value indicative of a logic program level corresponding to an ON state for the source device (not shown) from which the corresponding digital input signal is received; a sample number field 250 for receiving a user specified sample number value; and a sample time field 252 for receiving a user specified sample time value. The sample number value and sample time value are used in a software implemented debouncing scheme of the present invention which provides debouncing of the corresponding digital input signal which may arise due to any of a wide variety of electrical and mechanical effects in the distributed process control system 10 (FIG. 1). The sample number value and sample time value specify a required number of consecutive values sampled during the specified sample time for which the corresponding digital input signal must be above or below the ON state logic program level value before a transition of the logic value of the digital input signal is determined to have occurred. Note that the digital input variable 246 does not include an access right field. Access to input variables from the end user GUI 65 (FIG. 1) defaults to read only, and therefore read/write access to the digital input variable 246 from the end user GUI 65 (FIG. 1) is not provided during execution of the control process.

In the preferred embodiment, the digital input identity value carried in the ID field of the digital input variable 246 specifies a length for the associated digital input data field (to be allocated in the ECU 12 of FIG. 1), which is adequate for storing a bit value.

FIG. 4D shows a block diagram at 254 illustrating fields of a digital output variable used in the programming process of the present invention, the fields including: an identity field (ID field) for receiving a digital output identity value for uniquely identifying the corresponding digital output variable 254, and also for specifying the length of an associated digital output data field to be allocated by the LCU 12 (FIG. 1) for storing values used for generating a corresponding one of the digital output signals provided at the digital output ports 16 and 38 of the LCU and digital I/O extension unit 40 (FIG. 1); a digital output variable name field for receiving a user specified string of characters descriptive of the source of, or information carried by, the corresponding digital output signal; and an input/output address field for receiving a user specified value indicative of the particular one of the digital output ports 16 (FIG. 1) at which the corresponding digital output signal is to be provided. The digital output variable 254 is similar to the digital input variable 246 (FIG. 4C) in that it also includes an ON state logic program level field. However, the depicted digital output variable differs from the digital input variable 246 (FIG. 4C) in that it does not include a sample number field or a sample time field. In addition, the digital output variable 254 is dissimilar from the digital input variable in that it includes an access right field 256, a delay field 258, and an LED property field 260. In the preferred embodiment, the digital output identity value carried in the ID field of the digital output variable 254 specifies a length for the associated digital output data field (to be allocated in the LCU 12 of FIG. 1), which is adequate for storing a bit value.

The access right field 256 receives a user-specified value indicative of whether the digital output variable 254 may be accessed as a read only value or as a read/write value by the end user GUI 65 (FIG. 1).

The delay field 258 of the digital output variable receives a user specified delay time value indicative of a delay time required for an external component of the system under test to be responsive to the corresponding digital output signal.

The LED property field of the digital output variable is used to carry an LED property value for specifying the behavior of an external LED of the system under control (other than the LED's 60 of the LED panel of FIG. 1) in response to receiving the digital output signal corresponding, with the digital output variable 254.

FIG. 4E shows a block diagram at 262 illustrating fields of a front panel LED variable used in the programming process of the present invention, the fields including: an ID field for receiving a front panel LED variable identity value for uniquely identifying the corresponding front panel LED variable 262, and also for specifying the length of an associated LED data field to be allocated by the ECU 12 (FIG. 1) for storing values used for generating a corresponding one of the LED output signals provided at the front panel port 26 of the LCU 12 (FIG. 1); a front panel LED variable name field for receiving a user specified string of characters descriptive of the source of, or information carried by, the corresponding LED output signal; an 10 input/output address field for receiving a user specified value indicative of the port 26 (FIG. 1) at which the corresponding LED output signal is to be provided; an access right field for receiving a user-specified value indicative of whether the digital output variable 254 may be accessed as a read only (R/O) value or as a read/write (R/W) value by the end user GUI 65 (FIG. 1); and an ON state logic program level field. The front panel LED variable 262 is very similar to the digital output variable 254 (FIG. 4D). In the preferred embodiment, the front panel LED variable identity value carried in the ID field of the front panel LED variable 262 specifies a length for the associated LED data field (to be allocated in the LCU 12 of FIG. 1), which is adequate for storing a two bit value. The two bits of the LED data field to be allocated by the LCU are used for storing LED values representing LED states including ON, OFF, blink slow, and blink fast.

FIG. 4F shows a block diagram at 264 illustrating fields of a panel switch variable used in the programming process of the present invention, the fields including: an identity field for receiving a panel switch variable identity value for identifying the corresponding panel switch variable 264, and also for specifying the length of an associated panel switch data field to be allocated by the LCU 12 (FIG. 1) for storing values received via a corresponding one of the panel switch signals received at the front panel port 26 of the LCU 12 (FIG. 1); a panel switch variable name field for receiving a user specified string of characters descriptive of the source of, or information carried by, the corresponding panel switch signal; and an input/output address field for receiving a user specified value indicative of the particular digital input port 14 (FIG. 1) at which the corresponding panel switch signal is to be provided; an access right field for receiving a user-specified value indicative of whether the corresponding panel switch variable 264 may be accessed as a read only (R/O) value or as a read/write (R/W) value by the end user GUI 65 (FIG. 1); and an ON state logic program level field.

In the prefer-red embodiment, the panel switch variable identity value carried in the ID field of the panel switch variable 264 specifies a length for the associated panel switch variable data field (to be allocated in the LCU 12 of FIG. 1), which is adequate for storing a bit value.

FIG. 4G shows a block diagram at 266 illustrating fields of a program variable used in the programming process of the present invention, the fields including: an identity field for receiving an ID value identifying the corresponding program variable 266, and also for specifying the length of an associated program variable data field (not shown) to be allocated by the LCU 12 (FIG. 1) for storing program values; a program variable name field for receiving a user-specified string of characters descriptive of the corresponding program variable; a configuration property field 268 for receiving a user specified value indicative of whether the program variable 266 is to be stored in the configuration data base in the serial flash EPROM unit 100 (FIG. 2) of the UCB, or in the main data base in the parallel flash EPROM unit 98 (FIG. 2), when the control program object file 140 (FIG. 3) is installed into the UCB 88; an initialization value field 270 for receiving a corresponding user-specified initialization value for the program variable data field (not shown); and an access right field for receiving a user-specified value indicative of whether the corresponding program variable 266 may be accessed as a read only (R/O) value or as a read/write (R/W) value by the end user GUI 65 (FIG. 1). In the preferred embodiment, the program variable identity value carried in the ID field of the program variable 266 specifies a length for the associated program variable data field (to be allocated in the LCU 12 of FIG. 1), which is adequate for storing a floating point number.

FIG. 4H shows a block diagram at 272 illustrating fields of a digital variable used in the programming process of the present invention. The fields of the depicted digital variable include: an identity field for receiving an ID value identifying the corresponding digital variable 272, and also for specifying the length of an associated digital variable data field (not shown) to be allocated by the LCU 12 (FIG. 1) for storing digital values; a digital variable name field for receiving a user-specified string of characters descriptive of the corresponding digital variable; a configuration property field for receiving a user specified value indicative of whether the digital variable 272 is to be stored as configuration data; an initialization value field 274 for receiving a corresponding user-specified initialization value for the digital variable data field (not shown); and an access right field for receiving a user-specified value indicative of whether the corresponding digital variable 272 may be accessed as a read only (R/O) value or as a read/write (R/W) value from the end user GUI 65 (FIG. 1); and an LED property field 276. The LED property field 276 is used for carrying a value indicative of whether a specified LED is currently, or was at some time, blinking fast or blinking slow.

In the preferred embodiment, the identity value carried in the ID field of the digital variable 272 specifies a length for the associated digital variable data field (to be allocated in the LCU 12 of FIG. 1). which is adequate for storing a bit value.

FIG. 4I shows a block diagram at 278 illustrating fields of a timer variable used in the programming process of the present invention. The depicted fields of the timer variable 278 include: an identity field for receiving an ID value identifying the corresponding timer variable 278, and also for specifying the length of an associated timer variable data field (not shown) to be allocated by the LCU 12 (FIG. 1) for storing timer values; a timer variable name field for receiving a user-specified string of characters descriptive of the corresponding timer variable; a configuration property field for receiving a user specified value indicative of whether the timer variable 278 is to be stored as configuration data; an initialization value field 280 for receiving a corresponding user-specified initialization value for the timer variable data field (not shown); and an access right field for receiving a user-specified value indicative of whether the corresponding timer variable 278 may be accessed as a read only (R/O) value or as a read/write (R/W) value from the end user GUl 65 (FIG. 1). In the preferred embodiment, the identity value carried in the ID field of the timer variable 278 specifies a length for the associated timer variable data field (to be allocated in the LCU), which is adequate for storing an integer whole number.

The Programming Process

FIG. 5 shows a flow diagram at 400 illustrating a series of steps for implementing a main menu of a user interface of the programming process of the present invention for configuring a logic control unit. Although not shown, in the preferred embodiment, the programming process provides an option in the main menu of selecting from a plurality of control programs to be edited or created. The depicted process begins with step 402 in which the programming process prompts a user to select from programming options including editing of variables, editing of the state machine process, compiling, and uploading. In step 404, the programming process receives a user input selected from the choices specified in step 402. In step 406, the programming process determines whether the option of editing variables has been selected. If the user has selected the option of editing of variables, the depicted process proceeds to "A1" (to FIG. 6). In step 407, it is determined whether the user has selected the option of printing a variable listing for the present control program, and if so, the process proceeds to "A2" (to FIG. 17). In step 408 it is determined whether the user has selected the option of editing the state machine process. If so, the depicted process proceeds to "B" (to FIG. 18). In step 409, it is determined whether the user has selected the option of generating a program listing, and if so, the process proceeds to "C" (to FIG. 32). In step 410 it is determined whether the user has selected the option of compiling and if so, the depicted process proceeds to step 411 in which the programming system compiles the internal files 132 (FIG. 3A) in accordance with any of a variety of well known compiling techniques. In step 412, the programming process determines whether the user has selected the option of uploading. If it is determined at 412 that the user has selected the option of uploading, the depicted process proceeds to step 413 in which the uploading module 142 (FIG. 3A) provides conversion and uploading of the object file 140 to the LCU 12 (FIG. 1) as described above. If it is determined at 412 that the user has not selected the option of uploading, the depicted process ends.

Editing Logic Control Variables

FIG. 6 shows a flow diagram at 420 illustrating a variable editing sub-process providing a user with choices for editing different types of variables in the programming process of the present invention. The depicted process begins with step 422 in which the programming process prompts a user to select from variable-editing options including the editing of analog input variables, analog output variables, digital input variables, digital output variables, program variables, digital variables, panel light-emitting diode (panel LED) variables, panel switch variables, timer variables, and proportional integral derivative (PID) variables. In step 424, the programming process receives a user input indicating one of the variable editing options provided in step 422.

From step 424, the depicted process proceeds to 426 at which it is determined whether the option of editing analog, input variables has been selected. If so, the depicted process proceeds to "AI" (to FIG. 7). From 426, the depicted process proceeds to 428 at which it is determined whether the user has selected the option of editing analog output variables, and if so, the depicted process proceeds to "AO" (to FIG. 8). From 428, the depicted process proceeds to 430 at which it is determined whether the user has selected the option of editing digital input variables, and if so, the process proceeds to "DI" (to FIG. 9). From 430, the depicted process proceeds to 432 at which it is determined whether the user has selected the option of editing digital output variables, and if so, the depicted process proceeds to "DO" (to FIG. 10).

At 434, it is determined whether the user has selected the option of editing front panel LED variables, and if so, the process proceeds to "LED" (to FIG. 11). At 436, the programming process determines whether the user has selected the option of editing panel switch variables, and if so, the process proceeds to "PS" (to FIG. 12). From 436, the process proceeds to 438 at which it is determined whether the user has selected the option of editing program variables, and if so, the process proceeds to "PV" (to FIG. 13). At 440, the programming process determines whether the user has selected the option of editing digital variables, and if so, the process proceeds to "DV" (to FIG. 14). At 442, it is determined whether the user has selected the option of editing timer variables, and if so, the process proceeds to "T" (to FIG. 15). Finally at 444, it is determined whether the user has selected the option of editing PID variables, and if so, the process proceeds to "PID" (to FIG. 16), and if not, the depicted process ends.

FIG. 7 shows a flow diagram at 450 illustrating a sub-process of the programming process of the present invention for editing an analog input variable (AI variable) 200 (FIG. 4A). The depicted proceeds from "AI" (from FIG. 6) to 452 at which the programming system displays a list of all previously defined analog input variables. In step 454, the programming system: provides a user interface allowing the user to select from the options of defining a new analog input variable, or editing a previously defined analog input variable; and receives a corresponding user in put. In step 456, the programming system displays current values for all of the fields 202-211 (FIG. 4A) of the new/selected present analog input variable 200 (FIG. 4A). If the present analog input variable is a new variable, then the fields 202-211 (FIG. 4A) are undefined and no entry is displayed for each field. From step 456, the depicted process proceeds to step 458 in which the programming system provides an interface allowing the user to edit/define the fields 202-211 (FIG. 4A) of the present analog input variable, and also edit/define fields of the associated EU low program variable 225 (FIG. 4A) and EU high program variable 227. In step 460, the programming system receives and displays the user input for each of the fields 202-211 (FIG. 4A) of the present analog input variable.

In step 462, the programming system determines whether the user has selected the option of defining a new analog input variable. If it is determined at 462 that the user has selected the option of defining a new analog input variable, the depicted process proceeds to step 464 in which the programming system automatically assigns an analog input variable identity value to ID field 202 (FIG. 4A) of the present analog input variable 200. Values are assigned to the ID field 202 of each new analog input variable by reading from the float type variable counter value stored in the variable flies of the internal files 132 (FIG. 3) which is increased each time a new float type variable is defined. From step 464, the process proceeds to step 466 in which the programming system EU generates a new EU low program variable 225 (FIG. 4A) and a new EU high program variable 227 from the sub-fields 210-220 and 221-224 respectively of the EU low field 210 and EU high field 211 of the associated analog input variable 200 (FIG. 4A). In step 468. the programming system automatically assigns identity values to ID fields 226 and 228 (FIG. 4A) of the new EU low program variable 225 and new EU high program variable 227 respectively by reading from the float type counter value. From step 468, the process proceeds to step 470 in which the programming system saves the new/edited values for the fields of the present analog input variable, and the fields of the EU low variable and EU high variable associated with the present analog input variable. If it is determined at 462 that the user has not selected the option of defining a new analog input variable, bust has selected the option of editing a previously defined analog input variable, the depicted process proceeds from 462 directly to execute step 470 as described above.

FIG. 8 shows a flow diagram at 480 illustrating a sub-process of the programming process of the present invention for editing an analog output variable (AO variable) 230 (FIG. 4B). The depicted proceeds from "AO" (from FIG. 6) to 482 at which the programming system displays a list of all previously defined analog output variables. In step 484, the programming system: provides a user interface allowing the user to select from the options of defining a new analog output variable, or editing a previously defined analog output variable, and receives a corresponding use input. In step 486, the programming system displays current values for all of the fields (FIG. 4B) of the new/selected present analog output variable 230 (FIG. 4B). If the present analog output variable is a new variable, then the corresponding fields of the analog output variable (FIG. 4B) are undefined and no entry is displayed for each field. From step 486, the depicted process proceeds to step 488 in which the programming system provides an interface allowing the user to edit/define the fields of the present analog output variable 230 (FIG. 4B), and also edit/define fields of the associated EU low program variable 236 (FIG. 4B) and EU high program variable 238. In step 490, the programming system receives and displays the user input for each of the fields (FIG. 4B) of the present analog output variable.

In step 492, the programming system determines whether the user has selected the option of defining a new analog output variable. If it is determined at 492 that the user has selected the option of defining a new analog output variable, the depicted process proceeds to step 494 in which the programming system automatically assigns an analog output variable identity value to ID field (FIG. 4B) of the present analog output variable 230. Values are assigned to the ID field of each new analog output variable by reading from the float type variable counter value stored in the variable files of the internal files 132 (FIG. 3) which is increased each time a new float type variable is defined. From step 494, the process proceeds to step 496 in which the programming system generates a new EU low program variable 236 (FIG. 4B) and a new EU high program variable 238 from the sub-fields and of the EU low field 232 and EU high field 234 respectively of the associated analog output variable 230 (FIG. 4B). In step 498, the programming system automatically assigns identity values to ID fields 237 and 239 (FIG. 4B) of the new EU low program variable 236 and new EU high program variable 238 respectively by reading from the float type counter value. From step 498, the process proceeds to step 500 in which the programming system saves the new/edited values for the fields of the present analog output variable, and the fields of the EU low variable and EU high variable associated with the present analog output variable. If it is determined at 492 that the user has not selected the option of defining a new analog output variable, bust has selected the option of editing a previously defined analog output variable, the depicted process proceeds from 492 directly to execute step 500 as described above.

FIG. 9 shows a flow diagram at 520 illustrating a sub-process of the programming process of the present invention for editing a digital input variable (DI variable) 246 (FIG. 4C). The depicted process proceeds from "DI" (from FIG. 6) to 521 at which the programming system displays a list of all previously defined digital input variables. In step 522, the programming system: provides a user interface allowing the user to select from the options of defining a new digital input variable, or editing a previously defined digital input variable; and receives a corresponding user input. In step 523, the programming system displays values previously entered for all of the fields (FIG. 4C) of the digital input variable selected in step 522, the fields including the DI variable name field, I/O address field, ON state logic program level field, sample number field, and sample time field (FIG. 4C). If the present digital input variable is a new variable, then the fields of the digital input variable (FIG. 4C) are undefined and no entry is displayed for each field.

In step 524, the programming system provides an interface allowing the user to edit/define the fields (FIG. 4C) of the present digital input variable. In step 525, the programming system receives and displays the user input for each of the fields (FIG. 4C) of the present digital input variable. The depicted process proceeds from step 525 to 526 at which the programming system determines whether the user has selected the option of defining a new digital input variable. If it is determined at 526 that the user has selected the option of defining a new digital input variable, the process proceeds to step 527 in which the programming system automatically assigns a digital input variable identity value to the ID field (FIG. 4C) of the present digital input variable. Values are assigned sequentially to the ID field of each new digital input variable by reading from the digital type variable counter value which is increased each time a new digital type variable is defined. From step 527, the process proceeds to step 528 in which the programming system saves the new/edited values for the fields of the present digital input variable. It it is determined at 526 that the user has not selected the option of defining a new digital input variable, the process proceeds directly to execute step 528 as described above, after which the process returns to "A1" (to FIG. 6).

FIG. 10 shows a flow diagram at 530 illustrating a sub-process of the programming process of the present invention for editing a digital output variable (DO variable) 254 (FIG. 4D). The depicted proceeds from "DO" (from FIG. 6) to 531 at which the programming system displays a list of all previously defined digital output variables. In step 532, the programming system: provides a user interface allowing the user to select from the options of defining a new digital output variable, or editing a previously defined digital output variable; and receives a corresponding user input. In step 533, the programming system displays values previously entered for all of the fields (FIG. 4D) of the new/selected digital output variable including the digital output variable name field, I/O address field, access right, ON state logic program level field, delay 258, and LED property 260 (FIG. 4D). If the present digital output variable is a new variable, then the fields of the digital output variable (FIG. 4D) are undefined and no entry is displayed for each field.

In step 534, the programming system provides an interface allowing the user to edit/define the fields (FIG. 4D) of the present digital output variable. In step 535, the programming system if receives and displays the user input for each of the fields (FIG. 4D) of the present digital output variable. The depicted process proceeds from step 535 to 536 at which the programming system determines whether the user has selected the option of defining a new digital output variable. If it is determined that the user has selected the option of defining a new digital output variable, the process proceeds to step 537 in which the programming system automatically assigns a digital output variable identity value to the ID field (FIG. 4D) of the present digital output variable. Values are assigned to the ID field of each new digital output variable by reading from the digital type variable counter value which is increased each time a new digital type variable is defined. From step 537, the process proceeds to step 538 in which the programming system saves the new/edited values for the fields of the present digital output variable. If it is determined at 536 that the user has not selected the option of defining a new digital output variable, the process proceeds directly to execute step 538 as described above, after which the process returns to "A1" (to FIG. 6).

FIG. 11 shows a flow diagram at 540 illustrating a sub-process of the programming process of the present invention for editing a front panel LED variable 262 (FIG. 4E). The depicted proceeds from "LED" (from FIG. 6) to 541 at which the programming system displays a list of all previously defined LED variables. In step 542, the programming system: provides a user interface allowing the user to select from the options of defining a new LED variable, or editing a previously defined LED variable; and receives a corresponding user input. In step 523, the programming system displays values previously entered for all of the fields (FIG. 4E) of the new/selected front panel LED variable including the variable name field, I/O address field, access right, and ON state logic program level field (FIG. 4E).

In step 524, the programming system provides an interface allowing the user to edit/define the fields (FIG. 4E) of the present LED variable. In step 525, the programming system receives and displays the user input for each of the fields (FIG. 4E) of the present LED variable. The depicted process proceeds from step 525 to 526 at which the programming system determines whether the user has selected the option of defining a new LED variable. If it is determined at 526 that the user has selected the option of defining a new LED variable, the process proceeds to step 527 in which the programming system automatically assigns an LED variable identity value to the ID field (FIG. 4C) of the present digital input variable. Values are assigned to the ID field of each new front panel LED variable by reading from the digital type variable counter value. From step 527, the process proceeds to step 528 in which the programming system saves the new/edited values for the fields of the present LED variable. If it is determined at 526 that the user has not selected the option of defining a new LED variable, the process proceeds directly to execute step 528 as described above, after which the process returns to "A1" (to FIG. 6).

FIG. 12 shows a flow diagram at 550 illustrating a sub-process of the programming process of the present invention for editing a panel switch variable 264 (FIG. 4F). The depicted proceeds from "PS" (FROM FIG. 6) to step 551 at which the programming system displays a list of all previously defined panel switch variables. In step 552, the programming system: provides a user interface allowing the user to select from the options of defining a new panel switch variable, or editing a previously defined panel switch variable; and receives a corresponding user input. In step 553, the programming system displays values previously entered for all of the fields (FIG. 4F) of the new/selected panel switch variable including the panel switch variable name field, I/O address field, access right, and ON state logic program level field (FIG. 4F).

In step 554, the programming system provides an interface allowing the user to edit/define the fields (FIG. 4F) of the new/selected panel switch variable. In step 555, the programming system receives and displays the user input for each of the fields (FIG. 4F) of the present panel switch variable. The depicted process proceeds from step 555 to 556 at which the programming system determines whether the user has selected the option of defining a new panel switch variable. If it is determined at 556 that the user has selected the option of defining a new panel switch variable, the process proceeds to step 557 in which the programming system automatically assigns a panel switch variable identity value to the ID field (FIG. 4F) of the present digital input variable. Values are assigned to the ID field of each new panel switch variable by reading from the digital type variable counter value. From step 557, the process proceeds to step 558 in which the programming system saves the new/edited values for the fields of the present panel switch variable. If it is determined at 556 that the user has not selected the option of defining a new panel switch variable, the process proceeds directly to execute step 558 as described above, alter which the process returns to "A1" (to FIG. 6).

FIG. 13 shows a flow diagram at 560 illustrating a sub-process of the programming process of the present invention for editing a program variable 266 (FIG. 4G). The depicted proceeds from; "PV" (from FIG. 6) to step 561 in which the programming system displays a list of all previously defined program variables. In step 562, the programming system: provides a user interface allowing the user to select from the options of defining a new program variable, or editing a previously defined program variable; and receives a corresponding user input. In step 563, the programming system displays values previously entered for all of the fields (FIG. 4G) of the new/selected program variable including the program variable name field, configuration property field 268. initialization value field 270, and access right field (FIG. 4G).

In step 564, the programming system provides an interface allowing the user to edit/define the fields (FIG. 4G) of the new/selected program variable. In step 565, the programming system receives and displays the user input for each of the fields (FIG. 4G) of the present program variable. The depicted process proceeds from step 565 to 566 at which the programming system determines whether the user has selected the option of defining a new program variable. It it is determined at 566 that the user has selected the option of defining a new program variable, the process proceeds to step 567 in which the programming system automatically assigns a program variable identity value to the ID field (FIG. 4G) of the present program variable. Values are assigned sequentially to the ID field of each new program variable by reading from the float type variable counter value stored in the variable files of the internal files 332 (FIG. 3) which is increased each time a new float type variable is defined. From step 567, the process proceeds to step 568 in which the programming system saves the new/edited values for the fields of the present program variable. If it is determined at 566 that the user has not selected the option of defining a new program variable, the process proceeds directly to execute step 568 as described above, after which the process returns to "A1" (to FIG. 6).

FIG. 14 shows a flow diagram at 570 illustrating a sub-process of the programming process of the present invention for editing a digital variable 272 (FIG. 4H). The depicted proceeds from "DV" (from FIG. 6) to step 571 in which the programming system displays a list of all previously defined digital variables. In step 572, the programming system: provides a user interface allowing the user to select from the options of defining a new digital variable, or editing a previously defined digital variable; and receives a corresponding user input. In step 573, the programming system displays values previously entered for all of the fields (FIG. 4H) of the selected digital variable including the digital variable name field, configuration property field, initialization value field 274, access right field, and LED property field 276 (FIG. 4H).

In step 574, the programming system provides an interface allowing the user to edit/define the fields (FIG. 4H) of the present digital variable. In step 575, the programming system receives and displays the user input for each of the fields (FIG. 4H) of the present digital variable. The depicted process proceeds from step 575 to 576 at which the programming system determines whether the user has selected the option of defining a new digital variable. If it is determined at 576 that the user has selected the option of defining a new digital variable, the process proceeds to step 577 in which the programming system automatically assigns a digital variable identity value to the ID field (FIG. 4H) of the present digital variable. Values are assigned to the ID field of each new digital variable by reading from the digital type variable counter value. From step 577, the process proceeds to step 578 in which the programming system saves the news/edited values for the fields of the present digital variable. If it is determined at 576 that the user has not selected the option of defining a new digital variable, the process proceeds directly to execute step 578 as described above, after which the process returns to "A1" (to FIG. 6).

FIG. 15 shows a flow diagram at 580 illustrating a sub-process of the programming process of the present invention for editing a timer variable 278 (FIG. 4I). The depicted proceeds from "T" (from FIG. 6) to 581 at which the programming system displays a list of all previously defined timer variables. In step 582, the programming system: provides a user interface allowing the user to select from the options of defining a new timer variable, or editing a previously defined timer variable, and receives a corresponding user input. In step 583, the programming system displays values previously entered for all of the fields (FIG. 4I) of the selected timer variable including, the timer variable name field, configuration property field, initialization value field 280, and access right field (FIG. 4I).

In step 584, the programming system provides an interface allowing the user to edit/define the fields (FIG. 4I) of the new/selected timer variable. In step 585, the programming system receives and displays the user input for each of the fields (FIG. 4I) of the present timer variable. The depicted process proceeds from step 585 to 586 at which the programming system determines whether the user has selected the option of defining a new timer variable. If it is determined at 586 that the user has selected the option of defining a new timer variable, the process proceeds to step 587 in which the programming system automatically assigns a timer variable identity value to the ID field (FIG. 4I) of the present timer variable. Values are assigned to the ID field of each new timer variable by reading from the long type variable counter value. From step 587, the process proceeds to step 588 in which the programming system saves the new/edited values lot the fields of the present timer variable. If it is determined at 586 that the user has not selected the option of defining a new timer variable, the process proceeds directly to execute step 588 as described above, after which the process returns to "A1" (to FIG. 6).

As mentioned above, proportional integral derivative (PID) variables may also be defined in the programming process of present invention for creating a control program for execution by the LCU 12 (FIG. 1) to control a system having closed loop feed back. For controlling such systems, the LCU 12 (FIG. 1) includes additional software modules which are responsive to the PID variables of the control program loaded to the LCU.

The PID fields include: a PID name field; a time sampling interval field for creating a corresponding timer variable having an identity field carrying an identity value which identifies the timer variable and specifies the length of an associated data field to be allocated by the LCU for the timer variable, a configuration sub-field, and an access right sub-field; a conversion mode field for indicating one of three conversion modes, the conversion mode field having a configuration field and an access right sub-field.

The PID fields also include: a proportional coefficient field for creating a corresponding program variable having an identity field carrying an identity value which identifies the program variable and specifies the length of an associated data field to be allocated by the LCU for the program variable, a configuration field, and an access right field; an integral coefficient field for creating a corresponding program variable having an identity field carrying an identity value which identifies the program variable and specifies the length of an associated data field to be allocated by the ECU for the program variable, a configuration field, and an access right field; a differential coefficient field for creating a corresponding program variable having an identity field carrying an identity value which identifies the program variable and specifies the length of an associated data field to be allocated by the LCU for the program variable, a configuration field, and an access right field; and a hysteresis field for creating a corresponding program variable having an identity field carrying an identity value which identifies the program variable and specifies the length of an associated data field to be allocated by the LCU for the program variable, a configurational field, and an access right field.

The PID fields further include: a process variable delay field for creating a corresponding timer variable having an identity field carrying an identity value which identifies the timer variable and specifies the length of an associated data field to be allocated by the LCU for the timer variable, a configuration field, and an access right field; a process variable average field for creating a corresponding timer variable having an identity field carrying an identity value which identifies the timer variable and specifies the length of an associated data field to be allocated by the ICU or the timer variable, a configuration field, and an access right field; an output upper limit percentage field for creating a corresponding program variable having an identity field carrying an identity value which identifies the program variable and specifies the length of an associated data field to be allocated by the LCU for the program variable, a configuration field, and an access right field; an output lower limit percentage field for creating a corresponding program variable having an identity field carrying an identity value which identifies the program variable and specifies the length of an associated data field to be allocated by the LCU for the program variable, a configuration field, and an access right field; a digital output signal field which must be predefined; and a hardware I/O PID manual mode field which must be predefined.

The PID field further include: a hardware I/O PID/manual mode field for creating a digital variable; a set point hardware I/O field which must be predefined; a set point field for creating a program variable; a process hardware I/O field which must be predefined; a process field for creating a program variable; a manual output percentage hardware I/O field which must be predefined; a manual output percentage field for creating a program variable; an analog output hardware I/O field which must be predefined; an analog output hardware I/O field for creating a program variable; and a pulse length for creating a corresponding program variable having an identity field carrying all identity value which identifies the program variable and specifies the length of an associated data field to be allocated by the LCU for the program variable, a configuration field, and an access right field.

The PID fields further include: a frequency match to maximum output field for creating a corresponding program variable having an identity field carrying an identity value which identifies the program variable and specifies the length of an associated data field to be allocated by the LCU for the program variable, a configuration field, an access right field, and a pulse frequency mode field; a minimum frequency allowed field for creating a corresponding program variable having an identity field carrying an identity value which identifies the program variable and specifies the length of an associated data field to be allocated by the LCU for the program variable, a configuration field, an access right field, and a pulse frequency mode field; a maximum frequency allowed field for creating a corresponding program variable having an identity field carrying an identity value which identifies the program variable and specifies the length of an associated data field to be allocated by the LCU for the program variable, a configuration field, an access right field, and a pulse frequency mode field; and a pulse period field for creating a corresponding program variable having an identity field carrying an identity value which identifies the program variable and specifies the length of an associated data field to be allocated by the LCU for the program variable, a configuration field, an access right field, and a pulse length mode field.

FIG. 15 shows a flow diagram at 590 illustrating a sub-process of the programming process of the present invention for editing a PID variable. The depicted proceeds from "PID" (from FIG. 6) to 591 at which the programming system displays a list of all previously defined PID variables. In step 592, the programming system: provides a user interface allowing the user to select from the options of defining a new PID variable, or editing a previously defined PID variable; and receives a corresponding user input. In step 593, the programming system displays values previously entered for all of the fields of the selected PID variable including the PID variable name field, configuration property field, initialization value field 280, and access right field.

In step 594, the programming system provides an interface allowing the user to edit/define the fields of the new/selected PID variable. In step 595, the programming system receives and displays the user input for each of the fields of the present PID variable. The depicted process proceeds from step 595 to 596 at which the programming system determines whether the user has selected the option of defining a new PID variable. If it is determined at 596 that the user has selected the option of defining a new PID variable, the process proceeds to step 597 in which the programming system automatically assigns a PID variable identity value to the ID field of the present PID variable. Values are assigned sequentially to the ID field of each new PID variable by reading from a PID variable counter value stored in the variable files of the internal files 332 (FIG. 3) which is increased each time a new PID variable is defined. From step 597, the process proceeds to step 598 in which the programming system saves the new/edited values for the fields of the present PID variable. If it is determined at 596 that the user has not selected the option of defining a new PID variable, the process proceeds directly to execute step 598 as described above, alter which the process returns to "A1" (to FIG. 6).

In the preferred embodiment of the present invention, each of the above described variable editing processes is implemented us