CA2599119A1 - Method for controlling and operating a production cell, and control device - Google Patents

Abstract

The invention relates to a method and a device for controlling a production cell for producing plastic injection-moulded parts, according to which the production cycle is defined and parameterised by the user. The invention is based on a component-oriented control system. Components can be, for example, the mould closure, the injection unit, the core puller, the handling appliances etc., which are virtually formed in the control system. According to the invention, machine cycles are designed, managed and run on the basis of behaviourally complete components, together forming a domain model, by means of a specialised domain language. In this way, an injection-moulding machine can be used and operated in a universal and simple manner. The components appear on the display screen or operating surface and are used by the user as the basis for the modelling of any cycles. Furthermore, a domain language is used for each problem area in the control system, in order to describe solutions and to automatically generate the program code therefrom.

Description

ME-THDa:F
GR COINITJZGLLNGANDiOPETUffM A ~=TfM:CE-Q, ~
CONTROL DEVICE

Technical Field The invention relates to a method for controlling and operating a production cell for producing plastic injection-moulded parts, including at least part of the peripheral devices assigned to it, wherein the production cycle is defined and parameterized by the user. Furthermore, the invention relates to a device for controlling and operating a production cell for producing plastic injection-moulded parts with an injection-moulding machine with computing and storage tools, wherein the production cycle can be defined by the user via operator controls.

State of Technology In contrast to classic machine tools, plastic injection-moulding does not involve a work piece to be processed. Instead, the work piece must be produced in a cyclic process from liquefied material inside the injection moulds. As a second distinctive characteristic, the injection-moulding machine features a large number of axes. In the centre, there is the injection mould, which, in the simplest case, consists of two mould halves that are closed for the moulding process and opened for parts extraction. In practical applications, the injection mould, which is also referred to as the injection tool or tool, can have highly complex "innards"
that have to be controlled via the machine control device.

Q~cendirg m: ffieijs~ :of ffm: Cnj_ec~~maukft m~cfi~irre, it niay feature an automated extraction gripper, for example. Other components of an injection-moulding machine are heating and cooling units, as well as a raw material supply unit. Depending on the degree of automation, raw material preparation units, as well as transfer robots, transport devices and a packing device for finished moulded parts, can be components of the production cell as well. The tool or the mould closure can feature auxiliary tools, for example to facilitate a quick tool change. Due to the large number of possible additional components and/or auxiliary tools, we call this a production cell. A
production cell often also includes two or more injection-moulding machines which can be operated in a coordinated manner via the control device. Consequently, according to this definition, a "production cell" means at least one or multiple injection-moulding machines with all peripheral tools.

According to conventional controlling concepts for injection-moulding machines, all components are coordinated by a central machine control system and locked off against each other in such a way that no major malfunctions are possible.
The central control system features all necessary computing and storage spaces, plus a knowledge base and a basic infrastructure for displaying the processes on a user terminal, and is equipped with BUS connections for communication, forwarding control commands to all existing process components and for networking with the overriding main computer, e.g. also for working together with other injection-moulding machines.

With respect to injection-moulding machines, experts increasingly recognize a rising complexity of the overall machine control process as a primary issue.
This complexity is primarily due to the fact that not only is there a variety of operating parameters and processes in the order-based production of injection-moulded parts, but that each axis and/or element features a variety of internal processes.
For example, the ejector for ejecting the finished injection-moulded parts can feature between 5 and 10 selectable processes. Due to these processes, the pactoT, :as: welLas:a irr~L--jx =of the :speed:~~ path:of the e-ejector, can be selected.

The concept of primary reliance of operation on parameters and/or process functions can be problematic in terms of technical and conceptual considerations, both regarding further development of the machine control device and operability of the machine. While the parameters, depending on their number, technically offer virtually any scalability, they are badly suited to the design of the dynamic structures that are necessary for the configuration of a production cycle. In many cases, the production cycle today has to be configured by defining parameters and locking mechanisms. Except in standard cases, this is anything but easy and often not very flexible. This - from the perspective of the customer - lack of flexibility of the control device leads to the necessity of developing customized solutions. For the operator of the control device, the parameterization of solutions based on the current state of technology is also extremely problematic, since the general overview is lost, due to the large number of parameters and the sometimes not clearly identifiable interdependencies. The central machine cycle that is relevant for the operator is submerged in the abundance of existing parameters. One of the main reasons why this parameter concept will only have very limited suitability as a regulating concept in the future can be seen in the fact that the associated grouping of parameters is not based consistently enough on the actual structure of the machine and/or is focused too strongly on the existing technical software structures. This means that each additional function of machine control can have serious consequences relating to the required adjustments, since the complexity is increased disproportionately by the multitude of correlations. This means that, in addition to the effective complexity of the new function, another unwanted complexity is added.

A second issue is presented by the set-up time. On the one hand, this concerns the work effort, but also the production downtime during the set-up period. In order to be able to prepare the effective production of a new injection-moulding Axde:r in:a shad lim:~in :an Dpl4nized: and 3&-A :f -or ~a=e~
must not be too great. With the increasing complexity of the injection tool, the basic problem of a parallel and synchronized process control is also further accentuated.

EP 573 912 suggests a method for an injection-moulding machine, in particular for the configuration of the cycle, which involves the operating parameters required for the process of an injection cycle being entered, in an operator-guiding manner, into the data-processing unit via an entering unit, and then stored. Subsequently, one or multiple injection cycles are carried out based on the stored operating parameters. It is suggested as a solution:
= that the physically possible production cycle and the production cycle that is possible based on the machine and tool design are taken into account when entering the cycle and the configuration of the injection cycle, which is essentially done before the start of injection;
= that the equipment existing at the respective machine or assigned to it is registered and taken into account; and = that as a result, the user is provided with a selection of entry possibilities for other cycle components that can be compatibly inserted into the existing parts, including in the machine and tools.

The central idea of EP 573 912 is a consistent procedure based on the following fundamental principles:
1. The production cycle and the injection cycle are configured by the tool setter.
2. The tool setter is already given a selection of suggestions for logical steps at the first entry by the control unit.
3. Each entry that can lead to malfunctions, e.g. entry of invalid target values (such as pressures, speeds, temperatures, etc.) is refused by the control device from the outset.
4. The control device suggests a logical entry for each case.

5. As::a resut:a selecffcrr:ofi_w~Tf~:er~ Is tfe1M1Se1ter, thus helping to make his work easier and faster.

The control unit of EP 0 573 912 is based on a safety concept that restricts the flexibility of the control options. While providing a selection of entry options for the cycle increases the safety with respect to misconfigurations, the price for this is a restriction of flexibility and/or the possibility to fully exploit the free sequencing capability. EP 0 573 912 does not solve the initially described problem of the increasing complexity of the control device.

The US Patent Application 2003 / 0090018 describes a solution for programming and controlling an injection-moulding machine based on the principle of object orientation. The basis for this is a method that has been known for over 20 years (00-programmed method), for example according to the expert article "Object-oriented approach to PLC software design for a manufacture machinery using IEC 61131-3 norm languages"; Advanced intelligent mechatronics, 2001.
Proceedings. 2001 IEEE/ASME International conference on 8-12 July 2001, Piscataway, JN, USA, IEEE, Vol. 2, July 8, 2001 (07/08/2001), pages 787-792, XP010553352; ISBN: 0-7803-6736-7. Special reference is made to the listed references, e.g. B. Abou-Haider, E. Fernandez and T. Horton, "An object-oriented methodology for the design of control software for flexible manufacturing systems."

According to "Wikipedia," object-oriented programming (OOP) is a method for structuring computer programs which involves related data, and the program logic run by these data being combined into units, which are the so-called objects. At least conceptually speaking, a program will then no longer work to the effect (as is the case with percentage programming) that individual function areas of an algorithm are passed through in sequence. A number of data is modified, resulting in the evolving of the program logic in terms of communication and of the internal status modifications of the objects forming the program structure. The -advantaaPs of iy'rect-miented proqrammiqg:areJhie impnaved ~oct~7sris~fro~
:Gf the code and, consequently, an improved serviceability and reusability of the individual modules, as well as an overall higher flexibility of the program, particularly with respect to user guidance. This only indirectly makes the operation of the machine by the user somewhat easier.

The task underlying the invention was to search for solutions that allow for a full exploitation of flexibility and offer an easy-to-learn operation of the machine, in particular the configuration of machine processes and parameterization, and avoid the problem of unwanted complexity.

Description of the Invention According to the invention, machine cycles are designed, managed and run on the basis of behaviourally complete components, together forming a domain model, by means of a specialized domain language, in order to facilitate the handling and operation of an injection-moulding machine in a universal and simple manner.

In a device according to the invention, the computing/storage tools are designed to hold a locally organized knowledge base. At the operator controls, an image of at least part of the equipment existing at the respective production cell or assigned to it can be created in the form of its components in a domain model and operated accordingly, so that the operation of a production cell can be learned in a universal and simple manner.

A particularly preferred embodiment of this method is characterized by the control, programming and configuration being carried out on the basis of a component-oriented domain language for modelling cyclic and/or non-cyclic machine processes, based on a representation of the machine as a structured ~oflec~i~ ~ rampwmmts, and :th:e prGd=t>m zyc7e beft =Egured: oir programmed accordingly.

In a particularly preferred embodiment of the device, the control, programming and configuration can be carried out via the operator controls on the basis of a component-oriented domain language for modelling cyclic and/or non-cyclic machine processes, based on a representation of the machine as a structured collection of components, and the computing/storage tools are designed to hold a locally organized knowledge base for the components.

The inventors have recognized several factors and taken them into account in the new invention: A first, basic factor when it comes to controlling a production cell for producing plastic injection-moulded parts is that:

a) the process is dependent on the specific requirements of the production facility, and changes depending on the tools and, for example, based on the degree of automated production.
b) the operating parameters change depending on the injection moulding order, e.g. based on a different tool, different peripherals or different plastic.

The second basic factor is:

a) the hardware and software conceptualization of the control philosophy (e.g. central or local); and b) the manner in which the freely selectable processes and parameters are entered on the operator terminal of the control device.

The third, basic fact lies in the use of a domain model designed as a component model. The components are designed in a behaviourally complete structure. A
domain model describes the knowledge on a certain application field in the prabrem: area,- ie.,aIL fechn i cay: reTe~~t ~a~~s zequired :for uriderstarfdir tg ffm:
problem are combined in one model. The representation of the domain elements and their relations (e.g. in the form of a class diagram according to UML) forms the core of a domain model. By contrast, object-oriented programming is a programming concept which primarily offers advantages to the manufacturer of an injection-moulding machine, but does not directly influence the operation per se.

The conceptual model on which the user interface is based describes a system of interrelated objects. These objects form the basis for the mental model of its users. Each object describes a manipulable unit that is offered for direct use in the user interface. Each object is complete in its user options. This means that it can be understood and used by the user. The user interface does not expand the semantics of the object but merely represents the object with its options and allows its manipulation. The term "behaviourally complete" in practice refers primarily to operation. Behaviourally complete components are objects that can be used directly for operation and provide everything for the representation and manipulation of same.

Behavioural completeness is the basis for an easy-to-learn user interface that moves into the background in favour of the task to be solved after a short adjustment period. Behavioural completeness is the necessary prerequisite for the implementation of an interaction style based on directly manipulable objects.
This is a consistent continuation of context-sensitive operation; the context reveals the available actions exclusively on the basis of the object to be manipulated. This interaction style "Select object and manipulate" is easy to understand and use; it only requires a very small learning effort and also supports the above-mentioned requirement that the user interface is to move into the background, in an ideal fashion.

At the Amntm-~ the::mew inven~i~rr is -ffie Ammpmant is- Lmecl im multiple ways: in the process and in the device; each physically existing and detected component is virtually represented in the control device.

An especially significant advantage of the new invention is that:
= the operator makes his entries in a component- and command-oriented manner; and = the user configures the production cycle with the greatest possible freedom, and parameterization is made significantly easier; and also that = the production cell is subsequently controlled in a component-oriented manner.

The benefit of the new invention for the user already presents itself when at least the most important components, especially those directly influencing the injection-moulding process, are treated in a component-oriented manner. Which additional devices are treated as components also strongly depends on the significance of the respective function in the overall cycle, as well as the automation level.

In the current state of technology, the focus is either the parameterization or the configuration of the production cycle. In both cases, neither the issue of the complexity of the control device nor the unrestricted optimization of the production cycle could be solved with respect to a truly free programming by the user. A differentiation must be made between injection-moulding machines used to make the same injection-moulded parts for years, and machines in which the tools have to be frequently changed, based on the current order. In both cases, the concept of a component-oriented control according to the invention offers major benefits, both for the injection-moulding machine manufacturer and the users of the machine. For the Applicant, the conversion from the previous control concept to the component control system means an enormous work effort in the range between 20 and 30 man years.

Thazamept~of~ onentmocfel fO1r-.UT_rE-Aet _ is based on a plausible and easily comprehensible system model. The machine is comprised of components controlled by a sequence. This concept replaces the previously conventional parameter concept and creates a basis for the implementation of even complex control processes by means of a freely programmable process control system. Replacing the current, parameter-based machine control system with a component-oriented system allowing the user to control and monitor the machine on the basis of the machine cycle results in a drastic simplification of operation. The component model provides the ideal prerequisite for creating a system enabling the user to fulfill upcoming tasks in a goal-oriented and efficient manner, following the motto "Simple things made easy. Difficult things made possible."

The new solution according to one aspect concerns the control architecture and the control process in relation to the user. Here, a significant aspect is the replaceability of components and the possibility to add additional components to the control system, either at the level of the virtual component or the machining components. An example for this is the change from a hydraulic to an electric drive unit, either for individual or all axes. A key advantage of the new solution is the fact that with the component model, any further development or restructuring of the entire control system is made significantly easier, since the components are only loosely coupled with each other and it is therefore easy to replace them or add additional components. This means that the complete control system offers enormous advantages and improvements both for the manufacturer and the user, in the present and in the future. Any further development in the area of the production cell can be done in a component-oriented manner with respect to engineering, process technology and control technology, without causing the complexity of the control device to increase disproportionately. In other words, "the system scales."

~zamponent :of t~~fectk~-m:outdftig:
machine. Therefore, the machine can be viewed as a combination of components. This form of structuring can be continued in the controlling software, where each hardware component has a counterpart as a software component. Logical components that, for example, capture or encapsulate procedural knowledge, or also timer components, can be easily implemented in this manner. The component concept is also easy to understand for the tool setter and the user.

The term "component" means concrete assemblies or modules, such as:
= Injection axis and/or = Plastification axis and/or = Injection aggregate and/or = Mould closure axis and/or = Mould axis and/or = Rotary mould disk and/or = Core pullers and/or = Sliders and/or = Ejector axis and/or = Extraction robotics and/or = Column adjustment axis and/or = Heating and cooling unit and/or = Hydraulic aggregate (if any) and/or = Electronic components and assemblies and sensor technology and/or = Material supply and/or injection-moulded parts handling appliance and/or = the injection-moulded part.

FIowevEH, ~ TaWartementirs the:laroductkm celi, both-at the logical and physical levels, including any peripheral devices that may be assigned to it.

According to another particularly advantageous embodiment, the solution for each problem area can be described in functional terms in the control system on the basis of a conclusive domain model and by means of specific domain languages, and the program code for the technical implementation can then be automatically generated from this.

The new solution according to another aspect relates to the so-called freely programmable sequence control (FPSC) for generating, testing, optimizing and monitoring machine processes during the production of injection-moulded parts, supported by a domain language. The sequence control according to the invention is designed to help significantly reduce the response time to customer demands and particularly eliminate, as far as possible, the currently still required complex customized special programs.

There are three resulting scenarios for the user:
1. In the case of a new injection-moulding order with an existing tool, the stored dataset is reloaded into the control system when the tool is set up.
It does not matter whether the datasets are stored in an external data carrier, such as a floppy disk, memory stick or host computer, or in the control system. No programming is required when setting up the tool.
Control is based on the component model.
2. In the case of a new order with a new tool, the production cycle and the parameterization must be newly created at set-up. This is done on a component-oriented basis.
3. In the case of simple modifications, for example on an existing tool, the resulting solution is something between 1 and 2.

XSGcordinq: fo: an: especia1Cy of ffm: soYufian,a:
component knowledge base is assigned to the component. This allows for the use of maximum free programming, since the component itself provides the key organization concept. Controlling is done in a component-oriented manner for at least part of the equipment existing at each production cell or assigned to it. The advantage is that each of the covered components contains or encapsulates relevant procedural, mechanical and other relevant knowledge in order to provide the functions required for a cycle in an organized manner in the form of commands; this is done in collaboration with other components. In addition, each of the covered components contains or encapsulates relevant procedural, mechanical and other relevant knowledge in order to ensure protection for the machine part represented by the component.

The operating parameters required in the production cycle are input by the user by means of a data processing unit storing these operating parameters, while the control system takes into account both the physically possible options and those options based on the design of the machine and tools. The plausibility of the process is examined prior to the first run. Only valid values are accepted when parameterizing the cycle.

Each component provides control commands in the form of a command interface and features an event interface; the components are manipulated via the command interface in order to trigger one or multiple commands in other components working together with this component, if necessary. Status modifications in components can be adopted in the form of events via the event interface and used directly between the components as a basis for synchronizations, and as synchronization sources for influencing the production cycle. In their event interface, components offer event sources and destinations.

sounms: :are events- thiat = be= adop3e(i Cyy ~ zampmants:, :for example, the mould closure offers the events "Mould open" or "Mould locked."
Event destinations are required in order to be able to respond to events in the system that occur asynchronously to a machine cycle, such as the stop button being pushed. In this way, any processes in the area of the production cell can be created on the basis of the component model and then executed by the control system. Based on a representation of the production cell as an organized collection of components, cyclic and/or non-cyclic processes can be freely programmed and executed.

According to another embodiment, the injection-moulded part is treated as a virtual component in the sense of object orientation. The characteristic values of the manufacturing process, the production level or any other status of the injection-moulded part can be stored in the part and used to influence the injection-moulding process; for example, to control a reject gate.

An especially advantageous embodiment of the solution is one in which a domain language is used to describe solutions for every problem area in the control system, and the program code is automatically generated.

In another advantageous embodiment of this method based on a representation of the production cell as an organized collection of components, processes are freely programmed and executed on the operator interface on the basis of the components and their commands. The new solution allows the creation and execution of any cyclic and/or non-cyclic processes in the area of the production cell, based on the component model.

The production cycle, particularly the injection cycle, is based on the commands of the physically existing components and is created in an interactive process, which involves the following steps at the programming stage:
a) the control system offers all physically existing components as a selection;

b) Mm onerits requred for: tTie pmcess irrIliL-s-ense ufz:
pre-selection;
c) the user selects a command or an event source of a component and inputs the command or event source into the process;
d) this input is stored in the data-processing unit;
e) steps c) to d) are repeated until the process is complete;
while the parameterization of the commands, event sources and components involves the following steps:
f) selection of a command or an event source in the process and/or a component used;
g) display of the relevant parameters;
h) input of the parameters;
i) this input is stored in the data-processing unit;
j) steps f) to i) are repeated until all commands and event sources involved in the process or all components used have been parameterized.

Steps f) to i) can be carried out either after or during the creation of the process, until all commands, event sources and components used in the process have been parameterized.

First, the tool setter interactively configures the injection cycle on an input mask and inputs the operating parameters in a command- and component-oriented fashion. Preferably, a pre-selection of components required for the process is made and/or offered from the organized collection of components on the input mask. All function-relevant equipment existing at the respective production cell or assigned to it, such as peripheral equipment and tools, are interactively configured in a component-oriented fashion and integrated into the production cycle. Prior to the start of production, the machine processes are graphically and interactively configured via the input mask and the operating parameters input in a command- and component-oriented manner.

Azrcft fo:~arnfagecyus embGdirr~, Ihe c~ 1 ~emLtnf~res: ari:
input mask comprising a process list, a process presentation field, a component list with selectable commands and also a parameterization field; the operator creates the process in the process presentation field and parameterizes the components and commands used in the process in the parameterization field. A
definite advantage of the new solution is that the processes can be programmed in a completely free fashion. Due to the component knowledge, when a command is entered in the process presentation field, other commands for the mandatory follow-up steps are automatically inserted into the process as blanks.
The user then fills the blanks with concrete suitable commands for the components concerned.

The user has free choice for every process step. Contrary to the initially described patent EP 0 573 912, the new solution does not present the tool setter with a limited selection but with the entire range of options for his free selection.
Once a command has been specified, the control system prompts the tool setter to specify the follow-up steps according to the component knowledge, i.e. fill the automatically inserted blanks with concrete commands for the components concerned from the component list of the input mask.

Only those components and commands that are used in processes have to be parameterized. Thus, the variety installed in the control system is reduced to the essential options in a simple and comprehensible manner. The question of mandatory inputs required in order for the production cycle to be started is no longer an issue. For the parameterization of the components and their commands, only values within a permissible range will be accepted. The parameterization status of the components and commands used in a process is visualized, for example by colour-marking all incompletely parameterized commands and components. In a similar manner, any incomplete processes (i.e.
processes still containing blanks) in the process list, or processes containing components and commands that are not completely parameterized, are h~hiic~nted:_in Crr1_Kdd&rr ~ is t[ie_cptio~ using eNiEifmg pmcesses-as macros in other processes. For this purpose, the existing process can be inserted into another process as a macro, like a command. The macro can be expanded, for example to adjust the parameterization. The calculated ideal dataset is stored for all successfully created and executed production cycles, and can be reloaded by the user for the same or similar production cycles.

In a particularly advantageous embodiment design, parallel processes are synchronized with each other.

Another key aspect is that for the set-up of each new component, in particular a new injection-moulding tool, the necessary data are inserted in a component-oriented manner at the operator terminal. It is very advantageous that for the set-up of a new component, particularly a new tool, the specific process data can be input or loaded in electronic format at the operator terminal, based on a datasheet. For the set-up of a completely new work order with new moulds, the user can be offered several options, so that the production cycle can be immediately entered at the operation terminal in optimized form. For example, templates for typical production cycles can be offered and modified or amended by the user.

The new solution allows the tool setter to be provided with an expert system (e.g.
as an assistant) for the process configuration and the parameterization.

Another very advantageous inventive concept is that, based on the component idea, a comprehensive domain language, the "Process Application Language,"
was created, which allows for virtually any complex process for injection-moulding machines and/or production cells to be modelled in a universal and simple manner. A domain language is a formal but strongly simplified language for describing the facts in a problem area. The domain language comprises a small amount of words and can be visualized as text or graphics.

~axTdl~g :to: fha: n:Ew~oTufio~, fh:e:coroI~s~is::a ~f- rivm:
system. This means that it only responds to events. For example, there are no status requests (Polling). If component A is interested in the status of component B, component A adopts the relevant event from component B, which is triggered by a status change. This principle ensures that communication in the control system is restricted to a minimum.

The individual axes of the injection-moulding machine have a cyclic progression and together form the injection cycle. While the axes are synchronized to ensure that no axis "runs off," they do not have a common synchronization point, such as a common start/end point.

The visualization and operation of the injection-moulding machine is based on behaviourally complete objects. Objects or components are behaviourally complete if all functions are realized as behaviour or methods in the objects.
Such objects can be visualized directly and automatically (completely generic visualization).

During the manufacturing process, the injection-moulded part passes through various manufacturing stages. The process of the injection-moulded part passing through the manufacturing stages is called the part cycle. The part cycle can be integrated into the production cycle, with the production cycle driving the part cycle. The part and machine cycles do not have to be identical for this. A
virtual injection-moulded part passes through the various manufacturing stages while collecting information that, in turn, can influence the production cycle. For example, the virtual injection-moulded part collects the quality data and thus knows at all times whether it is still a good part or not. This information can be used to control the reject gate, for example.

ApcGrcift:to, ~ott~ ~dvanT_ageoas Aesjgp~_ it is: mWestof thaT :an: indivi~uaT
component should represent any element of the injection-moulding machine or the equipment and peripheral devices assigned to it, such as the mould closure, aggregate, core puller and handling appliance. Purely logical components can also be treated as individual components. Each of the components taken into account features an event interface and a command interface and has its own internal component knowledge.

Preferably, the control system is based on an organized collection of virtual components representing the elements of the production cell, each with their specially assigned knowledge base, while the production cell can be controlled in a component-oriented manner and the production cycle is driven by the commands, according to the configured process. Each component contains relevant procedural, mechanical and other relevant knowledge in order to ensure the protection of the machine part represented by the component.

Preferably, the operator interface features an input mask containing a process list and a process presentation field, a component list with selectable commands, and a parameterization field.

The tool process and its parameterization can be input, for example, based on a datasheet or loaded in electronic format; these data are usually defined by the tool manufacturer. The new solution allows the set-up of a tool to be carried out in a new distribution of tasks process.

The modelling of the process and the input of the commands, as well as the parameterization, can be carried out as part of the work preparation in a separate room away from the manufacturing process, and transferred to the machine control system. The tool setter at the machine can focus on the mechanical set-up and the process functions and their optimization, if applicable.

Ihe: memr ~~~ :essentialfy IeIa~e~ to: ffie~~~a~ freeTy pmgwmuible sequence control (FPSC) for generating, testing and monitoring production cycles in an injection-moulding machine. The freely programmable sequence control system is designed to help reduce the response time to customer requests significantly and, in particular, eliminate the currently required customized special programs to the greatest possible extent.

For better understanding, definitions are provided for the following terms.

Process string: A process string is a sequence of commands performed consecutively. Several process strings can be performed simultaneously (parallel time). Parallel process strings can be synchronized.

Base library (BL): The base library provides the sequence control unit with the general basic functions, access to the operating system and hardware, thus uncoupling the sequence control from the hardware and the operating system.

A domain language is a formal but strongly simplified language used to describe the facts in a problem area. Compared to a general programming language (General Purpose Language), a domain language has the advantage that it is much closer to the problem in need of a solution, resulting in programs (source code) becoming much more concise and significant. The consistent use of domain languages can contribute much to the manageability of complexity. This is a particularly advantageous inventive concept of the present solution. The domain language comprises a well-defined number of words suitable for the functional problem, such as "cycle," "scopes," "task," "sequence," "waitFor,"
"command."

In order to be able to map the freely programmable sequences, a comprehensive domain language - the Process Application Language - was created on the basis of the component principle; by means of this language, injection-moulding rrfacFiir~ jxpzesses: uf viffuaU- ay=VIexifg can be ~creTf~d in:a zrrfiversar and simple manner. The Process Application Language fulfills a double purpose:
on the one hand, it serves to enable the unlimited presentation of the basic processes available today from the start, including in the new system. At the same time, however, it forms the basis for the description of the freely programmable machine processes and thus the freely programmable sequence control. The Process Application Language represents the logical continuation of the component model, thus ensuring that the new operating concept, based on which the freely programmable sequence control is implemented, remains simple and thus allows the operator to work with an injection-moulding machine in a continuous, efficient and secure manner. The component-oriented domain language (Process Application Language) serves to model cyclic and/or non-cyclic machine processes, including all process steps required on request, in the form of commands for triggering component commands for the production preparation and/or completion of production, and also provides support for event-based synchronizations and inter-cycle commands. In addition to complete support for the parallel execution of process sequences, the Process Application Language also offers commands for:
= triggering commands of components, including the command arguments required for this;
= signalling status modes;
= waiting for status modes to be signalled;
= setting conditions for the execution of certain process branches;
= grouping process sequences for a cycle; and = forming name areas.

In addition, this language provides the option of using information on the work piece to be manufactured, by means of the modelled machine process as a synchronization and decision source to influence the process, and storing the relevant information, based on demand, from all available status information (if necessary, also inter-cycle). In the control software, both functional domain-specific_- anid pratzTems-masT be: sdIve(i. A: g=ocyd - - - ect~re=
ensures a clear separation between functional domain issues and technical software requirements. This separation is extremely important! If it is missing, there is a risk of the software being designed and implemented based on technical requirements and the actual functional problems being pushed into the background. Without a significant and easily comprehensible domain model, software quickly becomes a technical solution that sooner or later wi!l be unable to keep up with requirements. Problem-solving is increasingly dominated by technical issues and problems that have nothing to do with the original functional issue. This is an entirely different matter if the design and implementation of the software is based on an application model that places the functional domain into the centre of considerations and is clearly focused on it, both conceptually and linguistically. Such a domain model that can be understood both by users and developers forms the basis for a rich and beneficial communication between technical representatives and software developers.

In contrast to the so-called General Purpose Language (GPL), a domain language serves one and only one specific purpose. This means that such a language is uncompromisingly focused on the respective problem and realizes the concepts of the respective application area directly with the help of corresponding language constructs on the basis of a syntax designed to be simple and expressive; the domain language - referred to as Domain Language (DL) or Domain Specific Language (DSL) in English - thus becomes the basis for a domain-driven design in which the technical details - which, while important, are ultimately not domain-relevant - can move completely into the background in favour of the functional problems requiring a solution. Thus, the prerequisites are created for a form of model-driven application development in which the actual intentions of the solution are phrased clearly and unmistakably and can be reproduced and understood by experts at any time.

~~t~chni~a~pempactive, a d :n JarqTuag~~~~~~-order a&tracSxr since it remains completely unaffected by the technical details of a GPL. For example, in a domain language, loop processing or concurrency can be encompassed in such a way that the technical issues of a solution remain completely hidden in a specific GPL. By consciously ignoring technical issues that are irrelevant in the context of the functional problem, that is, by being selectively ignorant, we achieve a simplification of the solution-finding process and description at the application level by means of a domain-related concretization. Thus, the use of a domain language represents the next logical step on the path to high-order abstractions that allow us to increasingly ignore the often ugly technical details of the functionality of information technology. By means of the GPL, we can implement that which is used in a functional context by means of the domain language.

Event source: Each component offers events in its interface which can be adopted by other components; for example, the mould closure offers the events "Mould open" or "Mould locked."

Event destination: Each component specifies event destinations in its interface which it needs to be able to respond to events in the system that occur asynchronously to the production cycle; for example, the stop button being pushed.

Encapsulation: In object orientation, "encapsulation" refers to the hiding of implementation details (incl. structure and data). Direct access to the internal data structure is prevented and instead occurs via defined interfaces.

Command: Each component offers a series of commands in its interface which can trigger actions in the component; for example, the mould closure offers the commands "Close" or "Open."

Command argument: Each command can have any number of command arawTends. These= arg-unaenl& :are fhe-&-itairequinad fouthe:iaxecufionjof the:
command, such as speeds, times, pressures, paths, etc.

Component: A component describes a mechanical element of the injection-moulding machine, such as the form closure, the aggregate, etc. The machine can therefore be defined as a combination of components. This form of structuring can be continued in the control software, where every hardware component is mirrored by a software component. Logical components, such as components capturing technical knowledge, or timer components, can also be easily realized in this manner. The component concept is also easy to understand for the operator.

Each component offers both event sources and event destinations in its interface.

On a logical level, the components represent the machine elements to be physically controlled, including any peripheral devices. The processes are programmed based on the components required in each case. These components offer their functions in the form of commands that can be parameterized. In addition, they feature an event interface which provides all relevant status modes of a component in an adoptable form.

Programming: Generating a production cycle and parameterizing the components and commands used in this process.

Process engine: An infrastructure component containing the logistics required to be able to execute a production cycle modelled by means of the Process Application Language. "Execute" means that the process engine calls the commands on the components according to the production cycle.

Reactive System: The SySTeM 1S7eVaa=drivBrr Le. it respancrs ta it not provide status requests (Polling). If a component A is interested in the status of component B, A adopts the event of component B, which reports status changes. This principle restricts communication to a minimum.

Injection cycle: The individual axes of the injection-moulding machine have a cyclic progression, together forming the injection cycle. While the axes are synchronized with each other so no axis will "run away," they do not have a common synchronization point, such as a common start/end point (as is the case in EP 573 912).

During the manufacturing process, the injection-moulded part passes through various manufacturing stages. The process of the injection-moulded part passing through the manufacturing stages is called the part cycle. The part cycle can be integrated into the production cycle, with the production cycle driving the part cycle. The part and machine cycles do not have to be identical for this. A
virtual injection-moulded part passes through the various manufacturing stages while collecting information that, in turn, can influence the production cycle. For example, the virtual injection-moulded part collects the quality data and thus knows at all times whether it is still a good part or not. This information can be used to control the reject gate, for example.

Behaviourally complete: Components, or objects in general, are behaviourally complete if all functions are realized as behaviour or methods in the objects.
Such objects can be visualized directly and automatically (completely generic visualization).

The concept of object-oriented programming, which is generally known, can be described as follows: The individual elements making up an object-oriented program during its execution are, as previously mentioned, referred to as objects.
These objects are usually conceptualized based on the following paradigms:

Abstracrion: E~ iabLeof in ~sysTe~ an Ia exsidamcTa~n Atss1ractmocf"
an acting factor that can process orders, report and modify its status and communicate with other objects in the system without having to disclose how these skills are implemented.

Encapsulation: Objects cannot read or modify the internal status of other objects in an unexpected manner. An object has an interface which determines in which way an interaction with the object can take place. This prevents invariants of the program being circumvented.

Polymorphy: Various objects can react differently to the same message. If the correlation between a message and the response to this message is only terminated during the runtime, this is also referred to as a late bond (or dynamic bond).

Inheritance: New types of objects can be defined based on already existing object definitions. New elements can be included or existing ones overwritten.
If no inheritance is enabled, this is often referred to as object-based programming for a better distinction.

Classes: For better management of similar objects, most programming languages use the concept of classes. Classes are templates from which objects are generated at runtime. The program does not define individual objects, but a class of similar objects. The creation of objects from a class can be imagined in a similar way to the manufacture of cars from the design plan of a certain vehicle type. Classes are the design plans for objects. The class approximately matches a complex data type of procedural programming environments, but also goes beyond this: It not only specifies the data types making up the objects created by means of these classes, but also defines the algorithms operating on these data.
Thus, while individual objects interact with each other during the runtime of a pmV.-m ffie baEic pattern: :of~ 1r~erac~io~ Is:~t~necTW ffiffcte~rr=of tfie~
individual classes. In some programming languages, there is also a certain object for each class, the so-called class object, the purpose of which is to represent the class itself during runtime. This class object is also responsible for generating the objects in the class and calling up the corresponding algorithm. Classes are usually combined into class libraries, which are often organized by theme.
Therefore, users of an object-oriented programming language can purchase class libraries enabling them, for example, to access databases.

Methods: The algorithms assigned to a class of objects are also referred to as methods. The term "method" is often used as a synonym for "function" or "procedure," although the function or procedure should rather be considered the implementation of a method. In everyday usage, one also says "Object A calls Method m of Object B." A special role is played by methods for encapsulation, in particular also as access functions. Special methods for the construction and/or "destruction" of objects are called constructors and destructors.

Brief description of the invention The invention will now be explained in more detail using several examples. The figures show as follows:

Figure 1: a purely schematic representation of the entire problem area as per the task presented (top) and the solution by means of a Domain-Specific Language (DSL) (bottom right);
Figure 2: a more concrete design of a multi-DSL environment with a multi-purpose data storage;
Figure 3: the control unit as an organized collection of components as a concept for the control system;
Figure 4: the layered architecture of the new solution (layer model);
Figure 5: the schematic representation of the process editor;

F ig u re 6: :an examj~ka :for t~ gmVji~- m-presenfaiyrr :of ~Prmass:
Application Language (PAL);
Figure 7: an example for the textual representation of the Process Application Language;
Figure 8: a typical template sheet for the tool designer with the instructions for the tool process.

Methods and design of the invention The following refers to Figure 1. Previous practice shows that functional and technical software problems keep coinciding in the control software of, for example, an injection-moulding machine. This necessarily leads to an increased complexity of the software. To implement the functional and technical requirements, the new solution suggests a consistent separation by means of domain languages (English: Domain-Specific Language - DSL; Figure 1, bottom right). The figure on the bottom left shows a domain-driven design without DSL.
The bold dotted line symbolizes the complete meshing of the two problem areas without a DSL. The result is not only increased complexity, but also significantly more work if the program is modified at a later point. The domain-driven design based on domain-specific languages has the major advantage that technical aspects can be treated and solved separately from the functional requirements.
This allows the functional programming to be performed - closer to the functional issues and thus more concrete - and more removed from technical issues and thus more abstract.
Figure 2 shows a more concrete representation of the new solution with a multi-DSL environment for domain-driven design. The task can be solved in an ideal way, thanks to the following advantages:

- modification-friendly - useful documentation - txoxiTay ~~_~~~i~Terr~~~ ~fiarrctiorfaf~r~d ~e~Ti~icaTTeve1.

- :environrrient for :a:Aorrzini-:diven desig_n--witlT e Mu:Cfi=PzPo:se::
data storage forms the basis for the creation of the necessary DSLs. The initially higher development effort for the creation of this infrastructure is more than balanced by the increased effectiveness and efficiency. DSLs, especially in a multi-DSL environment, facilitate a genuine domain-driven design (DDD). The domain-driven design (DDD) focuses on the functional issue and does not make any technical specifications. The DSL brings us closer to the functional issue; it reduces the unwanted, not the essential complexity. The separation of functional and technical issues by means of a DSL increases the effectiveness and efficiency. All-purpose languages such as C++ are still required for the technical implementation. The reduction of unwanted complexity facilitates a better -and therefore faster - analysis, understanding and solution of functional problems.

The system model underlying the control system, shown in figures 3 and 4, views the machine as a combination of cooperating components. A component (4, 7) incorporates any element of the injection-moulding machine, both at the logical and physical level, including any peripheral equipment assigned to it. Based on the components existing at the machine, the user generates machine cycles (1) on the operating unit (2) or the operator terminal (1). In order to execute a machine cycle, it is loaded into the process engine by the control unit. The process engine (3) now drives the cycle, i.e. it calls the commands (5) on the involved components (4) according to the loaded machine cycle. When a component has executed a command, this is signalled to the caller of the command (6). The process engine is the infrastructure part containing the necessary logic in order to be able to execute a production cycle modelled with a Process Application Language. "Execute" means that the process engine calls ffie: zammancl~~~ cGmpxents accardi.na:to the: pmdutdoTi- zy-Te For example, the process engine calls the command "Close" at the component "Mould" (4a). The mould component, in turn, then calls the command "Drive" on the electric linear axis "Mould closure" (7a). Via the base library (8), the command to drive is transmitted to the controller (11) (figure 2) controlling the motion of the axis according to the specified drive profile. Once the axis reaches its destination, the controller signals this to the linear axis component (7a), which signals the end of the drive command to the mould component (4a), and eventually, the mould component signals the end of the closing command to the process engine (3).

Since this is a reactive, event-driven system, command calls do not have a blocking effect, and several commands can be triggered practically simultaneously on various components; for example, "Dosing" can run parallel to "Opening" and "Closing" of the mould. The coordination and synchronization is taken over by the process engine (3).

In the control unit, a differentiation is made between components of the logical (4, 12) and technical (7, 13) levels. Logical components (4) represent a functional unit of the injection-moulding machine or production cell, such as the mould closure unit ("mould" for short) (4a), the dosing and injection unit ("screw"
for short) (4b), etc. A logical component can consist of several axes; for example, the dosing and injection unit (4b) consists of a linear (7b) and a rotation axis (7c).
A technical component (7) represents an axis. It ensures that the drive technology is easily replaceable by encapsulating the drive technology. Thus, the replacing of the drive technology does not influence the logical components or the configured machine cycles.

The physical, actual components are symbolically represented in figure 3 below in the image of an injection-moulding machine (30). Of the multitude of individual components "X", only the following are indicated: drive unit or axis, mould motion (31), ejector (32), movable mould or tool (33), endless screw (34), linear drive of tha: end[ess~crPwffmear axis~~~andffirive::of the iNi1Cess:
(rotation axis) (36), aggregate (37), protective cover (38).

Figure 5 shows a process editor. Operating the machine is significantly easier if the machine cycle is explicitly visible to the operator and the relevant information can be clearly recognized and changed, if necessary. The visualized machine cycle based on known components such as the mould closure, aggregate, ejector, etc. can also be used as an organizing element for the parameterization of the individual commands that are ultimately used to control the machine.
The individual commands, such as "Close mould," "dose" or "inject" can be represented directly and made available for editing. With the process editor according to figure 3, any process, such as the production cycle, can be modelled and the components and commands used can be parameterized. The process editor and/or the processes are the focus of the programming of the injection-moulding machine. The entire parameterization of the injection-moulding machine, including the assigned peripheral equipment, can be viewed and modified via the process editor. Thus, the currently conventional distribution of the parameters across a number of input masks (screen pages) can be foregone. The process editor according to fig. 3 consists of four areas:
= the list of all existing cycles; process list (14);
= the list of all physically present components; component list (15);
= the graphic representation of the cycle; process representation field (16);
and = the input mask for the parameterization of components and commands;
parameterization field (17).

If an existing cycle is selected (18), the cycle is graphically visualized in the process representation field (16). The user can now edit, rename, copy or delete the selected cycle. To create a new cycle, the user can access the function "New" in the process list (14). There is the option to select those components that am ~~or tha ~ cycTe fro-rrf~i Esf nf pMEkEffly pTitzamp nerits, ih:
the sense of a pre-selection. To create the actual cycle, the user selects a command (20) of a component (19) and adds it to the cycle (16). He will then repeat this until the cycle is complete. When the user selects a command in the cycle, the associated command parameters are displayed in the parameterization field (17) and can also be entered there. A command can be used several times in a cycle. Each use (command instance) has its own parameterization. In the process representation field (16), synchronizations (22) can be inserted between the commands and parameterized, if necessary. In addition, there is the option of moving or deleting the commands and synchronizations inserted into the cycle or to modify the associated parameterization. Within a cyclic process, many commands are symmetrical, i.e. if an axis (e.g. an ejector) is driven forwards, it will have to be retracted at some point. Based on this component knowledge, the control unit automatically inserts blanks into the process, which the user has to fill with concrete commands.

Only components and commands that are used in processes have to be parameterized. Thus, the variety installed into the control unit is reduced to the essentials in an easy and comprehensive manner. The question of mandatory entries needed for the production cycle in order to be able to start is no longer an issue. A cycle is complete when all blanks have been filled and all components and commands used have been fully parameterized. From the list of existing cycles (14) it can be seen at a glance which cycles are complete; in addition, incomplete cycles are marked. In the process representation field (16) and in the component list (15), commands or components with an incomplete parameterization are also highlighted. In the parameterization field (17), missing parameters are also marked.
In addition, there is the option of using existing cycles as macros in other cycles.
For this purpose, the existing cycle is entered as a macro into another cycle, like a command. The macro can be expanded, for example in order to adjust the parameterization. The creation of a cycle based on existing components and ftteir zommairTc1s is not-subje~ct f~ restric~i~T HmveveT, thede:
of potential errors in the cycle in the context of a plausibility check; for example, if the ejector is to drive forwards when the tool is closed, the user will have to confirm this.

The Process Application Language (PAL) is a component-oriented domain language and serves to model cyclic and non-cyclic machine processes. In addition to complete support for the parallel execution of process sequences (23), it also offers commands for:
= triggering commands (25) of components, including the command arguments required for this;
= signalling status modes (26);
= waiting for status modes to be signalled (24);
= specifying conditions for the execution of certain process branches;
= grouping process sequences into a cycle (27 + 28); and = forming name areas; scope (29).

The PAL can be visualized either graphically (figure 6) or as text (figure 7).
The two forms of representation have the same content of information. The graphic representation is preferred for the operating unit, since it is easier to understand and the process can be registered at a glance. The words of the domain language are bolded in figure 5.

Figure 7 is a typical instruction sheet for the mould manufacturer. The set-up of a new mould (33) for a matching production order can be based on the following steps. The tool setter usually receives a mould diagram, a description of the moulding process and possibly a report on the mould trial from the mould designer. Based on this information (mould size, injection volume, closure force, etc.), the tool setter establishes or verifies the size and equipment of the injection-moulding machine. The tool setter mounts the mould (33), connects it and then checks the functions of the individual axes of the mould (33) while in mamia-l:orset-W moda liow,th:e tod seffeT can enrtertTienoaYdprocess m the operating unit of the machine. The individual axis movements are usually first tested in manual or set-up mode before being integrated into the process. In this phase, parallel axis motions are deliberately avoided, since the tool setter first has to ensure safety when dealing with the mould and the process. Once the mould process is running, the axes of the injection unit (aggregate, dosing and injection axis) are then integrated into the process. Now, a part can be injection-moulded for the first time. The injection process is refined to ensure that good-quality parts are produced. Now, the tool setter starts to optimize the production, with the goal of producing good-quality parts within the shortest period possible.
He has the option of reducing the cycle time by parallelizing the processes and increasing the speed of the drive motions. In the final step, the peripheral equipment, for example an extraction system or a sprue picker, is integrated into the process.

Figure 8 shows an example for the instruction of process sequences as prescribed by the manufacturer of injection-mould tools.

Claims (39)

1. Method for controlling and operating a production cell for producing plastic injection-moulded parts, including at least part of the peripheral equipment assigned to it, according to which the production cycle is defined and parameterized by the user, wherein machine cycles are designed, managed and run on the basis of behaviourally complete components, together forming a domain model, by means of a domain language in order to facilitate the operation of an injection-moulding machine in a universal and simple manner.

2. Method according to Claim 1, wherein the control, programming and configuration occurs on the basis of a component-oriented domain language for modelling cyclic and/or non-cyclic machine processes, based on a representation of the machine as an organized collection of components, the process being configured or designed by the user.

3. Method according to Claim 1 or 2, wherein a component incorporates any element of the production cell, both on the logical and physical levels, including any peripheral equipment assigned to it.

4. Method according to one of Claims 1 to 3, wherein for each problem area in the control unit, the solution is described at the functional level on the basis of a coherent domain model and by means of specific domain languages, and the program code for the technical implementation is automatically generated.

5. Method according to one of Claims 1 to 4, wherein a domain language is specified to describe any process in the production cell, said domain language being visualized on the operator terminal and/or an input mask in graphic or text format.

6. Method according to one of Claims 1 to 5, wherein at least part of the equipment existing at each production cell or assigned to it is registered and taken into account as components in the control unit, and the components appear on the screen and/or operating unit and can be used by the user as the basis for modelling any process.

7. Method according to one of Claims 1 to 6, wherein components are concrete elements or modules, such as injection axis and/or plastification axis and/or injection aggregate and/or mould closure axis and/or mould axis and/or mould rotation disk and/or core pullers and/or sliders and/or ejection axis and/or extraction robotics and/or column adjustment axis and/or heating and cooling unit and/or hydraulic aggregate (if any) and/or electronic components and assemblies and sensor technology and/or material supply and/or injection-moulded parts handling appliance and/or the injection-moulded part.

8. Method according to one of Claims 1 to 7, wherein each of the registered behaviourally complete components contains relevant procedural, mechanical and other relevant knowledge in order to provide the functions required for each respective process in an organized form as commands, together with other components.

9. Method according to one of Claims 1 to 8, wherein each of the registered behaviourally complete components contains relevant procedural, mechanical and other relevant knowledge in order to ensure the protection of the machine part represented by the component, as well as its safe application.

10. Method according to one of Claims 1 to 9, wherein the operating parameters required for the production cycle are input by the user by means of a data-processing unit storing said operating parameters, while the control unit takes into account all physical possibilities as well as the possibilities determined by the design of the machine and the tool.

11. Method according to one of Claims 1 to 10, wherein each component provides control commands in the form of a command interface and features an event interface.

12. Method according to Claim 11, wherein the component is manipulated via the command interface to trigger one or multiple commands on other components working together with this component, if necessary.

13. Method according to one of Claims 11 or 12, wherein status modifications in components are released via the event interface in the form of adoptable events and can be used as a basis for synchronization directly between the components, and as synchronization sources for influencing the production cycle.

14. Method according to one of Claims 1 to 13, wherein the injection-moulded part is treated as a virtual component for the purpose of object orientation; characteristic values of the manufacturing process are assigned to the injection-moulded part, and the status of the injection-moulded parts is stored and used to influence the injection-moulding process; for example, to control a reject gate.

15. Method according to one of Claims 1 to 14, wherein any cyclic and/or non-cyclic processes within the area of the production cell are designed and executed on the basis of the component model.

16. Method according to one of Claims 1 to 15, wherein based on a representation of the production cell or parts thereof, in particular an injection-moulding machine, as an organized collection of components, processes are freely programmed on an input mask of the operator terminal.

17. Method according to one of Claims 1 to 16, wherein the production cycle, in particular the injection-moulding process, is designed in an interactive manner based on the commands of the physically present components, and comprises the following steps:

a) the control system offers all physically existing components as a selection;
b) the user selects the components required for the process in the sense of a pre-selection;
c) the user selects a command or an event source of a component and inputs the command or event source into the process;
d) this input is stored in the data-processing unit;
e) steps c) to d) are repeated until the process is complete;
while the parameterization of the commands, event sources and components involves the following steps:
f) selection of a command or an event source in the process and/or a component used;
g) display of the relevant parameters;
h) input of the parameters;
i) this input is stored in the data-processing unit;
j) steps f) to i) are repeated until all commands and event sources involved in the process or all components used have been parameterized.

Steps f) to i) can be carried out either after or during the creation of the process, until all commands, event sources and components used in the process have been parameterized.

18. Method according to one of Claims 1 to 17, wherein a pre-selection of components needed for the process is offered and/or made from an organized collection of components in an input mask.

19. Method according to one of Claims 1 to 18, wherein all equipment present at the respective production cell and/or assigned to it, such as peripheral devices and tools, are treated like components.

20. Method according to one of Claims 1 to 19, wherein prior to start of production, the machine cycles are interactively and graphically configured on an input mask and the operating parameters are entered in a command- and component-oriented manner and, if a matching, previously generated dataset exists, this dataset is preferably loaded.

21. Method according to one of Claims 1 to 20, wherein the configuration of a process is freely designed and, based on the component knowledge, when a command is inserted in the input mask, additional commands are automatically inserted into the cycle as blanks for the necessary follow-up steps and the user has to fill the blanks with concrete, suitable commands for the components involved from the component list of the input mask.

22. Method according to one of Claims 1 to 21, wherein the control system features an input mask containing a process list, a process representation field, a component list with selectable commands and, in addition, a parameterization field, and the user configures and parameterizes the process on the operating interface.

23. Method according to one of Claims 1 to 22, wherein the process representation field of the input mask continuously shows whether the parameterization for the commands used in the configured process is complete.

24. Method according to one of Claims 1 to 23, wherein the component list of the input mask continuously shows whether the parameterization for the commands used and/or designed in the configured process is complete.

25. Method according to one of Claims 1 to 24, wherein only values that are within a permissible range according to the component knowledge are accepted for the parameterization of the components and their commands.

26. Method according to one of Claims 1 to 25, wherein it can be seen from the process list which processes are incomplete, i.e. that these contain blanks and/or use components or commands with incomplete parameterization; those parameters that have not been entered are highlighted in the parameterization field and the component list shows those components - and the process representation field those commands - which have not been completely parameterized.

27. Method according to one of Claims 1 to 26, wherein parallel processes can be synchronized.

28. Method according to one of Claims 1 to 27, wherein the tool setter is provided with an expert system for the process design and for the parameterization.

29. Method according to one of Claims 1 to 28, wherein the determined ideal dataset is stored for all successfully executed production cycles and can be loaded by the user for identical or similar production cycles.

30. Device for controlling and operating a production cell for producing plastic injection-moulded parts with an injection-moulding machine with computing and storage tools, wherein the production cycle can be predefined and parameterized by the user via operator controls, and wherein the computing/storage tools are designed to hold a knowledge base, while at the operator controls, an image of at least part of the equipment existing at the respective production cell or assigned to it can be created in the form of behaviourally complete components in a domain model and machine cycles can be designed, managed and run by means of a domain language, so that the operation of a production cell is facilitated in an easy and consistent manner.

31. Device according to Claim 30, wherein the control unit is designed in a component-oriented manner, and at least part of the equipment existing in the production cell can be registered and taken into account as a behaviourally complete component and can be controlled via the relevant commands.

32. Device according to Claims 30 or 31, wherein an individual component represents any element of the injection-moulding machine or the equipment and peripheral devices assigned to it, such as the form closure, aggregate, core puller, handling device, etc., and purely logical components are also possible.

33. Device according to one of Claims 30 to 32, wherein each of the components taken into account features an event interface and a command interface, as well as its own internal component knowledge base.

34. Device according to one of Claims 30 to 33, wherein said device features a control infrastructure with an organized collection of virtual components matching the elements of the production cell, each with its own assigned knowledge base, and the production cell can be controlled in a component-oriented manner and the production cycle can be driven by the commands according to the configured process.

35. Device according to one of Claims 30 to 34, wherein each component contains relevant procedural, mechanical and other relevant knowledge to ensure the protection of the machine part represented by the component.

36. Device according to Claim 30, wherein the control, programming and configuration can be executed via the operating unit on the basis of a component-oriented domain language for modelling cyclic and/or non-cyclic machine processes based on a representation of the machine as an organized collection of components, and the computing/storage tools are designed to hold a locally organized knowledge base for the components.

37. Device according to Claim 36, wherein at least part of the equipment present at the respective production cell or assigned to it is registered and taken into account as components in the control unit and the components are displayed on the screen and/or operator terminal and can be used by the user as the basis for modelling any process.

38. Device according to Claim 37, wherein the operator terminal features an input mask containing a process list, a process representation field, a component list with selectable commands and, in addition, a parameterization field.

39. Method according to one of Claims 25 to 38, wherein the execution of a process is visualized, so that the status is visible at any time and conclusions about the cause of errors are facilitated, if errors occur.