Template language for industrial controller programming

Data processing: generic control systems or specific application – Generic control system – apparatus or process – Sequential or selective

Reexamination Certificate

Rate now

  [ 0.00 ] – not rated yet Voters 0   Comments 0

Details

C700S007000, C700S012000, C700S169000, C700S083000, C700S086000, C700S087000, C706S050000, C706S060000, C717S100000, C717S125000, C717S146000, C717S132000, C709S241000, C709S241000, C709S241000

Reexamination Certificate

active

06553268

ABSTRACT:

STATEMENT REGARDING FEDERALLY SPONSORED RESEARCH
Not applicable.
BACKGROUND OF THE INVENTION
This invention relates to electronic programmable controllers for operating industrial equipment, and more particularly, to a programming language used to develop control programs performed by industrial controllers to control industrial equipment.
Programmable controllers are well-known systems for operating industrial equipment, such as assembly lines and machine tools, in accordance with a stored program. In these controllers, a stored program is executed to examine the condition of specific sensing devices on the controlled equipment, and to energize or de-energize selected operating devices on that equipment contingent upon the status of one or more of the examined sensing devices. The program not only manipulates single-bit input and output data representing the state of the sensing and operating devices, but also performs arithmetic operations, timing and counting functions, and more complex processing operations.
One industry which extensively uses programmable controllers is the automotive industry. In the automotive industry, various automotive parts are conveyed along machine lines consisting of many consecutive workstations. Most workstations include at least one tool which performs some function to alter the characteristics of work pieces as they are delivered to the station. For example, an unfinished cast engine block that requires a plurality of holes, bores, and threads, as well as other metal-removing procedures, may be provided at the beginning of a machine line that produces finished engine blocks. The machine line may consist of any number of different stations, each station performing a different procedure on the unfinished block. An indexer in the form of a transfer bar can be arranged to move each block from one station to the next following a completed process. Typically, at each station the block would be clamped prior to any metal-removing operation.
In this type of system, a programmable controller would receive inputs from all of the various tools at all of the workstations and would provide activating output signals to synchronize machine operation. During metal-removing periods with the transfer bar out of the way, all of the tools would perform their functions. In between metal-removing periods during transfer periods, the tools would be parked, the clamps unclamped, and the transfer bar would advance workpieces from one station to the next.
Industrial controllers are frequently programmed in “relay ladder” language (RLL) where instructions are represented graphically by “contacts” and “coils” of virtual relays connected and arranged in ladder-like rungs across power rails. RLL, with its input contacts and output coils, reflects the emphasis in industrial control on the processing of large amounts of input and output data.
RLL also reflects the fact that most industrial control is “real time”; that is, an ideal industrial controller behaves as if it were actually composed of multiple relays connected in parallel rungs to provide outputs in essentially instantaneous response to changing inputs. Present industrial controllers do not, in fact, employ separate parallel relay-like structures, but instead simulate the parallel operation of the relays by means of a conventional Von Neumann-type computer processor which executes instructions one at a time, sequentially. The practical appearance of parallel operation is obtained by employing extremely fast processors in the execution of the sequential control program.
As each rung is executed, inputs represented by the contacts are read from memory (as obtained from inputs from the controlled process or the previous evaluation of coils of other rungs). These inputs are evaluated according to the logic reflected in the connection of the contacts into one or more branches within the rungs. Contacts in series across a rung represent boolean AND logic whereas contacts in different branches and thus in parallel across the rung represent boolean OR logic.
Typically a single output coil at the end of each rung is set or reset and, based on the evaluation of that rung, this setting or resetting is reflected in the writing to memory of a bit (which ultimately becomes an output to the industrial process or to another RLL rung).
Once a given rung is evaluated, the next rung is evaluated and so forth, In the simplest form of RLL programming, there are no jumps, i.e. all rungs are evaluated in a cycle or “scan” through the rungs. This is in contrast to conventional computer programming, where branch and jump instructions cause later instructions or groups of instructions to be skipped, depending on the outcome of a test associated with those branch or jump instructions.
While RLL is well-suited for controlling industrial processes like those in the automotive industry, RLL programming is not an intuitive process and, therefore, requires highly-skilled programmers. Where hundreds of machine tool movements must be precisely synchronized to provide a machining process, programming in RLL is extremely time-consuming. The time and relative skill associated with RLL programming together account for an appreciable percentage of overall costs associated with a control system. In addition, the final step in RLL programming is typically a lengthy debugging and reworking step which further adds to overall system costs.
One way to streamline any type of programming is to provide predefined language modules, expressed in a language such as RLL, which can be used repetitively each time a specific function is required. Because of the similar types of tools and movements associated with different machine-line stations, industrial control would appear to be an ideal industry for such language modules.
The predefined logic module approach works quite well for certain applications, like small parts-material handling or simple machining. The reason for this is that the RLL logic required for these applications tends to be very simple. In small parts material handling applications the 1/0 count is low and the interfaces between modules are minimal. In fact, the mechanisms are often independent units, decoupled from neighboring mechanisms by part buffers such that no signals are required to be exchanged between modules. These “loosely coupled” systems lend themselves to “cut and paste” programming solutions.
But the predefined, fixed logic module approach does not work well for other applications, for example metal-removing applications. There are two main reasons for this. First, there can be considerable variation in how components, such as sensors and actuators, combine to produce even simple mechanisms. Second, processes like metal removing normally require tightly controlled interaction between many individual mechanisms. The interaction is controlled by exchanging signals, called interlocks, between the control logic modules of the individual mechanisms. The application of specific interlocks depends on knowledge of the process and the overall control strategy, information not generally needed, or knowable, when the control logic for each mechanism is defined.
For example, a drill is a typical metal-removing tool used in the automotive industry. In this example an ideal drill is mounted on a carriage that rides along a rail between two separate limiting positions on a linear axis, an advanced position and a returned position. Two limit switches, referred to herein as returned and advanced LSs, are positioned below the carriage and, when tripped, signal that the drill is in the returned and advanced positions, respectively. Two separate dogs (i.e. trigger extensions), an advanced dog and a returned dog, extend downwardly from the bottom of the carriage to trip the LSs when the advanced and returned positions are reached, respectively. In the ideal case, both LSs may be assumed to be wired in the same “normally opened” manner, so that electrically speaking they are open when released and closed when triggered. In this ideal case, where the ph

LandOfFree

Say what you really think

Search LandOfFree.com for the USA inventors and patents. Rate them and share your experience with other people.

Rating

Template language for industrial controller programming does not yet have a rating. At this time, there are no reviews or comments for this patent.

If you have personal experience with Template language for industrial controller programming, we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Template language for industrial controller programming will most certainly appreciate the feedback.

Rate now

     

Profile ID: LFUS-PAI-O-3059161

  Search
All data on this website is collected from public sources. Our data reflects the most accurate information available at the time of publication.