WO2000022486A1 - Systeme et procede de generation d'un programme de commande - Google Patents

Systeme et procede de generation d'un programme de commande Download PDF

Info

Publication number
WO2000022486A1
WO2000022486A1 PCT/US1999/024073 US9924073W WO0022486A1 WO 2000022486 A1 WO2000022486 A1 WO 2000022486A1 US 9924073 W US9924073 W US 9924073W WO 0022486 A1 WO0022486 A1 WO 0022486A1
Authority
WO
WIPO (PCT)
Prior art keywords
state
conesponding
condition
program
variable
Prior art date
Application number
PCT/US1999/024073
Other languages
English (en)
Inventor
Richard Harris
Jack Wiens
Joseph Fraser
Heiki Kask
Peter Nobel
Original Assignee
Scientronix, Inc.
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority claimed from US09/172,473 external-priority patent/US6167319A/en
Priority claimed from US09/189,027 external-priority patent/US6505341B1/en
Application filed by Scientronix, Inc. filed Critical Scientronix, Inc.
Priority to CA002347491A priority Critical patent/CA2347491A1/fr
Priority to JP2000576325A priority patent/JP2002527803A/ja
Priority to AU11154/00A priority patent/AU1115400A/en
Priority to EP99954929A priority patent/EP1135715A4/fr
Publication of WO2000022486A1 publication Critical patent/WO2000022486A1/fr

Links

Classifications

    • G—PHYSICS
    • G05—CONTROLLING; REGULATING
    • G05B—CONTROL OR REGULATING SYSTEMS IN GENERAL; FUNCTIONAL ELEMENTS OF SUCH SYSTEMS; MONITORING OR TESTING ARRANGEMENTS FOR SUCH SYSTEMS OR ELEMENTS
    • G05B11/00—Automatic controllers
    • G05B11/01—Automatic controllers electric
    • G05B11/36—Automatic controllers electric with provision for obtaining particular characteristics, e.g. proportional, integral, differential
    • G05B11/42—Automatic controllers electric with provision for obtaining particular characteristics, e.g. proportional, integral, differential for obtaining a characteristic which is both proportional and time-dependent, e.g. P. I., P. I. D.
    • G—PHYSICS
    • G05—CONTROLLING; REGULATING
    • G05B—CONTROL OR REGULATING SYSTEMS IN GENERAL; FUNCTIONAL ELEMENTS OF SUCH SYSTEMS; MONITORING OR TESTING ARRANGEMENTS FOR SUCH SYSTEMS OR ELEMENTS
    • G05B19/00—Programme-control systems
    • G05B19/02—Programme-control systems electric
    • G05B19/04—Programme control other than numerical control, i.e. in sequence controllers or logic controllers
    • G05B19/05—Programmable logic controllers, e.g. simulating logic interconnections of signals according to ladder diagrams or function charts
    • G05B19/056—Programming the PLC

Definitions

  • 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 and for generating a flow chart corresponding to the control program.
  • LCU logic control unit
  • PLC programmable logic controller
  • 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.
  • 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.
  • 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.
  • 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.
  • 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 condition, 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 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.
  • 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
  • LCU logic control unit
  • Fig. 2 is a schematic block diagram of a universal controller (UCB) which is a preferred embodiment of the LCU of Fig. 1 ;
  • Fig. 3 A 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. 3B 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 41 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 interface 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.
  • 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.
  • Figs. 47-50 show a flow diagrams depicting a process for generating a cross-reference listing.
  • 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.
  • 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.
  • LCU logic control unit
  • each of the digital input ports 14 and each of the digital output ports 16 includes eight bits.
  • the front panel port 26 and graphics port 28 are both RS232 type serial communication ports, and the LCU 12 includes all hardware required for each RS232 port.
  • the serial bus port 18 is a synchronous serial input/output port.
  • 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.
  • 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: an 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.
  • 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
  • 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.
  • end user GUI end user graphical user interface
  • 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 60 are to be activated.
  • 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.
  • 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.
  • the LED panel 58 includes 128 individually addressable LED's 60, and the switch panel 62 includes 4 rows of 40 switches 64.
  • the analog input/output extension unit 31 and digital input/output extension unit 35 are non-intelligent cards.
  • the extension units 31 and 35 may include additional processing capability and additional memory capacity.
  • 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 interface device 84 such as a keyboard or mouse coupled with the computer, and a printer 85.
  • 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.
  • the programming process of the present invention may be implemented using any combination of computer programming software, firmware or hardware.
  • 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.
  • 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.
  • 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
  • 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.
  • 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. 3 A 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).
  • 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.
  • the programming process is implemented in C language.
  • 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
  • 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.
  • 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.
  • 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.
  • OS kernel multitasking operating system kernel
  • 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. 3 A).
  • the configurable I/O system 184 includes a plurality of I/O drivers.
  • I/O device variables input/output device variables
  • memory location variables include program variables and digital variables.
  • each of the variables includes an identification field used in the programming 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.
  • 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.
  • ID field identity field
  • 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.
  • 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
  • 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.
  • 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 analog input variable illustrated at 200 also include a sample number field
  • 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 characters 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 identifies the EU low program variable 225; and the EU low sub-fields 217, 218, 219, and 220.
  • 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 EU 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.
  • 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.
  • 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 "
  • 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.
  • 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.
  • float type variables include analog input variables, analog output variables, and program variables.
  • 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.
  • name fields including fields 203, 217, and 221 for the depicted analog input variable
  • 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.
  • 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 sub-field, an EU high access right sub-field, and an EU high configuration status sub- field.
  • EU low field 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
  • EU high field EU high 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.
  • 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.
  • 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.
  • analog input variable 200 (Fig. 4A) does not include an access right field. Access to analog 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 by 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.
  • 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 by 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 L
  • 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.
  • 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.
  • 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 LCU 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.
  • ID field an identity 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.
  • 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.
  • 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 LCU 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.
  • 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 IO 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).
  • 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.
  • 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.
  • 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.
  • 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.
  • 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. 41 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.
  • 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.
  • 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.
  • step 404 the programming process receives a user input selected from the choices specified in step 402.
  • the programming process determines whether the option of editing variables has been selected.
  • 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).
  • 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).
  • 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).
  • 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.
  • 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.
  • 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.
  • step 424 the programming process receives a user input indicating one of the variable editing options provided in step 422.
  • 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 "Al" (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).
  • the programming process determines whether the user has selected the option of editing front panel LED variables, and if so, the process proceeds to "LED" (to Fig. 11).
  • 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).
  • 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).
  • 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 (Al variable) 200 (Fig. 4A).
  • the depicted proceeds from "Al" (from Fig. 6) to 452 at which the programming system displays a list of all previously defined analog input variables.
  • 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 input.
  • 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).
  • the fields 202-211 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.
  • the programming system receives and displays the user input for each of the fields 202-211 (Fig. 4 A) of the present analog input variable.
  • 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 files 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 generates a new EU low program variable 225 (Fig.
  • 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.
  • step 470 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.
  • 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 user input.
  • 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).
  • 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.
  • step 490 the programming system receives and displays the user input for each of the fields (Fig. 4B) of the present analog output variable.
  • 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.
  • 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.
  • step 500 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.
  • 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.
  • 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.
  • the programming system provides an interface allowing the user to edit/define the fields (Fig. 4C) of the present digital input variable.
  • 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.
  • step 526 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. If 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 "Al" (to Fig.
  • 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).
  • DO variable digital output variable
  • 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.
  • 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.
  • 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.
  • step 534 the programming system provides an interface allowing the user to edit/define the fields (Fig. 4D) of the present digital output variable.
  • step 535 the programming system 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.
  • step 537 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 "Al" (to Fig. 6). Fig.
  • 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.
  • 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.
  • 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).
  • step 524 the programming system provides an interface allowing the user to edit/define the fields (Fig. 4E) of the present LED variable.
  • 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.
  • step 528 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 "Al" (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.
  • 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.
  • 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).
  • 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.
  • 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.
  • 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, after which the process returns to "Al" (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.
  • 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.
  • 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).
  • step 564 the programming system provides an interface allowing the user to edit define the fields (Fig. 4G) of the new/selected program variable.
  • 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. If 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.
  • 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).
  • step 571 the programming system displays a list of all previously defined digital variables.
  • 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.
  • 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).
  • step 574 the programming system provides an interface allowing the user to edit define the fields (Fig. 4H) of the present digital variable.
  • 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 new/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 "Al" (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. 41).
  • the depicted proceeds from "T" (from Fig. 6) to 581 at which the programming system displays a list of all previously defined timer variables.
  • 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.
  • the programming system displays values previously entered for all of the fields (Fig. 41) of the selected timer variable including the timer variable name field, configuration property field, initialization value field 280, and access right field (Fig. 41).
  • step 584 the programming system provides an interface allowing the user to edit/define the fields (Fig. 41) of the new/selected timer variable.
  • step 585 the programming system receives and displays the user input for each of the fields (Fig. 41) 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. 41) 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.
  • step 587 the process proceeds to step 588 in which the programming system saves the new/edited values for 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 "Al" (to Fig. 6).
  • 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.
  • 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 LCU for the program variable, a configuration field, and an access right field; a differential coefficient field for creating a corresponding
  • 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 LCU for 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
  • the PID fields 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 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.
  • 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
  • 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.
  • 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.
  • 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.
  • step 594 the programming system provides an interface allowing the user to edit/define the fields of the new/selected PID variable.
  • 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.
  • 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, after which the process returns to "Al" (to Fig. 6).
  • each of the above described variable editing processes is implemented using a windows type user interface which allows the user to select functions including save, delete, and cancel at any time during the variable editing sub-process.
  • the save, delete, and cancel functions respectively allow for saving fields entered for a variable, deleting a previously defined variable, and canceling edits made to fields of a variable.
  • the user interface for each of the above described editing processes provides the user with an option to select a move function allowing the user to rearrange the order of the variables displayed in steps 452, 482, 521, 531, 541, 551. 561, 571, 581, 591 of the variable editing sub-processes.
  • Fig. 17 shows a flow diagram at 610 illustrating a sub-process for generating a variable listing in the programming process of the present invention.
  • the depicted process proceeds from "A2" (from Fig. 5) to step 612 in which the programming system displays (via the display unit 83 of the programming system 80 (Fig. 1) or via a printer coupled with the programming system 80) all variables previously defined for a present control program.
  • step 614 the programming system displays values entered for all of the fields associated with the previously defined variables.
  • the depicted proceeds from step 614 back to "A" (to Fig. 5).
  • Each program level, which defines a sub-process of the control program includes a plurality of states which the control program is to operate in.
  • There are two types of program levels that may be defined in the programming process including a task program level, and a sub-routine program level.
  • Each task program level created in the programming process defines a major sub-process, or thread, of the control program which is to be asynchronously executed by the LCU 12 (Fig. 1).
  • the first program level defined must be a task program level.
  • the operating system kernel 182 (Fig. 3B) is a multitasking system in that if the operating system receives a request from two or more program levels simultaneously, the highest program level is given priority in competing for the processing resources of the CPU 90 (Fig. 2) of the UCB 88.
  • subroutine program levels are used in the programming process to define sub-processes of the control program which are to be called many times from another one of the program levels.
  • Each subroutine program level is called from one, and only one, calling program level of the control program which may be a task program level or another sub-routine program level.
  • each subroutine program level defines a sub-process of the control program which is executed by the LCU 12 (Fig. 1) in the thread of the sub-process defined by the calling program level. Details related to calling a subroutine program level and returning from a subroutine program level are described in further detail below.
  • a plurality of states associated with the program level are defined by the user.
  • Each state assigns user specified values to user specified variables, thereby defining a state of operation of the system under the control of the control program.
  • Each state must include at least one condition for transition from the corresponding state to a destination state. Transition from a source state to a destination state takes place during execution of the control program when the relevant user defined condition is satisfied.
  • user defined conditions test the value of specified variables, and also specify a transition from a present state to a destination state if the condition is determined to be true.
  • the starting point for the user in the programming process is at the first program level and first state of a control program.
  • the user can use either an address or descriptive name to identify each program level, state, and condition.
  • the programming process when executed by the programming system 80 (Fig. 1) automatically generates an address for each new state and each new condition ofthe control program.
  • Each program level is assigned a program level address, or program level number, X, by the user.
  • the program level numbers, X, for a particular control program are user specified and need not be numbered sequentially.
  • Each state of a particular program level is assigned a state number, Y, and therefore each state has a unique state address, X:Y.
  • the state numbers, Y are assigned sequentially to each state of a particular program level in the programming process as further explained below.
  • Each condition of a particular state is assigned a condition number, Z, and therefore each condition has a condition address, X:Y:Z, where Z is a condition number of a condition in state Y and program level X.
  • the condition numbers, Z are assigned sequentially for each state Y of each program level X in accordance with the programming process.
  • the address of each user defined program level, state, and condition is stored in the source file ofthe internal files 132 (Fig. 3 A), and then passed to the LCU 12 (Fig. 1) via the compiler 136, data converter 164, and data loader 172 (Fig. 3 A).
  • a user specified condition may specify the calling of a particular subroutine program level upon satisfaction of the specified condition.
  • the user is required to specify: a destination state address of a destination state residing in the subroutine program level; as well as a subroutine state address of a state residing in the calling to which the control program is to proceed after execution ofthe subroutine program level.
  • Each subroutine program level must include at least one condition which, if determined to be true during execution ofthe control program, indicates a return to the calling program level associated with the subroutine program level.
  • Fig. 18 shows a flow diagram at 630 illustrating a sub-process for editing program levels, states, and conditions of a user specified control program created via the programming process ofthe present invention.
  • the depicted process proceeds from "B" (from Fig. 5) to step 632 in which, for each previously defined program level, the programming system displays values entered for associated program level fields including a program level ID field which carries the user specified program level number, 'X', a program level type field which carries a value indicative of whether the corresponding program level is a task program level or a sub-routine program level, and a program level description field which carries a user specified character string descriptive ofthe function ofthe corresponding program level ofthe control program.
  • the programming system provides an interface allowing the user to choose from: a first option of selecting one ofthe previously defined program levels displayed in step 632, for editing; or a second option of defining a new program level.
  • step 636 the programming system receives a user input based on the choices provided in step 634, after which the process proceeds to 638 at which it is determined whether the user has chosen the option of defining a new program level. If it is determined at 638 that the user has not chosen the option of defining a new program level, but rather has chosen the option of selecting a previously defined program level for editing, the depicted process proceeds to "E" (to Fig. 19) to execute a sub-process for editing a program level as further described below.
  • step 640 the programming system provides a user interface allowing the user to enter values for the program level fields associated with the new program level including the program level number field, program level description field, and program level type field.
  • step 642 the programming system receives and displays the user input for the program level number field, program level description field, and program level type field.
  • step 642 the depicted process proceeds to "F" (to Fig. 20) to execute a state editing sub-process providing a user interface allowing the user to define states ofthe new program level as further described below.
  • Fig. 19 shows a flow diagram at 650 illustrating a program level editing sub-process for editing a previously defined program level.
  • the depicted process proceeds from "E" (from Fig. 18) to step 652 in which, for each previously defined state ofthe program level selected for editing in step 636 (Fig. 18), the programming system displays associated values for state fields including a state name field, and a state address field which carries an associated state address X:Y.
  • the user interface provided by the program level editing sub- process provides the user with an option to select a "MOVE" function allowing the user to rearrange the order ofthe states displayed in step 652.
  • the programming system displays values for condition fields for each of a list of previously defined conditions for transition from the corresponding state.
  • the condition fields include: a condition address field carrying a condition address (X:Y:Z) indicative ofthe corresponding condition; a condition name field carrying a user specified character string descriptive ofthe corresponding condition; a destination state address field carrying a user specified destination state address (X, Y) of a user specified destination state to which the process is to proceed if the corresponding condition is true; and a destination state name field carrying a user specified character string descriptive of the destination state.
  • step 656 the programming process: provides an interface allowing the user to select from the options of defining a new state or a new condition, or selecting from the previously defined states and conditions ofthe program level selected in step 636 (Fig. 18); and receives a corresponding user input.
  • step 656 it is determined at 658 whether the user has selected the option of defining a new state, and if so, the depicted process proceeds to "F" (to Fig. 20) to execute a state editing sub-process providing a user interface allowing the user to define a new state as further described below.
  • Fig. 20 shows a flow diagram at 670 illustrating a state editing sub-process for implementing a user interface allowing the user to edit states of a present program level ofthe control program.
  • the state editing sub- process 670 is implemented using a windows type user interface which allows the user to select functions including save, delete, and cancel at any time during editing ofthe new/selected state ofthe control program.
  • the save, delete, and cancel functions respectively allow for saving fields entered for a state, deleting a previously defined state ofthe control program, and canceling edits made to fields of a state.
  • the user interface provides for: a first interface (e.g., a cursor location at which text may be entered) allowing the user to enter text only for a message; and a second interface means allowing the user to enter text and variables for the message as further described below.
  • a first interface e.g., a cursor location at which text may be entered
  • a second interface means allowing the user to enter text and variables for the message as further described below.
  • step 674 the programming system: provides a user interface allowing the user to enter a descriptive name associated with the new/selected present state ofthe present program level; and receives the corresponding user input. If the present state is a previously defined state which has been selected to be edited, the programming system initially displays the previous entry for the name field. If the present state is a new state, the programming system initially displays no entry. In step 676, the programming system provides a user interface allowing the user to optionally enter a character string forming a descriptive message for a text only message field associated with the new/selected state. In step 678, the programming system receives and displays the user input for the message field.
  • step 680 the programming system provides an interface allowing the user to optionally define/edit a formula for the new/selected state. From step 680, the process proceeds to 682 at which it is determined whether the user has selected the option of defining a formula for the present state. If it is determined at 682 that a formula is to be defined, the depicted process proceeds to "H" (to Fig. 23) to execute a state formula editing process as described further below, after which the process proceeds to step 686. If it is determined at 682 that a formula is not to be defined, the depicted process proceeds directly to step 686 in which the programming system provides a user interface allowing the user to optionally enter a log message for the present state.
  • step 688 It is then determined at 688 whether the user has selected the option of entering a log message, and if so, the depicted process proceeds to "J " ' (to Fig. 20) to execute a log message editing process as further described below, after which the process proceeds to step 690. If it is determined at 688 that the user has not selected the option of entering a log message, then the process proceeds directly from 688 to step 690.
  • step 690 the programming system displays a list of all previously entered state- defining type variables including the analog output variables, digital output variables, program variables, digital variables, front panel LED variables, and timer variables.
  • the user interface ofthe state editor provides the user with an option to select a view function allowing the user to display, in step 690, only those variables previously selected to be used in the present state.
  • the user interface provided by the state editing sub-process provides the user with an option to select a "MOVE" function allowing the user to rearrange the order of the states displayed in step 654 (Fig. 19).
  • step 692 the programming system provides a user interface allowing the user to select from the variables displayed in step 690, after which the depicted process proceeds to "K" (to Fig. 21).
  • Fig. 21 shows a flow diagram at 700 illustrating further steps ofthe state editing sub- process illustrated in Fig. 20.
  • the depicted steps allow the user to define and edit values to be assumed by selected variables upon transition ofthe control program to the present state during execution ofthe control program.
  • the depicted process proceeds from "K" (from Fig. 20) to step 702 in which the programming system: provides a user interface allowing the user to override the default value entered for the access right field ofthe variable selected in step 686 (Fig. 20); and receives a corresponding user input. For example, the default value previously entered for an access right field of a particular variable may be read only.
  • Step 702 allows the user to configure the logic control unit 12 (Fig.
  • step 702 the programming system modifies the access right field in accordance with the user input received in step 702.
  • step 706 the programming system provides a user interface allowing the user to select from the options of: (1) assigning a value to the selected variable; or (2) assigning another variable to the variable selected in step 692 (Fig. 20).
  • the process proceeds from step 706 to 708 at which the programming system determines whether the user has selected the option of assigning a value to the selected variable. If the user has selected the option of assigning a value to the selected variable, the depicted process proceeds to execute steps 710 and 712 in which the programming system: provides a user interface allowing the user to enter a value for the selected variable; and receives, assigns, and displays the entered value.
  • step 718 the programming system displays a list of all possible variables which may be assigned to the present variable selected in step 692 (Fig. 20).
  • the present variable may be assigned the value of any other variable for which the same type of data field (i.e., long value, floating point value, and digital value) is to be allocated by the LCU 12 (Fig. 1) during execution ofthe control program. Additionally, a long value type variable may be assigned the value of a floating point type variable, and vice versa.
  • step 720 the programming system provides a user interface allowing the user to select from the list of variables displayed in step 718.
  • step 722 the programming system receives, assigns, and displays the variable selected to be assigned to the present variable selected in step 692 (Fig. 20).
  • the depicted process proceeds from step 722 to 724 at which it is determined whether a timer variable has been selected in step 692 (Fig. 20) for the present state. If it is determined at 724 that a timer variable has been selected in step 692 (Fig. 20) to be used in defining the present state, the process proceeds to "L" (to Fig. 22) to execute a sub-process of configuring control of a timer associated with the present timer variable, after which the process proceeds to 726. If it is determined at 724 that a timer variable has not been selected in step 692 (Fig. 20), the process proceeds from 724 directly to 726 at which it is determined whether the present state is a new state or a previously defined state.
  • step 726 If it is determined at 726 that the present state is a new state, the process proceeds to 727 in which the programming system automatically assigns a state number, Y, to the state number field ofthe present state, after which the process proceeds to step 728 in which the programming system generates and saves source code for the present state based on the user input described above. If it is determined at 726 that the present state is not a new state, but is rather a previously defined state, the process proceeds directly from 726 to execute step 728 as described above.
  • Fig. 22 shows a flow diagram at 730 illustrating a timer configuring sub-process ofthe programming process for configuring the control of a timer associated with the timer variable selected in step 692 (Fig. 20) for use in the present state ofthe control program.
  • the depicted process proceeds from "L" (from Fig. 21) to step 732 in which the programming system provides a user interface allowing the user to select the option of controlling a timer, associated with the timer variable selected in step 692 (Fig. 20), to start or stop upon activation ofthe present state. From step 732.
  • step 734 the programming system determines whether the user has selected the option of controlling the timer, associated with the present timer variable, to run stop during the present state, and if so, the process proceeds to step 736. Otherwise, the process proceeds directly to "LR" (to Fig. 21) to resume editing ofthe present state.
  • step 736 the programming system provides a user interface allowing the user to select from the options of running, or stopping the timer associated with the present timer variable upon activation ofthe present state during execution ofthe control program by the LCU 12 (Fig. 1). Each timer variable has a timer start/stop field associated with it. In step 738.
  • the programming system provides a user interface allowing the user to select from read/write (R W) or read only (R O) for a second access right field associated with the selected timer variable, and also associated with the present state.
  • the programming system receives user input corresponding with the user interface provided in step 738. For example, if the user selects "running" the timer associated with the present timer variable during the present state, and also selects read/write for the second access right field associated with the present timer variable, then the end user may overwrite the timer start/stop field to stop the timer associated with the present timer variable upon activation ofthe present state. From step 740, process proceeds to "LR" as described above.
  • Fig. 23 shows a flow diagram at 740 illustrating a formula editing sub-process for implementing a user interface allowing the user to define a formula associated with a state ofthe control program.
  • the formula editing process is implemented using a windows type user interface which allows the user to select functions including save, delete, and cancel at any time during the variable editing sub-process.
  • the save, delete, and cancel functions respectively allow for saving fields entered for a formula, deleting a previously defined formula, and canceling edits made to fields of a formula.
  • step 742 the programming system displays: a first variable list ofthe variable names of all previously defined program variables; a second variable list ofthe variable names of all previously defined analog input variables; a third variable list ofthe variable names of all previously defined analog output variables; a fourth variable list ofthe variable names of all previously defined timer variables; a list of operators; and a numerical constant entry means (i.e., a cursor location at which numbers may be entered via the keyboard).
  • the list of operators includes the mathematical operators: add, subtract, multiply, divide, equals, greater of, and least of.
  • step 742 the programming system provides a user interface allowing the user to select from formula building options including: selecting a variable from one ofthe four lists displayed in step 742; entering a numerical constant (including fractional numbers) using the entry means provided in step 742; selecting from the list of operators: or saving the formula.
  • step 744 the programming system receives the user input via the interface provided in step 744. It is then determined at 748 whether the user has selected the option of saving the formula, and if so, the process proceeds to "HR" (to Fig. 20) to resume editing ofthe present state.
  • step 748 the depicted process executes steps 744 and 746 allowing further editing ofthe present formula for the present state until the user selects the option of saving the formula in step 746, after which the process proceeds to step 749.
  • step 749 the programming system generates source code defining the present formula, and saves the present formula to the source file ofthe internal files 132 (Fig. 3 A). From step 749, depicted process proceeds to "HR" (to Fig. 20) to resume editing the present state. Fig.
  • FIG. 24 shows a flow diagram at 760 illustrating steps of a log message editing sub- process for implementing a user interface allowing a user to edit a log message associated with a particular state ofthe control program.
  • the depicted process proceeds from "J" (from Fig. 20), and proceeds to step 762 in which the programming system: provides a user interface allowing the user to enter position coordinates for display of a log message; and receives user input for the position coordinates.
  • the position coordinates are indicative of a position on the LCD 56 ofthe end user front panel 50 (Fig. 1) at which the present log message is to be displayed during execution ofthe control program by the LCU 12 (Fig. 1).
  • Log messages may also be displayed via the graphics display unit 74 (Fig. 1) ofthe end user GUI 65.
  • step 763 the programming system: provides a user interface allowing the user to select from the options of entering text for the log message, or selecting a variable to be displayed as part ofthe log message for the present state; and receives a corresponding user input.
  • the depicted process proceeds to 764 at which the programming system determines whether the user has selected the option of entering text, or the option of selecting a variable. If it is determined at 764 that the user has selected the option of entering text, the depicted process proceeds to step 765 in which the programming system: provides a user interface allowing the user to enter text for the log message; and receives user input.
  • step 767 the programming system: provides a user interface allowing the user to either save the current log message, or add additional text or variables to the current log message; and receives a corresponding user input. If it is determined at 764 that the user has chosen the option of selecting a variable to be displayed with the log message, the depicted process proceeds from 764 to step 768 in which the programming system: provides a user interface allowing the user to select one from a list ofthe variable types including analog input variables, analog output variables, digital input variables, digital output variables, program variables, digital variables, panel LED variables, panel switch variables, timer variables, and PID variables; and receives a corresponding user input indicating a selected variable type.
  • step 769 the programming process displays a list of all previously defined variables ofthe type selected by the user in step 768.
  • step 770 the programming system provides a user interface allowing the user to select a log variable from the list displayed in step 769. The depicted process proceeds from step 770 to execute step 767 as described above.
  • step 771 it is determined whether the user has chosen the option of selecting an additional log variable or text string, and if so, the depicted process repeats steps 763, 764, 765, 767. 769, and 770 until the user selects the option of saving the current log message in step 767. If it is determined at 767 that the user has selected the option of saving the current log message, the process proceeds to step 772 in which the programming system generates source code representing the present log message, and saves the present log message to the source file ofthe internal files 132 (Fig. 3 A), after which the process proceeds to "JR" (to Fig. 20) to resume editing ofthe present state.
  • Fig. 25 shows a flow diagram at 780 illustrating a process for implementing a user interface allowing the user to define limits for the present program level ofthe control program.
  • the depicted process proceeds from "El" (from Fig. 19) and proceeds to step 782 in which the programming system displays a list of all previously defined program levels ofthe control program, excluding the present program level. From step 782, the process proceeds to step 784 in which the programming system: provides a user interface allowing the user to select a limit program level for the present program level from the program levels displayed in step 782; and receives a user selected limit program level. In step 786.
  • the programming system displays a list of all "available” limiting states ofthe user selected limit program level, the available states being those states not previously selected as limiting states for limiting operation ofthe present program level.
  • the programming system displays a list of all "unavailable” limiting states ofthe user selected limit program level, the unavailable limiting states being those which have been previously selected to limit operation ofthe present program level.
  • the programming system provides a user interface allowing the user to select from the list of available limiting states ofthe user selected limit program level; and receives a user selected limiting state.
  • the programming system updates and displays the lists of available and unavailable limiting states ofthe user selected limit program level.
  • a control program When a control program includes a limit for a particular program level, the limit being defined using a limiting state of a limit program level, then the LCU 12 (Fig. 1) executing the control program will activate the particular program level to run only when the corresponding limit program level is currently activated to run in the corresponding limiting state.
  • Fig. 26 shows a flow diagram at 800 illustrating a condition editing sub-process for implementing a user interface allowing the user to define and edit conditions ofthe present state and program level. The depicted process proceeds from "G" (from Fig. 19), and proceeds to step 802 in which the programming system: provides a user interface allowing the user to enter text for a condition name field ofthe new/selected condition; and receives a corresponding user input.
  • a subroutine call condition specifies the calling of a particular subroutine program level upon satisfaction ofthe terms ofthe condition.
  • the user is required to specif ⁇ ': a destination state address of a destination state residing in the subroutine program level; as well as a return state address of a return state residing in the calling program level to which the control program is to proceed after execution ofthe specified subroutine program level.
  • Each subroutine program level must include at least one condition which, if determined to be true during execution ofthe control program, indicates a "RETURN" to the calling program level associated with the subroutine program level.
  • condition editing sub-process varies dependent upon whether the present program level is a subroutine program level or a task program level.
  • step 804 it is determined whether the present program level is a subroutine program level. If it is determined at 804 that the present program level is a subroutine program level, the depicted process proceeds to step 806 in which the programming system provides a user interface allowing the user to choose from the options of: selecting a destination state address (X:Y) from a list of all previously defined states in all program levels ofthe control program; or selecting "RETURN". From step 806, the depicted process proceeds to step 810 in which the programming system receives the corresponding user input.
  • step 808 the programming system provides a user interface allowing the user to select a destination state address (X:Y) from a list of all previously defined states in all program levels ofthe control program. From step 808, the depicted process proceeds to step 810 in which the programming system receives the corresponding user input.
  • step 812 the programming system: provides a user interface allowing the user to select from the options of defaulting to direct, or goto type transition (as opposed to a subroutine type transition), or indicating a call transition by selecting a return state address (X:Y) of a state from a list of all previously defined states ofthe present program level; and receives a corresponding user input.
  • the depicted process proceeds to "Ml" (to Fig. 27).
  • the user interface includes a pull down window labeled "SUB-RETURN" which, when clicked on, displays a list of all previously defined states ofthe present program level, and allows the user to select the return state from those displayed.
  • Fig. 27 shows a flow diagram at 820 illustrating further steps ofthe condition editing sub-process of Fig. 26.
  • the depicted process proceeds from "Ml" (from Fig. 26), and proceeds to step 822 in which the programming system displays a list of all previously entered variables including analog input variables, analog output variables, digital input variables, digital output variables, program variables, digital variables, front panel LED variables, timer variables, and PID variables.
  • step 824 the programming system provides a user interface allowing the user to select from the options of: saving the present condition; or selecting from displayed variables to be used in defining condition statements ofthe present condition.
  • the programming system receives a user input based on the options provided in step 824. It is then determined at 828 whether the user has selected the option of saving the present condition.
  • the process determines at 830 whether the user has chosen the option of selecting one ofthe variables from the variable types including analog input variables, analog output variables, or program variables, and if so, the process proceeds to "N" (to Fig. 29) to implement a sub-process, after which the process proceeds to 834. If it is determined at 830 that the user has not selected one ofthe analog input variables, analog output variables, or program variables, the process proceeds directly to 834.
  • step 834 it is then determined at 834 whether the user has chosen the option of selecting a timer variable, and if so, the process proceeds to step 836 in which the programming system indicates the name and ID value ofthe timer variable selected, after which the process proceeds to "M2" (to Fig. 28). If it is determined at 834 that the user has not selected a timer variable, the depicted process proceeds to determine at 838 whether the user has selected a variable from the variable types including the digital variables, digital input variables, digital output variables, front panel LED variables, or panel switch variables, and if so the process proceeds to "O" (to Fig. 32).
  • step 828 If it is determined at 828 that the user has selected the option of saving the present condition in step 826, the process proceeds to step 840 in which the programming system generates source code defining the present condition, and saves the present condition to the source file ofthe internal files 132 (Fig. 3 A).
  • Fig. 28 shows a flow diagram at 840 illustrating a sub-process for defining check-state condition statements.
  • the depicted process proceeds from "M2" (from Fig. 27), and proceeds to step 841 in which the programming system: provides a user interface allowing the user to select the option of editing/defining a check-state condition statement for the present condition; and receives a user input.
  • the process proceeds from step 841 to 842 at which the programming system determines whether the user has selected the option of editing or defining a check-state condition statement. If it is determined at 842 that the user has not selected the option of editing a check-state condition statement, the process proceeds directly to "Ml" (to Fig. 27).
  • step 843 the programming system displays indicia of whether any state ofthe present program level has been selected to be used in defining a check-state condition statement.
  • step 844 the programming system displays a list of program levels previously defined in the control program, excluding the present program level.
  • step 845 the programming system: provides a user interface allowing the user to select from the program levels displayed in step 844; and receives a user selected program level for defining a check-state condition statement.
  • step 846 the programming system displays indicia of whether the present state has been selected to be used in defining a check-state condition statement.
  • step 847 the system displays a list of states ofthe user selected program level for editing/defining a check-state condition statement.
  • the system provides a user interface allowing the user to select a state to be used in defining a check-state condition statement; and receives a user selected state.
  • the programming system generates a check-state condition statement based on the user selected state received in step 848.
  • the check-state condition statement specifies a criterion that the user selected state must be active, or running, for the present condition to be true.
  • the above described steps ofthe condition editing sub-process 800 are implemented using a windows type user interface which allows the user to select functions including save, delete, and cancel at any time during editing ofthe conditions ofthe control program.
  • the save, delete, and cancel functions respectively allow for saving fields entered for conditions, deleting previously defined conditions ofthe control program, and canceling edits made to fields of a condition.
  • the user interface of the condition editor provides the user with an option to select a move function allowing the user to rearrange the order ofthe conditions displayed in step 654 (Fig. 19), and the order ofthe variables displayed in step 822 (Fig. 27).
  • the user interface ofthe state editor provides the user with an option to select a view function allowing the user to display, in step 822 (Fig.
  • Fig. 29 shows a flow diagram at 850 illustrating steps ofthe condition editing sub- process for conditioning a state transition on the present value of an analog input variable, analog output variable, or program variable.
  • the process proceeds from "N" (from Fig. 27), and proceeds to step 852 in which the user is provided with an interface allowing the user to select logical inversion as an operator in defining a current condition statement ofthe present condition.
  • the logical inversion option if selected, provides for logical inversion ofthe value of the variable selected in step 824 (Fig. 27) for purposes of defining a present condition statement for the present condition.
  • the programming system receives a user input for the logical inversion option.
  • step 856 receives a user input for the logical inversion option.
  • step 858 the programming system receives a corresponding user input It is then determined at 860 whether the user has selected the "LOW” operator, and if so, the process proceeds to "Nl" (to Fig. 30A) to implement a "less than” condition statement editing sub-process, further described below, after which the process proceeds to 862. If it is determined at 860 that the user has not selected the "LOW” operator, the process proceeds directly to 862 to determine whether the user has selected the "HIGH” operator.
  • the process proceeds to "N2" (to Fig. 30B) to implement a "greater than” condition statement editing sub-process, further described below, after which the process proceeds to 864. If it is determined at 862 that the user has not selected the "HIGH” operator, the process proceeds directly to 864 to determine whether the user has selected the "DEAD BAND” operator. If it is determined at 864 that the user has selected the "DEAD BAND” operator, the process proceeds to "N3" (to Fig. 31) to implement a dead band condition statement editing sub-process, further described below, after which the process proceeds to "Ml" (to Fig. 27).
  • Fig. 30A shows a flow diagram at 870 illustrating a "less than” condition statement editing sub-process ofthe process 850 (Fig. 8) for conditioning a state transition on the current value of an analog input variable, analog output variable, or program variable.
  • the depicted process proceeds from "Nl” (from Fig. 29), and proceeds to step 872 in which the programming system displays a list of all previously defined variables which may logically be compared with the variable selected in step 824 (Fig. 27).
  • the variables displayed in step 872 include all previously defined analog input variables, analog output variables, and program variables.
  • step 874 the programming system: provides a user interface allowing the user to select a "less than” reference variable from the variables displayed in step 872; and receives a corresponding user input.
  • step 876 the programming system generates a "less than” condition statement for determining whether the selected variable is less than the "less than” reference variable selected in step 874, after which the process proceeds to "N1R" (to Fig. 29).
  • Fig. 30B shows a flow diagram at 880 illustrating a "greater than” condition statement editing sub-process ofthe process 850 (Fig. 8) for conditioning a state transition on the current value of an analog input variable, analog output variable, or program variable. The depicted process proceeds from "N2" (from Fig.
  • step 882 the programming system displays a list of all previously defined variables which may logically be compared with the variable selected in step 824 (Fig. 27).
  • the variables displayed in step 882 include all previously defined analog input variables, analog output variables, and program variables.
  • step 884 the programming system: provides a user interface allowing the user to select a "greater than” reference variable from the variables displayed in step 882; and receives a corresponding user input.
  • step 886 the programming system generates a "greater than” condition statement for determining whether the selected variable is greater than the "greater than” reference variable selected in step 884, after which the process proceeds to "N2R" (to Fig. 29).
  • the present condition specifies that the currently selected variable must be between "greater than” reference variable and the "less than” reference variable.
  • the user may initialize another program variable to a constant value. Note also that if the access right field ofthe program variable 266 (Fig. 4G) carries a read/write value indicating that the program variable may be written to via the end user GUI 65 (Fig. 1), then the initialized program variable may be changed during execution ofthe control program.
  • Fig. 31 shows a flow diagram at 890 illustrating a "dead band” condition statement editing sub-process ofthe process 850 (Fig. 29) for conditioning a state transition on the variation ofthe value of an analog input variable, analog output variable, or program variable during a given sample period.
  • a "dead band” condition statement is used to modify a corresponding "less than” condition statement, and/or a corresponding "greater than” condition statement to allow for a dead band in which state transition will not be triggered.
  • Each "dead band” condition statement must be complemented by a "less than” condition statement or a "greater than” condition statement defined in the condition editing sub-process 850 (Fig. 29) for the same condition.
  • step 892 the programming system displays a list of all previously defined variables which may be used in defining a dead-band range for the current selected variable.
  • the variables displayed in step 892 include all previously defined analog input variables, analog output variables, and program variables.
  • step 894 the programming system: provides a user interface allowing the user to select a "dead-band" reference variable from the variables displayed in step 892; and receives a corresponding user selected reference variable. The user initializes another program variable to a constant value and uses the initialized program variable as the selected reference variable.
  • step 896 the programming system generates a "dead band” condition statement based on the user input received in step 892, after which the process proceeds to "N3R" (to Fig. 29).
  • a "greater than” condition statement may specify that the selected variable must be greater than a reference variable having a user- assigned value of 100. If a corresponding dead-band condition statement specifies a dead-band reference variable having a user-assigned value of 2, then the conesponding selected variable must be greater than 101 for the logic control unit 12 (Fig. 1) to determine that a state transition is to occur. In this case, a dead-band lies in the range between 100 and 101.
  • the access right field ofthe program variable 266 (Fig. 4G) carries a read/write value indicating that the initialized program variable may be written to via the end user GUI 65 (Fig. 1), then the initialized program variable may be changed during execution of the control program, thereby changing the corresponding dead-band condition statement.
  • Fig. 32 shows a flow diagram at 900 illustrating steps ofthe condition editing sub- process for conditioning a state transition on the current value of a digital variable, digital input variable, digital output variable, front panel LED variable, or a switch panel variable.
  • the process proceeds from "O" (from Fig. 27), and proceeds to 902 at which the programming system determines whether the user selected variable (determined at 838 of Fig. 27 to be a digital value type variable) is an LED type variable. If it is determined at 902 that the user selected variable is an LED type variable, the depicted process proceeds to step 904 in which the programming system provides a user interface allowing the user to select from logical operators including: "ON in AND”, “ON in OR”, “OFF in AND”, “OFF in OR”, "BLINK FAST in
  • step 904 the process proceeds to step 906 in which the programming system receives a user input indicating an operator to be used in defining a logic condition statement. From step 906, the process proceeds to step 908 in which the programming system generates a logic condition statement based on the user input received in step 906. after which the process proceeds back to "Ml" (to Fig. 27) to continue editing the present condition.
  • step 910 the programming system provides a user interface allowing the user to select from logical operators including: “ON in AND”, “ON in OR”, “OFF in AND”, “OFF in OR”, “BLINK FAST in AND”, “BLINK FAST in OR”, “BLINK SLOW in AND”, and “BLINK SLOW in OR”. From step 910, the process proceeds to execute steps 906 and 908 as described above, after which the process proceeds back to "Ml" (to Fig. 27) to continue editing the present condition.
  • condition statement having a plurality of criteria. For example, if the user selects "ON in AND" for a first user selected variable, and then saves the condition (in step 828 of Fig. 27) without defining any further condition statements, then the condition will be satisfied if the first user selected variable is determined to be ON.
  • Fig. 33 shows a flow diagram at 920 illustrating steps of a sub-process for generating program listings of program levels, states, conditions, and variables of a control program created in accordance with the programming process ofthe present invention. The depicted process proceeds from "C” (from Fig. 5), and proceeds to step 922 in which the programming system provides a user interface allowing the user to select from program listing choices including instruction listings, flow chart listings, cross-reference listings, tag listings, conditions listings, and a listing of compiled data.
  • step 924 the programming system receives a user selection based on the choices provided in step 922. It is then determined at 926 whether the user has selected the option of generating an instruction listing, and if so the process proceeds to "S" (to Fig. 35) to implement a process of generating instruction listings. It is subsequently determined at 928 whether the user has selected the option of generating flow chart listings, and if so, the process proceeds to "T” (to Fig. 39) to implement a process of generating flow cha ⁇ listings. It is determined at 930 whether the user has selected the option of generating cross-reference listings, and if so, the process proceeds to "U" (to Fig. 47) to implement a process of generating cross-reference listings.
  • the programming system determines at 932 whether the user has selected the option of generating tag listings, and if so, the process proceeds to step 933 to generate tag listings which comprise a list of all variables previously defined for a control program, and the values entered for all fields of each ofthe variables. This listing is particularly valuable for use by the end user who may use the tag listing to determine the access rights to each variable from the end user GUI 65 (Fig. 1). Finally, it is determined at 934 whether the user has selected the option of generating condition listings, and if so, the process proceeds to step 935 generate condition listings as further explained below. From 934, the process proceeds to "A" (to Fig. 5).
  • Fig. 34 shows an exemplary instruction listing at 940 generated by the programming system ofthe present invention from the internal files 132 (Fig. 3 A).
  • the instruction listing at 940 includes: an entry 941 indicating the name and program level number of a current program level; an entry 942 indicating the name and address of a limiting program level defined for the current program level indicated at 941 (if there is one defined); a plurality of entries 943 each indicating the name and address of a limiting state ofthe limiting program level indicated at entry 942; a plurality of entries 944 each indicating the name and address of a state ofthe current program level indicated at entry 941; a plurality of entries 945 each indicating the name and address of a condition ofthe corresponding state identified in the corresponding above listed entry 944; and a plurality of entries 946, each corresponding with one ofthe entries 945 and each providing an indication ofthe type of transition specified by the corresponding condition, and the name and address of a destination state.
  • the instruction listing further includes a plurality of entries 947 each indicating a variable type, a variable name of a corresponding variable defined in the state identified in the corresponding entry 944, a value assigned by the corresponding state, and the value previously entered in the access right field of the corresponding variable.
  • the instruction listing further includes a plurality of entries 948 each indicating a variable type, a variable name of a corresponding variable used in a conditional statement ofthe condition identified in the corresponding entry 945, and the corresponding conditional statement.
  • the corresponding entry 946 includes: an entry 949 having the name and address of a destination state of a subroutine program level; and an entry 950 having the name and address of a return state ofthe calling program level.
  • Fig. 35 shows a flow diagram at 952 illustrating a process ofthe present invention for generating an instruction listing.
  • the depicted process proceeds from "S" (from Fig. 33), and proceeds to step 953 in which the programming system displays a list of all previously defined program levels.
  • the programming system provides a user interface allowing the user to select from displayed program levels; and receives one or more user selected program levels.
  • the programming system renders the name and program level number ofthe current program level.
  • the programming system renders the name and address of limiting states previously defined for the current program level.
  • the programming system renders the name and address of a current state ofthe current program level.
  • the programming system renders, below the name and address ofthe current state, the name and address ofthe current condition for transition from the current state.
  • step 959 the programming system renders the name and address of a destination state to which the control program is to proceed if the current condition is true, and also renders indicia ofthe transition type specified by the cunent condition.
  • the programming renders "GOTO” for a direct type transition, and "CALL" for a call transition to a subroutine state.
  • the process then proceeds to 960 at which the programming system reads the source file ofthe internal files 132 (Fig. 3 A) to determine whether there are more conditions defined for the current state.
  • step 961 the system reads the source file to fetch the next condition as the current condition, after which the process proceeds to re-execute steps 958 and 959 as described above. If it is determined at 960 that there are not more conditions previously defined for the current state, the programming system reads the source files to determine at 962 whether there are more states previously defined for the current program level. If it is determined at 962 that there are more states defined for the current program level, the process proceeds to step 963 in which the programming system reads the source file to fetch the next state as the current state, after which the process proceeds back to step 957 as described above.
  • step 964 the programming system determines, based on the user selected program levels received in step 954. whether there are more program levels for which to generate instruction listings. If it is determined at 964 that there are more program levels, the process proceeds to step 966 in which the programming system reads the source file ofthe internal files 132 (Fig. 3 A) to fetch the next program level as the current program level. From step 966. the process proceeds to step 968 in which the programming system reads the source file to fetch the first state ofthe current program level as the current state, after which the process proceeds to step 955 as described above. If it is determined at 964 that there are not more program levels to be listed, the process proceeds to "C" (to Fig. 33).
  • condition listings list a control program by state and show what conditions cause a transition to the corresponding state.
  • Fig. 36 shows a block diagram at 970 of an exemplary flow chart listing of a first program level of a control program created via the programming system ofthe present invention.
  • the flow chart listing includes a plurality of state boxes 974 each having a name and address of a state ofthe control program, and a plurality of condition boxes 975 each having a name and address of a condition ofthe control program.
  • Each of a plurality of state and condition blocks 976 includes: a state box 974 having a particular state indicated therein; and at least one condition box 975, corresponding with the state box, and having rendered therein a condition for transition from the particular state.
  • the state and condition blocks 976 are disposed alternately in opposite columns consisting of a left column and a right column. Within a single column, adjacent state and condition blocks 976 are separated by a predetermined vertical displacement 977.
  • Each state box 974 has a state box anchor point 979, and each condition box 975 has a condition box anchor point 980.
  • a straight line connector 981 is rendered from the condition box anchor point 980 ofthe particular condition to the state box anchor point 979 of the destination state.
  • a side-to-same-side line 982 is rendered from the condition box anchor point 980 ofthe particular condition to the state box anchor point 979 ofthe destination state.
  • the depicted flow chart listing 970 includes a page break 983 which divides the third and fourth state and condition blocks 976, corresponding with states 1 :3 and 1 :4, from the fifth and sixth state and condition blocks 976. corresponding with states 1 :5 and 1 :6 ofthe first program level ofthe control program.
  • a page break 983 which divides the third and fourth state and condition blocks 976, corresponding with states 1 :3 and 1 :4, from the fifth and sixth state and condition blocks 976. corresponding with states 1 :5 and 1 :6 ofthe first program level ofthe control program.
  • an indication 984 including an arrow and the corresponding destination state address, are rendered inside the condition box 975.
  • condition 1 :3:3 indicates a direct transition to state 1 :6, which is in the same program level but on a different page, and therefore the condition box 975 for condition 1 :3:3 includes an indication 984 including an arrow and the state address 1 :6 ofthe destination state address. If the condition 1 :3:3 and the destination state 1 :6 were disposed on the same page, then the flow chart listing 970 would include a line rendered from the condition box anchor point to the destination state box anchor point as indicated by the dashed line.
  • condition box 975 For a particular condition indicating a direct (or goto) transition to a destination state within a program level different from the program level ofthe source state corresponding to the particular condition, an indication 985, including an arrow and the corresponding destination state address, are rendered inside the condition box 975.
  • condition 1 :6:3 indicates a direct transition to state 2:1, which is in program level 2. and therefore the condition box 975 for condition 1 :6:3 includes an indication 985 including an arrow and the state address 2:1 ofthe destination state address.
  • a first call indication 986 including an arrow and the corresponding destination state address is rendered inside the condition box 975
  • a second call indication 987 including an arrow and the corresponding return state address is rendered outside the condition box 975.
  • Fig. 37 shows an exemplary flow chart listing at 988 of a second task program level of a control program generated in accordance with the programming process ofthe present invention wherein the control program is partially coded in that destination states for particular conditions have not yet been specified by the user.
  • no destination state is specified for condition 2:2:2. and the programming system renders a "?” within the corresponding condition box at 989 to indicate that no destination state has been specified.
  • Fig. 38 shows a flow chart listing at 990 of a sub-routine program level of a control program generated in accordance with the programming process ofthe present invention.
  • each sub-routine program level includes at least one "return condition” indicating that the sub-routine program level is to return to the return state ofthe calling program level.
  • the condition box indicating condition 3:2:2 has "RETURN" rendered therein at 992 to indicate that when condition 3:2:2 is satisfied, the subroutine program level is to return to the return state ofthe calling program level.
  • condition 1 :5:2 specifies a call transition to state 3:1 of subroutine program level 3, and a return to state 1:1 ofthe calling program level 1 when the subroutine program level 3 (Fig. 38) returns, that is upon satisfaction of condition 3:2:2.
  • Fig. 39 shows a flow diagram at 1000 illustrating a process of generating arrays of position information for use in generating a flow chart listing in accordance with the programming process ofthe present invention.
  • the depicted process proceeds from "T" (from Fig. 33), and proceeds to step 1002 in which the programming system displays a list of all previously defined program levels of a control program.
  • step 1004 the programming system: provides a user interface allowing the user to select from the program levels displayed in step 1002; and receives a user selected program level having a program level number, N.
  • step 1006 the programming system: sets a first vertical position value, YI, representing the vertical coordinate position in a first column ofthe flow chart listing, to zero; and also sets a second vertical position value, Y2, representing the vertical coordinate position in a second column of the flow chart listing, to zero.
  • the first and second vertical coordinate position values are independent of each other, and each ofthe values spans multiple pages of a flow chart listing. Dividing either ofthe vertical coordinate position values by the number of vertical coordinates in a page yields a page number corresponding to the vertical coordinate position value. A vertical coordinate position value of zero corresponds to the top of a first page.
  • step 1008 the programming system sets the current state to state N:l, which is the first state ofthe user selected program level received in step 1004 as explained above.
  • the depicted process proceeds from step 1008 to 1010 at which the programming system reads the source file ofthe internal files 132 (Fig. 3 A) to determine whether the program level number ofthe current state is equal to the program level number of a previous state. This step is implemented in order to ensure that a page is skipped for a transition from one program level to another, as further explained below. If it is determined at 1010 that the program level number ofthe current state is not equal to the program level number ofthe previous state, the process proceeds to "T2" (to Fig. 41) to implement a process of advancing to the top of a next page before rendering the current condition.
  • step 1010 the process proceeds to step 1012 in which the programming system reads the source file ofthe internal files 132 (Fig. 3 A) to determine the number of conditions defined for the current state.
  • step 1014 the programming system selects YI or Y2 as the current vertical position value. For example, the programming system may select YI to represent the left column ofthe flow chart listing, and Y2 to represent the right column ofthe flow chart listing. The depicted process is executed repetitively and the programming system selects YI and Y2 as the current vertical coordinate position value for alternate cycles of the process.
  • step 1016 the programming system determines the vertical height ofthe current state/condition group by multiplying the element height, that is the height ofthe state boxes and condition boxes, by the number of conditions defined for the current state, plus one for the current state.
  • step 1018 the programming system adds the current vertical height to the current Y position value to determine an advanced Y position value.
  • step 1020 the programming system divides the current Y position value by a page length and rounds up to the next integer to determine a current page number.
  • step 1022 the programming system divides the advanced Y position value by the page length and rounds up to the next integer to determine an advanced page number.
  • the depicted process proceeds from step 1022 to 1023 at which the programming system determines whether the current page number is equal to the advanced page number, and if so the process proceeds to "TI" (to Fig. 40). If it is determined at 1023 that the current page number is not equal to the advanced page number, the depicted process proceeds to "T2" (to Fig. 41).
  • Fig. 40 shows a flow diagram at 1030 illustrating a sub-process of generating array position information for a state/condition group to be rendered on a current page.
  • the depicted process proceeds from "TI" (from Fig. 39) and proceeds to step 1032 in which the programming system determines an (X,Y) coordinate for the current state using the cunent Y position value.
  • step 1034 the programming system adds the state address and (X,Y) coordinate ofthe cunent state to a state anchor point anay stored in memory ofthe programming system 80 (Fig. 1).
  • step 1036 the programming system determines, for each ofthe conditions ofthe cunent state, the conesponding (X,Y) coordinates based on the (X,Y) coordinates for the cunent state.
  • step 1038 the programming system, for each ofthe conditions ofthe cunent state, adds the condition address and associated (X,Y) coordinate to a condition anchor point anay stored in memory of the programming system 80 (Fig. 1).
  • the state anchor point anay and condition anchor point anay are used during rendering ofthe flow chart listings (Figs. 36, 37, and 38).
  • the depicted process proceeds to 1040 at which the programming system determines whether there are more states previously defined for the cunent program level. If it is determined at 1040 that there are more states previously defined for the cunent program level, the process proceeds to step 1042 in which the programming system reads the source file to fetch the next state as the cunent state, after which the depicted process proceeds to "T3" (to Fig. 39) to repeat the process of generating anays of position information for use in generating a flow chart listing.
  • the depicted process proceeds to 1044 at which the programming system determines whether there are more program levels for which a flow chart is to be listed, and if so, the process proceeds to step 1046 in which the programming system reads the source file to fetch the next program level as the cunent program level. From step 1046 the process proceeds to step 1048 in which the programming system fetches the first state ofthe cunent program level as the cunent state, after which the process proceeds to "T3" (to Fig. 39). If it is determined at 1044 that there are not more program levels to be listed, the process proceeds to "T4" (to Fig. 42).
  • Fig. 41 shows a flow diagram at 1050 illustrating a process for generating anchor point anay position information for a state/condition group to be rendered on a next page.
  • the depicted process proceeds from "T2" (from Fig. 39), and proceeds to step 1052 in which the programming system sets in (X,Y) coordinate for the cunent state to be equal to the (X, Y) coordinate at the top ofthe next page.
  • step 1054 the programming system adds the state address ofthe cunent state and the associated (X, Y) coordinate ofthe cunent state to the state anchor point anay.
  • step 1056 the programming system adds the state address ofthe cunent state and the associated (X, Y) coordinate ofthe cunent state to the state anchor point anay.
  • the programming system determines, for each ofthe conditions ofthe cunent state, a conesponding (X, Y) coordinate based on the (X, Y) coordinate for the cunent state.
  • the programming system for each ofthe conditions ofthe cunent state, adds the condition address and associated (X, Y) coordinate to the condition anchor point array.
  • the process proceeds from 1058 to 1060 at which the programming system determines whether more states have been previously defined for the cunent program level. If it is determined at 1060 that more states have been previously defined for the cunent program level, the process proceeds to step 1062 in which the programming system reads the source file to fetch the next state as the cunent state, after which the process proceeds to "T3" (to Fig. 39).
  • step 1062 the programming system reads the source files to determine whether there are more program levels to be listed. If it is determined at 1060 that there are more program levels to be listed, the process proceeds to step 1066 in which the programming system reads the source file to fetch the next program level as the cunent program level. From step 1066, the process proceeds to step 1068 in which the programming system fetches the first state ofthe cunent program level as the cunent state, after which the process proceeds to "T3" (to Fig. 39).
  • Fig. 42 shows a flow diagram at 1070 illustrating a second pass process for generating a flow chart listing in accordance with the present invention.
  • the depicted process proceeds from "T4" (from Figs. 40 and 41), and proceeds to step 1080 in which the programming system reads the name and address ofthe cunent state ofthe cunent program level from the source file.
  • step 1082 the programming system reads the (X, Y) coordinate ofthe cunent state ofthe cunent program level from the state anchor point anay.
  • step 1084 the programming system renders the name and address ofthe cunent state in the state box associated with the (X, Y) coordinate ofthe cunent state.
  • step 1086 the programming system reads the name and address ofthe current condition ofthe cunent state from the source file.
  • step 1088 the programming system reads the (X, Y) coordinate ofthe cunent condition ofthe cunent state from the condition anchor point anay.
  • step 1090 the programming system renders the name and address ofthe cunent condition in the condition box associated with the (X, Y) coordinate. From step 1090, the process proceeds to step 1092 at which the programming system reads the source file to determine whether there are more conditions previously defined for the cunent state, and if so, the process proceeds to step 1094 in which the programming process reads the source file to fetch the next condition as the cunent condition.
  • the process proceeds to 1094 at which the programming system reads the source file to determine whether there are more state defined for the cunent program level. If it is determined at 1096 that there are more states defined for the cunent program level, the process proceeds to step 1098 in which the programming system reads the source file to fetch the next state as the cunent state. If it is determined at 1096 that there are not more states defined for the cunent program level, the process proceeds to 1100 at which the programming system reads the source file to determine whether there are more program levels to be listed, and if so, the process proceeds to step 1102 in which the programming system reads the source file to fetch the next program level as the cunent program level.
  • step 1102 the depicted process proceeds to step 1104 in which the programming system reads the source file to fetch the next state as the cunent state, after which the process proceeds back to step 1080 as described above. If it is determined at 1100 that there are not more program levels to be listed, the process proceeds to "T5" (to Fig. 43).
  • Fig. 43 shows a flow diagram at 1110 illustrating a process for illustrating transitions from a source state to a destination state based on conesponding conditions.
  • the depicted process proceeds from "T5" (from Fig. 42), and proceeds to step 1 112 in which the programming system reads the source file to determine whether the present condition indicates a direct (GOTO) transition or a call transition.
  • the process proceeds from step 1112 to 1114 at which the programming system determines whether the present condition indicates a direct (GOTO) transition. If it is determined at 1114 that the present condition does not indicate a direct transition, but rather indicates a call type transition, the process proceeds to "T6" (to Fig. 44).
  • the process proceeds to 1 116 at which the programming system determines whether the destination state box ofthe destination state indicated by the present condition, is on the present page. If it is determined that the destination state box is on the present page, the process proceeds from 1116 to step 1118 in which the programming system renders an arrow outside the cunent condition box pointing away from the present condition box, after which the process proceeds to "T7" (to Fig. 45).
  • step 1116 the programming system renders, inside the present condition box, an anow and the address ofthe destination state to which the control program is to proceed if the present condition is true. From step 1120, the depicted process proceeds to "TI" (to Fig. 40).
  • Fig. 44 shows a flow diagram at 1130 illustrating a sub-process for indicating a call transition.
  • the depicted process proceeds from "T6" (from Fig. 43) and proceeds to step 1132 in which the programming system renders, inside the present condition box, an anow and address ofthe destination state of a sub-routine program level to which the control program is to proceed if the present condition is true.
  • step 1132 the programming system renders, outside the present condition box, an anow and the address ofthe return state to which the control program is to proceed after the sub-routine returns.
  • the process proceeds to "T5" (to Fig. 43).
  • Fig. 45 shows a flow diagram at 1150 illustrating a process of rendering lines indicating transition from a source state to a destination state as a result of condition criteria being satisfied.
  • the depicted process proceeds from "T7" (from Fig. 43), and proceeds to 1152 at which the programming system determines whether the destination state box ofthe destination state is positioned in the column opposite the cunent condition box ofthe cunent condition. If is determined at 1152 that the destination state box and the current condition box are in opposite columns, the process proceeds to step 1154 in which the programming system renders a line extending from the anchor point ofthe cunent condition box to the anchor point ofthe destination state box.
  • step 1152 the process proceeds to step 1154 in which the programming system renders a first horizontal line extending a cunent horizontal displacement distance X from the anchor point ofthe cunent condition box to a cunent horizontal distal point. From step 1154, the process proceeds to step 1156 in which the programming system renders a vertical line extending from the cunent horizontal distal point to a cunent vertical distal point having a Y coordinate value equal to that ofthe anchor point of the destination state box.
  • step 1156 the process proceeds to step 1158 in which the programming system renders a second horizontal line extending from the cunent distal point to the anchor point ofthe destination state box. From step 1 158, the process proceeds to step 1160 in which the programming system increases the horizontal displacement distance X by a predetermined amount. From step 1 160, the process proceeds to "T5" (to Fig. 43).
  • Fig. 46 shows a block diagram of exemplary cross reference listings at 1200, 1202. and 1204 for a digital output variable, a digital input variable, and a timer variable, respectively.
  • the depicted cross reference listings are generated by the programming system ofthe present invention by reading from the source files ofthe internal files 132 (Fig. 3 A).
  • the cross reference listing at 1200 includes: an entry 1205 indicating a digital output variable name; an entry 1206 indicating a function performed using the digital output variable upon transition to a conesponding state; an entry 1207 indicating the name ofthe conesponding state; an entry 1208 indicating the address ofthe conesponding state; and an entry 1209 indicating the access right value of the digital output variable while the control program operates in the conesponding state.
  • the functions using the digital output variable which may be indicated by entry 1206 include “SET ON”, “SET OFF”, “ON IN AND”, “OFF IN AND”, “ON IN OR”, “OFF IN OR”, “BLINK SLOW IN OR”, “BLINK FAST IN OR”, “BLINK SLOW IN AND”, “BLINK FAST IN AND”, “ASSIGN”, “TAG ONLY”, “BLINK SLOW”, and “BLINK FAST”.
  • Cross reference listings similar to the one at 1200 are generated for digital variables and front panel LED variables which may be used in the same type of functions.
  • Cross reference listings for analog output variables (not shown) and cross reference listings for program variables (not shown) indicate functions which may be performed using the analog output variables and program variables upon transition to a conesponding state.
  • the cross reference listing at 1202 includes: an entry 1211 indicating a digital input variable name; an entry 1211 indicating a condition statement in which the digital input variable is used; an entry 1212 indicating the name ofthe conesponding program level, state, and condition in which the condition statement is used; and an entry 1213 indicating the address of the conesponding condition.
  • Condition statements which may be indicated by entry 1211 include “ON IN AND”, “OFF IN AND”, “ON IN OR”, “OFF IN OR”, “BLINK SLOW IN OR”, “BLINK FAST IN OR”, “BLINK SLOW IN AND”, and “BLINK FAST IN AND”.
  • Cross reference listings similar to the one at 1202, are generated for front panel switch variables which may be used in the same types of condition statements.
  • Cross reference listings for analog input variables indicate condition statements in which the analog input variable is used, the condition statements including "TEST >", “TEST ⁇ ”, “TEST BETWEEN”, “TEST NOT >”, “TEST NOT BETWEEN”, “REFERENCE”, and “TEST NOT ⁇ ".
  • the cross reference listing at 1204 includes: an entry 1214 indicating a timer variable name; an entry 1215 indicating a function performed with regard to the timer variable upon transition to a conesponding state in which the timer variable is used; an entry 1216 indicating the names ofthe conesponding program level and state for which the formulas is defined; an entry 1217 indicating the address ofthe conesponding state; and an entry 1218 indicating the expression ofthe formula itself.
  • Functions which may be indicated by entry 1215 include "SET VALUE”, "ASSIGN”. "SET TAG ONLY”, “SET RUN ON”, “SET RUN OFF”, “FORMULA”, and "TEST".
  • Fig. 47 shows a flow diagram at 1220 depicting a process for generating a cross- reference listing.
  • the depicted process proceeds from "U" (from Fig. 33) and proceeds to step 1222 in which the programming system displays a list of variable types including analog input, analog output, digital input, digital output, program variable, digital variable, panel LED variable, panel switch variable, and timer variable.
  • step 1224 the system provides a user interface allowing the user to choose from the options of: selecting one ofthe variable types for cross-reference listing; or selecting "interprogram level " cross-reference listing; and receives a conesponding user input.
  • Fig. 48 shows a flow diagram at 1230 depicting a sub-process ofthe process 1220 (Fig.
  • step 1232 the system searches the source file ofthe internal file 132 (Fig. 3 A) for a condition that specifies a direct or sub-routine transition to a destination state in a program level other than the conesponding source program level.
  • step 1234 the system determines whether a condition as described in step 1232 has been found. If it is determined at 1234 that such a condition has been found, the process proceeds to step 1236 in which the system reads the condition as the cunent condition from the source file.
  • step 1238 the system renders in a column labeled "FROM", the name and address ofthe cunent condition.
  • step 1240 the system renders in a column labeled "TO”, the name and address ofthe conesponding destination state, after which the process proceeds back to step 1232 to search for the next condition. If it is determined at 1234 that a condition specifying a transition to a destination state in another program level has not been found, the process proceeds to "C" (to Fig. 33).
  • Fig. 49 shows a flow diagram at 1250 illustrating a sub-process ofthe process 1220 (Fig. 47) for generating cross-reference listings, the depicted sub-process for generating cross- reference listings for variables.
  • the depicted process proceeds from "U2" (from Fig. 47) and proceeds to step 1252 in which the system renders the name of a cunent variable.
  • step 1254 the system searches the source file for a next condition including a condition statement using the cunent variable. It is then determined at 1256 whether a condition including a condition statement using the cunent variable has been found, and if so, the process proceeds to step 1258 in which the system renders the cunent condition statement.
  • step 1258 the process proceeds to step 1260 in which the system renders the name and address ofthe cunent condition, after which the process proceeds back to step 1254. If it is determined at 1256 that a condition, including a condition statement using the cunent variable has not been found, the process proceeds to step 1262, in which the system searches the source file for a next state assigning a value for the cunent variable. It is then determined at 1264 whether a next state assigning a value for the cunent variable has been found. If it is determined at 1264 that such a state has been found, the process proceeds to step 1266 in which the system renders a value assigned to the cunent variable by the cunent state.
  • step 1268 the system renders the name and address ofthe cunent state.
  • step 1270 the system renders the access right value for the cunent variable as the controlled program operates in the cunent state, after which the process proceeds back to step 1262.
  • the depicted process repeats steps 1262, 1264, 1266, 1268, and 1270 until it is determined at 1264 that a state assigning a value for the cunent has not been found, after which the process proceeds to "U3" (to Fig. 50).
  • Fig. 50 shows a flow diagram at 1280 depicting a sub-process ofthe cross-reference listing process 220 (Fig. 47).
  • the depicted process proceeds from "U3" (from Fig. 49) and proceeds to step 1282 in which the system searches the source file for a next formula using the cunent variable. It is then determined at 1284 whether a formula using the cunent variable has been found, and if so, the process proceeds to step 1286 in which the system renders the name and address ofthe state for which the cunent formula is defined. From step 1286, the process proceeds to step 1288 in which the system renders the cunent formula, after which the process proceeds back to step 1282.
  • step 1284 determines whether there are more variables ofthe type selected in step 1224 (Fig. 47). If it is determined at 1290 that there are more variables to be listed, the process proceeds to step 1292 in which the system fetches the next variable as the cunent variable, after which the process proceeds back to "U3" (to Fig. 49) to repeat processes 1250 and 1280 (Fig. 49 and 50). If it is determined at 1290 that there are not more variables to be listed, the process proceeds to "U" (to Fig. 1220).

Landscapes

  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Engineering & Computer Science (AREA)
  • Automation & Control Theory (AREA)
  • Programmable Controllers (AREA)

Abstract

L'invention concerne un procédé (10) pour générer un programme de commande destiné à être exécuté par une commande logique (12). Le procédé consiste à mettre en oeuvre une interface utilisateur de modification de variables (65) permettant à un utilisateur de définir et modifier des variables associées à des signaux de sortie correspondants; à mettre en oeuvre une interface utilisateur de modification d'états (65) permettant à un utilisateur de définir et modifier une pluralité d'états du programme de commande; à mettre en oeuvre une interface utilisateur de modification de conditions (65) permettant à un utilisateur de définir et modifier au moins une condition pour chacun des états du programme de commande; et à générer un programme de commande en fonction de relations associatives des variables, des états et des conditions.
PCT/US1999/024073 1998-10-13 1999-10-13 Systeme et procede de generation d'un programme de commande WO2000022486A1 (fr)

Priority Applications (4)

Application Number Priority Date Filing Date Title
CA002347491A CA2347491A1 (fr) 1998-10-13 1999-10-13 Systeme et procede de generation d'un programme de commande
JP2000576325A JP2002527803A (ja) 1998-10-13 1999-10-13 制御プログラムを生成するためのシステムおよび方法
AU11154/00A AU1115400A (en) 1998-10-13 1999-10-13 System and method for generating a control program
EP99954929A EP1135715A4 (fr) 1998-10-13 1999-10-13 Systeme et procede de generation d'un programme de commande

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
US09/172,473 US6167319A (en) 1998-10-13 1998-10-13 Process for generating program listings for programming a logic control unit
US09/189,027 US6505341B1 (en) 1998-11-10 1998-11-10 System and method for programming a logic control unit
US09/189,027 1998-11-10
US09/172,473 1998-11-10

Publications (1)

Publication Number Publication Date
WO2000022486A1 true WO2000022486A1 (fr) 2000-04-20

Family

ID=26868126

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US1999/024073 WO2000022486A1 (fr) 1998-10-13 1999-10-13 Systeme et procede de generation d'un programme de commande

Country Status (5)

Country Link
EP (1) EP1135715A4 (fr)
JP (1) JP2002527803A (fr)
AU (1) AU1115400A (fr)
CA (1) CA2347491A1 (fr)
WO (1) WO2000022486A1 (fr)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1445674A2 (fr) * 2002-09-30 2004-08-11 Husco International, Inc. Système d'exploitation pour un automate programmable d'un système hydraulique
CN102870053A (zh) * 2011-03-15 2013-01-09 欧姆龙株式会社 可编程控制器的cpu单元、可编程控制器用的系统程序以及存储了可编程控制器用的系统程序的记录介质

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR102414933B1 (ko) * 2020-04-27 2022-07-04 주식회사 유디엠텍 Plc 프로그램 정보를 이용한 플로우차트 생성방법

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5497315A (en) * 1993-02-26 1996-03-05 Toyoda Koki Kabushiki Kaisha Programming device for programmable sequence controllers
US5818711A (en) * 1996-09-30 1998-10-06 Allen Bradley Company, Llc Method for visually determining the status of program edits in an on-line programming environment
US5841657A (en) * 1991-03-30 1998-11-24 Mazda Motor Corporation System designing method of a production line

Family Cites Families (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4445169A (en) * 1980-06-13 1984-04-24 The Tokyo Electric Co., Inc. Sequence display apparatus and method
FR2549983B1 (fr) * 1983-07-25 1988-03-18 Telemecanique Electrique Terminal pour l'elaboration de programmes utilisables par un automate programmable
US5168441A (en) * 1990-05-30 1992-12-01 Allen-Bradley Company, Inc. Methods for set up and programming of machine and process controllers
EP0553731B1 (fr) * 1992-01-23 1999-04-14 Mitsubishi Denki Kabushiki Kaisha Automate programmable
JPH0938876A (ja) * 1995-08-01 1997-02-10 Ricoh Co Ltd シミュレーション装置
JP3679844B2 (ja) * 1995-11-09 2005-08-03 ファナック株式会社 シーケンス・プログラムの実行装置

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5841657A (en) * 1991-03-30 1998-11-24 Mazda Motor Corporation System designing method of a production line
US5497315A (en) * 1993-02-26 1996-03-05 Toyoda Koki Kabushiki Kaisha Programming device for programmable sequence controllers
US5818711A (en) * 1996-09-30 1998-10-06 Allen Bradley Company, Llc Method for visually determining the status of program edits in an on-line programming environment

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See also references of EP1135715A4 *

Cited By (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1445674A2 (fr) * 2002-09-30 2004-08-11 Husco International, Inc. Système d'exploitation pour un automate programmable d'un système hydraulique
EP1445674A3 (fr) * 2002-09-30 2004-12-15 Husco International, Inc. Système d'exploitation pour un automate programmable d'un système hydraulique
CN102870053A (zh) * 2011-03-15 2013-01-09 欧姆龙株式会社 可编程控制器的cpu单元、可编程控制器用的系统程序以及存储了可编程控制器用的系统程序的记录介质
EP2595020A1 (fr) * 2011-03-15 2013-05-22 OMRON Corporation, a corporation of Japan Cpu de plc, programme de système pour plc et support d'enregistrement stockant un programme de système pour plc
EP2595020A4 (fr) * 2011-03-15 2014-05-14 Omron Tateisi Electronics Co Cpu de plc, programme de système pour plc et support d'enregistrement stockant un programme de système pour plc

Also Published As

Publication number Publication date
CA2347491A1 (fr) 2000-04-20
EP1135715A4 (fr) 2002-01-16
EP1135715A1 (fr) 2001-09-26
JP2002527803A (ja) 2002-08-27
AU1115400A (en) 2000-05-01

Similar Documents

Publication Publication Date Title
US6505341B1 (en) System and method for programming a logic control unit
US6167319A (en) Process for generating program listings for programming a logic control unit
JP6186464B2 (ja) プロセス制御システムの環境設定及び管理を行う動的ユーザインターフェイス
EP0643848B1 (fr) Commande de pulverisateurs de peinture et analogue
US9256219B2 (en) System configuration using templates
JP4934482B2 (ja) プロセス制御のための環境の構成を補助するためのシステム
US6690981B1 (en) System and method for encapsulating user interface code for a graphical program
US6829733B2 (en) System and method for graphically detecting differences between test executive sequence files
US5295059A (en) Programmable controller with ladder diagram macro instructions
CN111007809B (zh) 在过程工厂内的现场设备的批量调试
US3979725A (en) Multi-way program branching circuits
WO1997040425A2 (fr) Application de langage de commande idiomatique
CN108345264B (zh) 可编程控制器
EP1135715A1 (fr) Systeme et procede de generation d'un programme de commande
US5721926A (en) Correspondence-oriented state-transition-model-based programming systems
CN111052010A (zh) 控制系统、开发辅助装置和开发辅助程序
JP2006243841A (ja) Ｐｌｃ用ツール装置
Gertler et al. Software for process control—A survey
JP4964036B2 (ja) エディタ装置およびエディタプログラム
CN113687832B (zh) 机器人程序的存储及编译方法
KR100423742B1 (ko) 순차기능챠트에 의한 전용 제어 시스템
KR20210049302A (ko) 모션 제어기의 오류 추적방법
CN117950650A (zh) 一种Unity3D组件与逻辑控制器交互可视化配置的方法
JPH10171641A (ja) ソフトウェア設計・試験支援装置
US20050080585A1 (en) Method for the operation of an electronic device

Legal Events

Date Code Title Description
ENP Entry into the national phase

Ref country code: AU

Ref document number: 2000 11154

Kind code of ref document: A

Format of ref document f/p: F

AK Designated states

Kind code of ref document: A1

Designated state(s): AE AL AM AT AU AZ BA BB BG BR BY CA CH CN CR CU CZ DE DK DM EE ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MD MG MK MN MW MX NO NZ PL PT RO RU SD SE SG SI SK SL TJ TM TR TT UA UG US UZ VN YU ZA ZW

AL Designated countries for regional patents

Kind code of ref document: A1

Designated state(s): GH GM KE LS MW SD SL SZ TZ UG ZW AM AZ BY KG KZ MD RU TJ TM AT BE CH CY DE DK ES FI FR GB GR IE IT LU MC NL PT SE BF BJ CF CG CI CM GA GN GW ML MR NE SN TD TG

DFPE Request for preliminary examination filed prior to expiration of 19th month from priority date (pct application filed before 20040101)
121 Ep: the epo has been informed by wipo that ep was designated in this application
ENP Entry into the national phase

Ref document number: 2347491

Country of ref document: CA

Ref country code: CA

Ref document number: 2347491

Kind code of ref document: A

Format of ref document f/p: F

ENP Entry into the national phase

Ref country code: JP

Ref document number: 2000 576325

Kind code of ref document: A

Format of ref document f/p: F

WWE Wipo information: entry into national phase

Ref document number: 1999954929

Country of ref document: EP

REG Reference to national code

Ref country code: DE

Ref legal event code: 8642

WWP Wipo information: published in national office

Ref document number: 1999954929

Country of ref document: EP

WWW Wipo information: withdrawn in national office

Ref document number: 1999954929

Country of ref document: EP