Flowchart exception handling element

Details Flowchart exception handling element Flowchart exception handling element

1998-05-14

2001-05-01

Cuchlinski, Jr., William A. (Department: 3661)

Data processing: generic control systems or specific application

Generic control system, apparatus or process

Sequential or selective

C700S017000, C700S018000, C700S083000, C700S086000, C700S186000, C068S012010, C068S012050, C068S012210, C318S434000, C318S473000, C318S806000, C710S014000

Reexamination Certificate

active

06226555

ABSTRACT:

FIELD OF THE INVENTION
The present invention relates generally to the control of industrial equipment and processes using graphical flow charts that indicate logic flow concurrently with the execution of the underlying control program. More particularly, the invention is directed to a system for handling exception conditions in a flowchart based program.
BACKGROUND OF THE INVENTION
The vast majority of industrial processes, by definition, consist of a series of sequential or concurrent steps, each step involving one or more actions to be taken by a machine or machines. The steps may occur at specific times and in a specified sequence according to specific parameters, or may occur in response to specific events. Each step may have one or more elements, each element describing activities or operations with greater specificity.
In the past, industrial equipment was commonly controlled directly by interfacing the equipment with a programmable logic controller, or “LC”. A PLC is a solid-state device designed to perform logic functions previously accomplished by electromechanical relays. The PLC uses output modules to actuate the industrial equipment in response to physical stimuli which the PLC is programmed by the operator of the system to recognize through input modules. PLCs, which still find wide use today, are usually programmed using either ladder logic or sequential function charts. Because of the cryptic nature of ladder logic, it is inherently complex and difficult and time consuming to debug and maintain.
More recently, manufacturers have sought to take advantage of the greater flexibility of general-purpose computers, including inexpensive commercially available personal computers, or “PCs”, to enhance the efficiency associated with creating and maintaining software programs used to control industrial processes. Because general purpose computers can be programmed in high level commercially available languages such as BASIC, FORTRAN, C, or in object-oriented languages such as C++, manufacturers and process control vendors have been able to develop PC-based control systems that emulate traditional PLC functions, but do it in such a way that permits them to be easy to use, program and maintain, while still offering significant cost savings over dedicated PLC-based solutions.
In many instances when a PLC is used, the PLC is connected to a central control computer. In such an arrangement, the PLC plays its own dedicated role controlling the industrial process at hand while concurrently communicating information back to the central computer. By using the high level commercially available programming languages, control methods have evolved using graphical flow charts to aid the software programmer developing control programs which can emulate traditional PLC functions. Use of PCs in this way enable a manufacturer to develop and run the operator interface on the same PC and share data with other Windows™ based programs or programs based on other operating systems through dynamic data exchange. Thus, a single PC may perform the function of the programmable logic controller, the operator panel, the programming terminal, and the real time system simulator. A PC therefore can replace three separate components: PLC programming terminal, PLC processor, and operator interface. By implementing a PC-based control system, manufacturers are able to lower control system investment costs, increase productivity in design and industrial operations, and reduce down time with built in flow chart based diagnostics.
Manufacturing control systems must not only control a manufacturing process, but also handle anomalies in the process, called “exceptions”. An exception occurs when an event occurs that is outside of the normal operation of the machine being controlled. For purposes of illustration, the prior art and the present invention will be described as being applied to a clamping and drilling operation. Those of skill in the art, however, will understand that manufacturing control systems can be used in many diverse applications.
FIG. 3
is an example of a state machine with one exception condition. The process shown in
FIG. 3
has four states
100
,
110
,
120
and
130
, each state having one corresponding exit condition, or exception,
105
,
115
,
125
,
135
where all of the conditions result in the same action
140
(an E-stop, in this example). As shown in
FIG. 3
, during normal operation, a piece to be worked is first clamped into place and then drilled. After drilling takes place, the piece is unclamped and after indexing the process cycle begins again with the next piece. If an error occurs at any step in the process, such as a jam in the machine being controlled, a separate sequence of operations is usually carried out to correct the error. Once the exception is fixed, the process cycle can be restarted. As can be seen in
FIG. 3
, even with a simple manufacturing process having only one exception exit per step and only one resulting action, a flowchart programmer has to individually program each of these conditions and connect the exception exit condition for each step to the same E-stop action. This type of programming can be quite burdensome. As the number of possible exception types and actions increase for each manufacturing step, the complexity of the program can increase exponentially, making the logic redundant and tedious to program.
The complexity of the program is mainly caused by the fact that each state must have at least one and possibly many exits to another state to address events that are out of the ordinary. At this point, the machine goes to a state where it handles the exception to normal operations. In other words, the normal program would cycle a particular group of steps repeatedly and if something wrong happens, then the program would go to an exception handling state which includes exiting the normal state mode. The condition causing the exception would then be repaired, allowing the program to return to the normal state process flow.
A decision diamond must be implemented at any point where special action is desired after an exception is detected. The exception handling becomes even more complicated if the decision takes place in a sub-routine. This is because the sub-routine may itself include parallel branches, causing multiple program threads to be executing when a particular exception occurs. The exception handling code will then have to eventually pull the multiple threads back to one common step, generating a great amount of extra work if the normal operation has branched into many different threads.
It is therefore an object of the invention to minimize program redundancy arising from individually programming multiple exception exit conditions for each state in a manufacturing control process.
It is yet another object of the invention to allow the exception handler to function regardless of the number of sub-program levels that have been called or the number of parallel threads being processed when an exception is detected.
SUMMARY OF THE INVENTION
The present invention is directed to an exception handler in a flowchart programmed software logic controller. In the invention, exception handling elements, such as a “Begin Exception” and “End Exception” element, are paired together, and corresponding elements have matching labels. Each error condition has exactly one Begin Exception element and zero or more associated End Exception elements. In a preferred embodiment, the Begin Exception elements will have an associated Boolean expression that is evaluated during every scan cycle of the logical controller. If the expression indicates that an exception condition exists, all program threads initiated after the Begin Exception element are terminated, including any threads created via parallel branches and regardless of any nested subroutines. The controller then may begin execution of an exception program that is connected to the Begin Exception element. Note that any element that occurs after defining an error condition using the exception e

Affiliated with

Also associated with

Rating

Flowchart exception handling element does not yet have a rating. At this time, there are no reviews or comments for this patent.

If you have personal experience with Flowchart exception handling element, we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Flowchart exception handling element will most certainly appreciate the feedback.

Rate now

Comments { 0 }

Profile ID: LFUS-PAI-O-2435748