RU75483U1 - SOFTWARE AND HARDWARE COMPLEX FOR MANAGEMENT PRECISION EQUIPMENT - Google Patents

Abstract

The utility model relates to the field of automation of production technological processes and can be mainly used in control systems for precision CNC machines and mechatronic modules. In a hardware-software complex, a numerical control system (CNC) is organized on a personal computer platform with a two-level architecture at the application level formed by: a group of modules 1 that implement applied control tasks using function blocks 2, as part of the mentioned group of modules 1; communication systems; functional means of scheduling and shared memory. The two-level architecture is formed on the basis of the same levels, in which the level of the CNC system as a whole and the level of any module 1 that implements a specific control task are executed as a virtual multiprocessor computer. The communication system is built in the form of a global server 3 with at least the following functions: configuration of the communication environment; control the type and content of sessions (i.e., transactions); control the selection of the type and group of the screen image; control the formatting of the transmitted data. The dispatching tool 4 is implemented as an independent (structurally allocated) component — a notification manager with subscription functions (i.e., service requests) of modules 1 for receiving and updating data and control commands. Each block 2 of the lower level is implemented similar to the general architecture of the CNC system and with similar functions, i.e., in the form of architectural control components tied to a local communication environment based on a local server 5 with a local structurally allocated notification manager and shared memory. 1 n.p. f-ly, 2 ill.

Description

The utility model relates to the field of automation of industrial technological processes and can be mainly used in control systems for precision CNC machines (numerical control) and mechatronic modules.

The next generation change significantly changes consumer properties, structure, architecture and software of numerical control systems (CNC). The principal features of the new generation CNC system such as PCNC (Personal Computer Numerical Control) are: using an open architecture, configuring the system with the equipment manufacturer and the end user, the evolution of the system in conditions of maximum independence from changes to the system platform; integration of software packages, access to information of any module, including diagnostic information of the control object; connection to an external network communication environment; use of system integration principles in the system architecture. Architecture at the application level is determined by the number and composition of application sections called control tasks. Among these tasks, we can mention: geometric (oriented to control follow-up drives); logical (organizing the management of electroautomatics), technological (guaranteeing the maintenance or optimization of process parameters); - terminal task (supporting dialogue with the operator, displaying system states, editing and verification of control programs); scheduling task (providing control of other tasks at the application level). The structure of the CNC system is a combination of basic modules and additional modules - commercial applications. The general structure is represented by the NC subsystem (Numerical

Control) and the PC subsystem (Personal Computer). The first forms an environment for CNC-oriented modules operating in real time, and for special user applications. The second subsystem forms the environment of a Windows-shaped user interface and includes an instrumental system for preparing and testing control programs, as well as other special applications. As the computing power of computers grows, the single-computer option becomes more attractive. The single-computer model uses a traditional computer equipped with additional controllers for communication with control objects. The Windows operating system is not a real-time system and therefore requires a corresponding extension; for example, in the form of the RTX 4.1 system of the American company VentureCom.

Architectural options give a general idea of the principles of open architecture in relation to CNC: a clear distinction between system, application and communication components; the possibility of independent development of any of them, both on the basis of original developments, and by embedding purchased software systems; client-server organization of interaction of subsystems, standardization of interfaces and transactions.

Five architectural options coexisting in the CNC market have been identified. Classic CNC systems (first option) are produced by firms with a rich tradition of producing their own high-quality microelectronic equipment. But they, under pressure from end users, offer a modification with a personal computer as a terminal (second option). For many reasons, the first systems such as PCNC belonged to a two-computer architecture (third option). Today they are popular and widespread. Later PCNC systems appeared, the core of which is implemented on a separate board installed in an industrial personal computer (fourth option). Finally as

increasing the power of microprocessors, a single-computer (fifth) version of the PCNC system is becoming more widespread.

Let us dwell in more detail on examples of PCNC-4 class systems (fifth option), which are of most interest today.

The Beckhoff CNC system (Germany) demonstrates an example of a single-computer architecture PCNC, within which all control tasks (geometric, logical, terminal) are solved purely by software. The external interface is based on a standard (optional) Fieldbus peripheral. Access to the objects is carried out using peripheral “terminals” of input-output.

The operating environment is a combination of the Windows operating system to support machine time processes and the TwinCat system (Total Windows Control and Automation Technology). The TwinCat operating system is integrated into Windows, adding real-time functions to it without changing Windows itself. At the application level, CNC program modules and programmable controllers with a client part (for data preparation) and a server part (for real-time operation) work in control flows.

When developing a new model of the CNC system, Siemens focused on an open architecture for the end user, both from the operator interface and from the system core. The operator interface works in the Windows operating system and allows inclusion of windows applications in the interface. However, a deeper interface reconfiguration is possible using the original ProTool tooling system. To expand the functions of the kernel, a scheme has been proposed according to which peculiar break-out-points called events are included in the kernel processes. Events trigger fragments of custom Visual C ++ code called here "compile cycles". Compiled loops have a unified OPI (OEM Program Interface), which provides them standard access to system data and functions through the "binding" binding mechanism

Closest to the claimed technical solution is a software and hardware complex for controlling precision equipment known from the prior art, the numerical program control system of which is organized on a personal computer platform with a two-level architecture at the application level, formed by: a group of modules that implement applied control tasks via functional blocks , as part of the mentioned group of modules; communication systems; functional means of dispatching and shared memory (see Sosonkin VL, Martinov GM "Principles of building CNC systems with an open architecture." - Instruments and control systems. 1996, No. 8, p. 18-21).

The disadvantages of this technical solution known from the prior art include the relatively low level of speed of the control system and, as a result, the relatively low productivity of the technical tool (control object) and the accuracy of the movement of its executive bodies insufficient for modern production.

The technical result of the claimed technical solution (objectively manifested by a software and hardware complex as a result of its direct participation in the work of a hardware under the control of the software installed on the said complex) is to increase the productivity of the equipment and the accuracy of the movement of its executive bodies as a result of increased speed of programmable modules of the same type and improve operational management equipment in e real time to maintain a predetermined process parameters and / or processing conditions.

The problem is solved by the fact that in the hardware-software complex for controlling precision equipment, a numerical control system (CNC)

organized on a personal computer platform with a two-level architecture at the application level, formed by: a group of modules that implement applied control tasks by means of functional blocks, as part of the mentioned group of modules; communication systems; according to the utility model, the two-level architecture is formed on the basis of the same levels in which the level of the CNC system as a whole and the level of any module that implements a specific control task are executed as a virtual multiprocessor computer; the communication system is built in the form of a global server with at least the following functions: configuration of the communication environment; management of the type and content of sessions, i.e., transactions; control the selection of the type and group of the screen image; control the formatting of the transmitted data; dispatching means is implemented as a notification manager with subscription functions (i.e., service requests) of modules for receiving and updating data and control commands; each lower-level unit is implemented similar to the general architecture of the CNC system and with similar functions, i.e., in the form of architectural control components tied to a local communication environment based on a local server with a local notification manager and shared memory.

The utility model is illustrated by the following graphic materials, where: Figure 1 - modular architectural system of CNC type PCNC and control tasks; Figure 2 - interface functions of an object-oriented highway (communication system in the form of a global server).

The CNC system of the hardware-software complex is organized on a personal computer platform with a two-level architecture at the application level, formed by: a group of modules 1 that implement applied control tasks using functional blocks 2, as part of the mentioned group of modules 1;

communication systems; functional means of scheduling and shared memory. The two-level architecture is formed on the basis of the same levels, in which the level of the CNC system as a whole and the level of any module 1 that implements a specific control task are executed as a virtual multiprocessor computer. The communication system is built in the form of a global server 3 with at least the following functions: configuration of the communication environment; control the type and content of sessions (i.e., transactions); control the selection of the type and group of the screen image; control the formatting of the transmitted data. The dispatching tool 4 is implemented as an independent (structurally allocated) component — a notification manager with subscription functions (i.e., service requests) of modules 1 for receiving and updating data and control commands. Each block 2 of the lower level is implemented similarly to the general architecture of the CNC system and with similar functions, i.e., in the form of architectural control components tied to a local communication environment based on a local server 5 with a local structured notification manager (Fig. 1 conditionally not shown) and shared memory.

The following describes in more detail the functional features of the claimed CNC system and the prospects for the development of its architecture.

Today, automated production involves those solutions that are based on a single product information model within its life cycle: from computer design (CAD) and computer planning (CAPP) to automated preparation of control programs (CAM) and manufacturing on CNC machines (NC) . A similar model is defined as part of the STEP suite of standards. The weak link in successive transitions along the stages of the life cycle is the transition CAM-NC. Programming modern CNC systems complies with ISO 6983 (DIN 66025).

The ISO 6983 standard (DIN 66025) supports the simplest commands for elementary movements and logical operations, but not

complex geometry and logic. However, more serious is the impossibility of two-way information exchange with CAD-CAM systems; which means that any changes in the control program cannot be displayed in the upstream information flow.

The STEP-NC standard offers a model of what needs to be done without details on how to make path movements and execute logical switching commands. This model meets the new standard ISO 14649, according to which: the product is obtained from the workpiece by removing the typical forms (features); by conditional or unconditional execution associated with typical forms of transitions (workingsteps); in the control flow specified by executables; with the necessary tolerances; using a tool that meets all the necessary requirements.

The ISO 14649 standard establishes the following Units of Functionality components: product (workpiece), type form (feature), executable block (executable), transition (operation), toolpath (toolpath), measurements (measures).

The product is described with the history of the version, with the information of the owner, with approvals, date, indicating the material and its properties. Typical forms define the area of the removed workpiece material, and their appearance is part of the appearance of the product. Typical forms are defined in a parametric form as a combination of a generator and a guide.

The core of the STEP-NC model is a workplan, which is a sequence of steps (workingsteps). Each step is associated with a transition in a typical product form. The transition contains a technological algorithm and instructions for the settings. An executable block describes the control flow and sequence of transitions associated with operations and sample forms.

The tool path sets the movement of the drives if the intelligent CNC system is not capable of planning such a path itself.

The control program is presented in the format of a physical file. The first section, the header, contains general information and comments. This is followed by the data section opened by the Data keyword: an operation plan, executable blocks, technological descriptions, geometric descriptions.

Using this format has a clear view and a clear environment. However, there are other proposals related to the direct use of EXPRESS and XML languages in NC control programs.

CNC systems focused on the use of STEP-NC can be represented by one of three options (types). The first option is a traditional CNC system, the control program of which in the ISO-14649 standard is transformed into the ISO-6983 format at the post-processing level. In the second version, the CNC system has a built-in interpreter of control programs in the ISO-14649 standard. The third option is the most qualified solution: the CNC system is built into the Internet and supports the ISO-14649 model, uniform in the CAD-CAM-CNC chain; Automated all functions from commissioning to measurement; The system has artificial intelligence.

Numerical control systems have modules operating on a machine time scale and real-time modules. Modules interact with each other and need scheduling. Moreover, dispatching problems are close to those that are solved by means of real-time operating systems; however, the dispatcher does not in any way replace the operating system.

Real-time systems, including the dispatcher module, are built on the basis of real-time operating systems (RTOS). Real-time executive systems offer different platforms for

development and execution of software. The real-time application part is developed on the host computer, then combined with the kernel and loaded into the control system as one task. This solution gives high accuracy and speed. An example is the VxWorks real-time operating system.

Management systems with a real-time UNIX operating system rewrite the core of a standard operating system with real-time requirements. Such systems support the entire set of UNIX applications. However, a UNIX system has a large volume and low reactivity. A typical and widely used member of the UNIX family is the non-profit Linux operating system.

Modern numerical control systems are increasingly using the Windows operating system with real-time extension. Windows is not a real-time system because: it does not have a sufficient range of thread priorities; it does not allow you to manage inheritance of priorities; thread synchronization mechanism and interrupt response time are unpredictable.

Meanwhile, due to the popularity of the Windows operating system in control systems, the problem must somehow be solved. A well-known approach is to expand (in the sense of real time) Windows. This may be the original development of the manufacturer of the control system, for example, WinCAT (Backhoff Industrie Electronic, Germany). Another option is to use a ready-made commercial extension, for example, VenturCom's RTX 4.1.

The real-time extension allows you to: quickly update the control system with the advent of new versions of Windows; implement the powerful application protection that Windows performs with the help of an independent HAL (Hardware Abstraction Level); it is easy to debug codes and use the capabilities of standard Microsoft mechanisms for information exchange between Windows and real-time tasks.

In such systems, the usual Win32 application interface for Windows works (for computer time); as well as additional application interfaces RTAPI and Win32 RT (Real Time, real-time interface). Additional application interfaces provide two real-time modes, hard and soft. This allows you to optimize the computing resources of the control system by dividing its functional tasks into three groups:

- critical tasks (frame interpolation, input-output, etc.) implemented in the RT-server process fall into hard real-time mode;

- in soft real-time mode, tasks related to real-time tasks (for example, frame interpretation) are solved; they are implemented in the Terminal process;

- in machine time mode, the rest of the standard standard application modules of the control system work (control program editor, built-in CAN system, processing process modeling system, etc.).

Traditionally, the communication environment of the CNC system is interpreted as a set of Application Programming Interface functions for exchanging data with the core of the CNC system, while the total number of API functions can reach several hundred. With this approach, a change in system architecture requires considerable development effort. Thus, the current situation is that the API defines some general interface for connecting modules in the CNC system, but does not support their integration.

The communication environment takes on the problem of integration and inter-module communication of the PCNC system. The "component" COM approach and well-known principles of system integration can be used in the development of individual modules of the CNC system and at the level of its macro design. The latter means that the problem of inter-module communication is solved in the same way as the problem of system integration. Object Oriented Trunk Can Serve

means of intermodular communication and a source of necessary intermodular services.

The backbone is a software (virtual) channel for data exchange between modules connected to the channel. An object-oriented backbone assumes the presence in its software of a set of objects that solve the problems of connecting modules, data transportation, etc. Figure 2 outlines four types of functions of an object-oriented backbone: data request functions, control functions, display functions, auxiliary functions.

The data request functions assume that there are different types of data in the PCMS system and the need for them is different. For example, data on the number and names of coordinate axes used on the machine is required once at the time of initialization of the PCNC system.

Data on the current state of the running process is needed constantly to make the right decisions. There are other options for requesting data. Therefore, the object-oriented highway provides five of their types: synchronous, asynchronous, synchronous by event, asynchronous by event, asynchronous circular request. The groups of the requested data roughly coincide with the groups of API functions.

The control functions can be divided into: channel control functions that open and close the channel; the functions of processes that control the progress of their implementation, including starting and stopping; on state management functions. If the request is related to the process of obtaining data from the source module (server) through the internal structure of the communication medium, the process of transferring and processing this data to the client module belongs to the group of data display functions.

There are also helper functions. They represent a single mechanism for converting and formatting data, processing

errors, exceptions for all modules connected to the object-oriented backbone.

The interaction of the modules of the RSMS system is client-server in nature. Transactions between the client module requesting the service and the server module providing the service are generalized according to their purpose.

A command is sent to the server to perform some action, for example, launching a control program. Such a command does not imply a response from the server. Another option: a request is sent to the server in order to obtain some data, for example, the values of the current coordinates. Such a request involves a response from the server.

Thus, in the data exchange procedure in the PCNC type CNC system, the request phase and the data display phase are highlighted. Manufacturers of CNC systems are responsible for providing an open structure in the first phase, and machine tool builders and end users have the capabilities of an open system to solve their special problems in the second phase. An object-oriented backbone is a communication medium for data exchange, but also a single server that provides services to any modules connected to it. Organization of transactions according to the type of synchronous, asynchronous and event sessions allows you to minimize traffic in the communication environment and optimally use processor resources.

The software for the CNC system at the application level consists of several fundamental sections called "CNC tasks". The most important of them is the geometric problem ("motion control"), which is present in all, without exception, CNC systems. It consists of three large modules: an interpreter of control programs, an interpolator, a control module for servo drives.

The interpreter translates the frames of the control program in the ISO-7bit code in order to represent the data in the input interpolator format. In the frame interpretation phase, the CNC system performs

equidistant calculations and calculations associated with the docking of equidistant circuits; Converts coordinate systems (in absolute or relative systems) and converts measurement systems (in millimeters or inches); calls standard loops and routines; Separates data flows of geometric, logical and other tasks. The best implementation of the interpreter is to build it like an ISO processor. This solution provides the greatest speed and flexibility of the PCNC system in relation to the command system, i.e. language version (code) ISO-7bit.

At the final stage of interpretation, the data arrives in a ring buffer (which allows analyzing for compatibility a group of neighboring frames with equidistant correction), and the final interpretation result is presented as an IPD code (Interpolator Data).

The tasks of the interpolation module are traditional. Recently, however, new demands have been made on the interpolator. Among them: reduction in price discrete in the drive to 0.5 microns or less; direct access to the drives, in which the movement in the frame is set in increments of the follower drive, which is necessary at especially high feed speeds; decomposition of complex movements into linear combinations of basic movements. Such requirements define a new (open) interpolator architecture in which individual blocks are clearly identified.

An open interpolator allows free extension of interpolation algorithms and their arbitrary combination when reproducing complex trajectories in multi-coordinate space (including using splines). The key to building an open interpolator is the right choice of input formats.

Consider an example of an interpolator that implements linear, circular, and spline interpolation, as well as their combinations. The interpolation module is connected to a common object-oriented highway of the CNC system. The interpolator interface provides: reception

interpolation parameters and operational signals for controlling the interpolator; outputting data on the state of the interpolation module.

The interpolator includes a certain set of blocks, its own internal bus and administrator. The frames of the control program are transmitted to the input of the translator in IPD format, converted to the internal format of the interpolator, processed in the Look Ahead frame-ahead block (in order to smooth the feed rate), and stored in a ring buffer. The translator generates messages in which the interpolation parameters are packed. Messages are addressed to certain blocks of the interpolator and can be main and additional. The main messages contain the data necessary for the addressed blocks, and the additional messages contain data on movements along the coordinate axes. Thus, the main messages initialize the blocks that should be involved in the interpolator when processing the control program block, and with the help of additional messages, the coordinate axes participating in the interpolation are initialized.

The internal interpolator bus is a “fast process bus” and links all the blocks together. It is implemented on the basis of an object-oriented approach and is connected to the main object-oriented bus of the CNC system with the help of an administrator. Blocks involved in working out the current frame are assigned using a special code. This code is initialized in the translator and passed to the administrator.

After broadcasting, several interpolation blocks from different or identical groups can be involved in a single frame. For example, when playing a helix on a machine, a linear acceleration-braking unit, a circular interpolation unit, a linear interpolation unit and a feed drive control unit will be included. When machining parts on five - six-coordinate machines, the simultaneous operation of several circular and linear or spline interpolators is possible.

This coding scheme provides flexibility and openness of the interpolator. It becomes possible to build an administrator that is invariant to the composition and number of interpolator blocks.

The purpose of the Look Ahead block of look-ahead viewing is:

- in determining the conditional time of the frame in the interpolator cycles for the subsequent correction of the contour speed;

- in the analysis in each frame of the basic motion parameters (the contour velocity vector at the beginning of the frame and at the end of the frame, the speed along the additional coordinate axes, the path in the main coordinate system, the radius of curvature of the motion path).

As a result of its operation, the Look Ahead block determines the speed at the end of the frame (final speed), the new value of the contour feedrate.

The general scheme of operation of the interpolator is as follows. After providing a quantum of processor time, the administrator (built according to the scheme of the firmware) sends a request to the translator to receive the codes of the interpolator blocks that should be started. After receiving the codes, the administrator starts the blocks in the order of their priorities; moreover, before each start it installs one of the following commands: “LOAD”, “OPERATING TACT”, “FINAL TACT”, “EMERGENCY BRAKING”, “INTERPOLATOR STOP”, “INTERPOLATOR RESET”, “INTERPOLATOR START”.

The list of commands can be changed and expanded by reprogramming the administrator. The process of loading a new frame coincides with the final cycle of interpolation of the previous frame. The final step of the interpolation consists in reaching the end point of the trajectory and does not require any complicated calculations. By the “WORKING TACT” command, each of the interpolators makes a request to the acceleration-braking unit and receives from it the value of the path increment, which must be passed along the contour in the interpolation cycle. The acceleration-braking unit starts earlier than the interpolators, since it has a higher priority. The SUMMATOR block forms the total

increments of the path from the individual components and issues them to the feed drives. In addition, the adder accumulates the absolute values of the coordinates and stores them throughout the entire operation time. By the command "SET FIXED POINT", the adder initializes the absolute coordinates. In the same block, the algorithm for correcting the errors of the lead screws also works.

Implementation of a logical task based on software-implemented (virtual) SoftPLC controllers

The technology for creating electric automation software based on software-implemented controllers is based on the concepts of class and object that are common for object-oriented programming. In this case, the class describes the type of equipment, and the object describes a specific instance. When a class is declared, data structure templates and methods are created that will work with this data. In the class object, specific data is built according to the template, and a link to the process serving them is provided.

When developing a control system for a new type of equipment, the developer does not need to re-develop a new class: it is enough for him to choose the closest class and realize the differences. This ensures the simplicity of modifications, reduces the time spent on development, reduces the total cost of development.

In the CNC system, the virtual controller runs under the Windows NT operating system with the VentureCom Real Time Extension (RTX). The design of the controller involves the sequential consideration of its model at three levels of abstraction: at the level of the model (structure) of flows, at the level of functional modules and at the level of software implementation.

Consider the structure of flows. The controller's task is to execute several commands simultaneously and to process external signals in parallel. Each controller process that

needs to be allocated a separate thread; it is performed as part of the main process of a virtual controller running under RTX.

The processor time allocated by the operating system to the main process must be distributed between threads.

We use the idea of pseudo-multithreading based on the mechanism of quantum extraction (time sharing). CPU time is allocated to streams in quanta, using the internal mechanisms of the controller. In each quantum, one thread is executed. All threads are divided into groups by priority. Group management is carried out by a separate software timer. The program timer is similar to the system timer implemented in the operating system, but does not generate interrupts. Its handler is launched by the scheduler (synchronization module). The selection of several groups of flows in the virtual controller is due to the fact that its various tasks require different reaction times to external influences: the shorter the reaction time, the higher the priority of the thread serving the task.

A higher priority stream means a higher frequency allocation time slices. Different frequencies are supported in the system by several timers, each of which is activated at its own frequency and allocates time slices to its flows. The synchronization module performs synchronized activation of timers.

The virtual controller has five components (modules):

- An analyzer that reads IPD data from the input buffer, converts this data into the internal format of the virtual controller, taking into account the input and output registers of the electric automation;

- a synchronizer supporting a mechanism for assigning time slices, generating clock signals for all processes of a virtual controller;

- executable modules used to work out the commands received by the virtual controller, such as: interrogating emergency stop sensors and limit switches, turning on / off the feed

coolant, clamping / unloading of the chuck, start / stop of the spindle, interrogation of temperature sensors, etc.

- a register used to exchange information between the CNC system and the virtual controller;

- a gateway designed to display information transmitted over the CAN trunk to the register.

Data exchange between the controller and the CNC system is carried out through a shared memory "register". The input and output data blocks are designed for two-way exchange with the control object: the controller reads information from the input data block and writes information to the output data block. Information is transferred between the register and the CAN trunk through a gateway.

Objects are instances of classes that describe the electrical automation of a CNC system. Within the modular architecture of the virtual controller, each individual class is responsible for its own control object on the machine. So, the CNcSpindle class is responsible for managing the spindle; class CNcClnt is responsible for controlling the supply of cutting fluid, etc.

Thanks to the modular architecture, the virtual controller has a high degree of flexibility that allows it to be used on machines of various groups and types. The configuration of the controller for a given type of machine, during its initialization, consists in creating a set of related objects that reproduces the configuration of the machine. For example, if there are two spindles in the machine, then two objects of the CNcSpindle class will be created, etc.

When creating objects, they are interconnected.

The idea of building a SoftPLC virtual controller based on a personal computer is extremely fruitful and promising. There is very little information on how to build the core of such a controller. Thanks to the object approach, it is possible to achieve a high degree of visibility of the system, reduce the time spent on development

software and simplify the debugging process. The SoftPLC virtual controller has a modular architecture in which a separate class is responsible for its control object on the machine; because of this, the virtual controller has a high degree of flexibility that allows it to be used for machines of various groups and types. The main task of the SoftPLC virtual controller, which consists in the simultaneous execution of several control commands and in parallel processing of external signals in real time, was solved using the idea of pseudo-multithreading. This idea uses a time-sharing mechanism (quantum allocation), as well as an additional opportunity to work with priorities. It was proposed to use shared memory for information exchange with hardware and between some objects of the virtual controller.

The implementation of the terminal task.

The terminal task as part of the CNC mathematical software is of particular importance, since it presents the control functionality to the end user. "Filling" the terminal task determines the attractiveness and competitiveness of the CNC system in the market. The properties of an open CNC system are developed as far as the terminal task lends itself to configuration and expansion. The most important sections of the terminal task are: an operator dialogue interpreter in the Windows interface, an editor of control programs in ISO-7bit code, a debug editor of control programs in a high-level language.

Modern control systems have wide capabilities for organizing the Man-Machine Interface (MMI) in Windows operating environments. The terminal management task usually reduces to the problem of building MMI. Designing an MMI application involves: creating an application skeleton; implementation of screens; development of a dialogue interpreter; the organization

information sessions (transactions) with other modules of the control system. The stage of developing a dialogue interpreter is the most complicated.

Among the dialogue functions can be identified: obtaining information about the management process; system and facility testing; editing and modeling of the control program; manual input and control of data mining; program entry and automatic control; management of commissioning operations. The dialog sets the permissible transitions between the states of the MMI application, within which the necessary functions are reproduced. The operator of the control system sets the transitions between states using the hardware and functional keyboard; moreover, the role of the latter prevails.

The basic window (frame window) of an MMI application consists of three components: a status window (StatusBar), a work area, and a functional keyboard area (ToolBar).

The working area of the base window is covered with panel windows with frames and headers; each panel provides functionally uniform information. The panel, in turn, contains control elements (control elements), which are designed to dynamically display data coming from the server or entered by the operator using the keyboard. Control elements can be selected at the screen design stage from the standard library or can be designed in accordance with customer requirements.

The status window in the same way consists of panels with control elements: specific (pictograms of modes and sub-modes, readiness indicators, indicators of used system resources, date and time indicators) or general (the same as in the work area, for tracking for information closed when changing the picture of the workspace).

The functional keyboard area is represented by buttons, each of which is a control element with a dynamic name. All buttons can be: in standby,

when they are available to the operator ("unpressed" state); in a state of work under the influence of the operator ("pressed" state); in a locked state when they are absent in the area of the functional keyboard or when the operator’s influence on them is ignored (“locked” state).

The structure of the dialogue in a flexible control system with an open architecture is determined by the customer of the CNC system, for which the tree of modes and sub-modes serves as the usual language for the external description of the dialogue. The branches of the tree are assigned the names of the buttons on the functional keyboard.

Thus, the course of the dialogue is a sequence of the following events: keystroke by the operator and the generation of a scan code; appeal to the object with a request for a service (or services); sales of services by the facility; waiting for next operator actions. This chain is called a sequence of acts, among which there are input (keystrokes) and output (all others). Output acts are generated as a result of interpretation of input. Consequently, the dialogue interpreter is a sequential service call mechanism in accordance with the actions of the operator, expressed in pressing a key. In addition to calling services, the interpreter parses the operator’s actions.

To the editor of control programs, first of all, they are presented with standard requirements typical for a text editor: entering and editing text, scrolling and turning pages; Transition, contextual search and replace operations block operations of marking, deleting, copying, moving, loading and adding blocks. Secondly, there are specific requirements: renumbering after removal-inclusion of personnel; change of scale and dimension; output active G-functions (G-vectors) based on the history of the frame; syntactic and semantic control; interactive (graphic) input of the frame and parameters of standard cycles (graphic help files

are part of the configuration file); creation of control programs in training mode.

Tools for debugging programs include: spatial graphical modeling of the tool path for fast and working movements; Active use of break points scaling a graphic image (zooming); support for various image modes (step-by-step, automatic, between breakpoints, etc.); modeling the rest of the program. Such capabilities require the inclusion of some kernel and additional subsystems in the editor: an interpreter for control programs (for any version of the ISO-7bit code), an interpolator simulator for drawing trajectories.

Due to the variety of versions of the control program language in the ISO-7bit format, there is a need for an editor that can be configured for a specific version of it. The configurator formalizes the ISO7-bit code by highlighting several levels of abstraction in it. At the first level, the system of commands (G-functions) and the parameters of each command are determined. The next level divides the command system into groups according to the functional purpose of the G-functions and forms the G-vector of active commands. The last level of abstraction assigns lists of delimiters, comments, axis names and addresses, G-function names.

The editor of control programs has an architecture open to end users, open to developers of the editor itself, open to external applications. For end users, this primarily means the ability to configure to different versions of the ISO-7bit language using a configuration file that has a text format. Further, it is possible to configure a user interface, including a contextual prompt system and a help system, using a text initialization file and corresponding dynamic resource libraries.

Among the high-level languages of control programs, AnlogC (firms Andron, Germany), CPL (Bosch firms,

Germany) and many others. Regardless of the version, the structures of all languages are the same: there is a main program and a set of routines. The body of the program contains a list of variables that change values during the course of the program. The execution process is accompanied by informational messages, warnings, error messages.

On the screen of the editor-debugger in the program window displays its text. Here you can set breakpoints (breakpoints), implement a step-by-step or automatic start of the program. Variables (or arrays of variables) are presented in a separate window in the form of a tree, which allows you to select those of them whose values you need to monitor. The current values of the selected variables (or arrays) are shown in another window, and these values can be edited. The hierarchy of the called routines is shown as a tree in a separate window. The stack window shows the routines called to the current moment. The OutputWin window is used to display information whose type is determined by a certain set of icons. Pictograms are also intended to display the properties of files of called routines.

These windows are among the basic and are constantly present on the screen. Windows with supporting information (for example, a list of breakpoints) are implemented as pop-ups. The main and auxiliary windows of the editor-debugger form an ActiveX control element.

Concluding the consideration of the terminal problem, we can say the following. The terminal task is one of the most complex and most critical sections of the CNC system. Its "skeleton" is the operator dialog interpreter in the Windows interface. For editing, debugging and modeling control programs, two types of configurable applications are used, for control programs of low and high level, respectively.

Implementation of the diagnostic management task.

The most advanced CNC systems have a separate diagnostic mode, which is implemented in the form of a hardware-software complex and is focused on testing and in-depth study of the logical and geometric control problems. Diagnostics, as a rule, is carried out "out of real time"; which means: measurements are stored in memory and then analyzed. The diagnostic subsystem is capable of configuring measurements, reading measured signals, storing measurement results together with measurement configuration results, printing measurement oscillograms, reading files with measurement results and measurement configuration results, and performing various operations on the measured signals. The Logic Analyzer is used to diagnose the logical control problem, and the Oscilloscope is used to diagnose the geometric problem.

The structure of the diagnostic subsystem.

The diagnostic subsystem is built like a virtual machine and has a multi-level structure. The lower level is represented by computer equipment, which is a physical source of measuring signals; here, in particular, there can be a programmable controller, a control board for servo drives, etc. Above are the I / O device drivers that are part of the operating system. Access to the services of input-output devices is carried out through a layer of base classes that implement data exchange with the diagnostic subsystem, their formatting and control. On top are second-level classes that start and control the measurement processes. The COM Server level (Component Object Model), standardizes access to the diagnostic subsystem, on the one hand, and supports a distributed model of the measurement system, on the other hand. The third or fifth levels build an object model of a subsystem

Diagnostics that facilitate the creation and maintenance of custom applications. A virtual diagnostic device (at the sixth level) is intended for operator access to the measurement results.

The virtual diagnostic device is connected to the interfaces of the COM-server for diagnostics; it is tied to the format (type) of the interfaces, and not to the implementation of the COM server itself. This allows the use of a virtual diagnostic device in different control systems.

Logic analyzer implementation.

Electro-automation of mechatronic systems is quite complex and requires highly qualified specialists in the commissioning and commissioning of equipment. Such specialists are usually located in remote service bureaus and are engaged in remote analysis of the input and output signals of the programmable controller using the same virtual device, having the configuration and measurement results.

The distributed architecture of the diagnostic subsystem is focused on working with both external programmable controllers and built-in control systems.

The measured data can be read and displayed by the ActiveX Logic Analyzer. When viewing the displayed signals, you can scale, compare with each other, etc.

Oscilloscope implementation.

The optimal adjustment of the controllers of the servo feed drives is impossible without a careful analysis of their dynamic characteristics using the Oscilloscope diagnostic subsystem. A feature of the distributed architecture of the Oscilloscope is the use of the "process-COM server", which contains all the operations on the signals, regardless of the source device of these signals. Among the possible operations on signals: scaling, shift, any mathematical calculations.

The oscilloscope operates in two modes, the measurement configuration mode and the display mode of the measurement data in text and graphical form. The oscilloscope has the ability to visually configure properties: colors, fonts, signal image styles.

Modern control systems have free computing resources that should be used most efficiently. In this sense, the creation and development of the diagnostic subsystem is of most interest. First of all, it is necessary to diagnose the logical and geometric control problems.

Development of complex standard cycles for CNC machines.

Reducing the development time of control programs has always remained relevant from the very beginning of the use of CNC machines. One of the options for such a reduction is an attempt to build a control program only from standard cycles with parametric tuning. At the same time, traditional simple cycles cannot be dispensed with.

The task of automating routine operations of machining parts is constantly in the field of view of machine builders. Solutions based on automatic machines do not provide the necessary flexibility; and only the use of machine tools with numerical control (CNC) allows us to talk about flexible and quickly reconfigurable production. Having got rid of routine operations at the level of mechanical control of equipment, we got no less routine at the level of software automation of this control.

Depending on the technological features of the use of CNC equipment, the complexity of software development is manifested both at the production preparation level and at the workshop operational management level. At the first level, the problem is solved

by creating (using) CNC automated programming systems and integrating such systems with automated product design systems. At the second level, one of the ways to increase the efficiency of operational control of CNC equipment is the widespread use of standard cycles. Further, standard cycles are considered as elements of the built-in mathematical software of the CNC that are directly accessible during the operational control of machines.

Complex standard cycles.

In the operational control of CNC machines, the built-in standard processing cycles of typical elements of the part shape are widely used. Standard cycles for drilling, tapping, grooving, etc. are widely known. All of them are quite simple to develop and use. Simple geometry and a small number of parameters allow you to design such cycles using standard development tools for control programs.

Attempts to create more complex standard cycles face a number of serious difficulties. Let us consider some of them using the example of a universal cycle of turning a groove of arbitrary shape.

A large number of cycle parameters gives rise to many possible combinations and complicates the development and testing process. The complex path of the tool is due to the fact that the cutting point is offset from the tool anchor point. The nature and magnitude of this displacement depend both on the geometric parameters of the tool and groove, and on the current section of the machining path, i.e. the cutting point floats relative to the calculated anchor point. For this reason, the final tool path differs markedly from the original contour. As a rule, roughing and

fair passages. It should be borne in mind that the finishing allowance can change not only the size, but also the shape of the groove; for example, chamfers and radii may be overlapped with an allowance. The need for oscillating movements of the cutter to select the bulk of the metal further complicates the tool path.

As a rule, the inherent capabilities of CNC systems to develop and debug control programs are quite limited. Traditional control languages are closer to assembler than to high-level languages. Therefore, it seems impossible to implement complex standard cycles using only the means of the CNC system itself.

The implementation of complex cycles.

It is supposed to use development tools. The creation of such tools requires a lot of effort and cost; therefore, we used a ready-made graphical environment that allows you to: display trial versions of cycles; view cycles at any scale; use special windows of current coordinates to track the current position of anchor points and cutting points, etc.

It is necessary to be able to write control programs in a higher level language, in comparison with traditional control program languages. In this case, it is supposed to use a postprocessor to generate a traditional control program from a program written in a high-level language.

As a toolkit, the visualization environment for design solutions was used. The choice of this environment is explained by the fact that it is widespread, has a built-in Visual Basic language, allows you to visualize real trajectories and positions of anchor points at any scale; has built-in measuring tools

coordinates; It has convenient tools for debugging programs and can serve as a practically ready development environment.

To develop NC programs, the following have been added:

- visualization modules for trial solutions written in Visual Basic;

- a converter for converting the received decisions into the NC control program.

In practice, the process of creating a loop is as follows.

- We are developing a control program in the language of Visual Basic.

- Visualize the resulting solution and check it for different parameters of the cycle.

- We convert the worked-out solution into a traditional control program (with comments in the form of lines in the Visual Basic language to facilitate understanding and further maintenance of the control program).

The following are fragments of the source program in Visual Basic and the NC control program.

Snippet code snippet

If tmp_flag <> 0 And (flagF3 = 0) Then

wDD_rsum = wDD_rsum + (wR3F3 + RS) * (1-Cos (AA))

tmp_val = 2 * (wR3F3 + RS) -wDD_rsum

dzr = Sqr (tmp_val * wDD_rsum)

zr = zK3R- (BS-RS)

End if

Fragment of the generated control program

(If tmp_flag <> 0 And [flagF3 = 0] Then)

# 123: = # 130 * [# 220 == 0]

(wDD_rsum = wDD_rsum + [wR3F3 + RS] * [1-Cos [AA]])

// # 123 # 129: = # 129 + [# 102 + # 205] * [1-COS [# 229]]

(tmp_val = 2 * [wR3F3 + RS] -wDD_rsum)

// # 123 # 77: = 2 * [# 102 + # 205] - # 129

(dzr = Sqr [tmp_val * wDD_rsum])

// # 123 # 126: = SQRT [# 77 * # 129]

(zr = zK3R- [BS-RS])

// # 123 # 127: = # 26 - [# 222- # 205]

This solution was used to build a standard grooving cycle with many parameters, as well as other similar standard cycles (grooves, grooves, etc.).

As is known, the CNC device pre-forms control program blocks in a buffer for their subsequent interpolation. By the time the tool moves, the interpreter of the control programs must perform all the necessary calculations (for complex standard cycles, they may require a lot) and synchronize with the interpolator of the CNC system. This means that the synchronization points of the interpreter and interpolator must be present in the control program. Incorrect arrangement of synchronization points leads to the fact that the interpreter runs through the necessary point, which leads to incorrect results even with a logically correct algorithm for moving the tool.

The approach used to write control programs for complex standard cycles has completely proven its worth in terms of

practical use, and in terms of prototyping a specialized system that allows you to work out a methodology for writing complex standard cycles and determine the technical requirements for more developed specialized systems.

Thus, the claimed technical solution can find wide application in the field of mechanical engineering for the automation of production processes, mainly in control systems for precision CNC machines and mechatronic modules.

Claims (1)

A hardware-software complex for controlling precision equipment, the numerical control system (CNC) of which is organized on a personal computer platform with a two-level architecture at the application level, formed by: a group of modules that implement applied control tasks through functional blocks as part of the mentioned group of modules; communication systems; functional means of scheduling and shared memory, characterized in that the two-level architecture is formed on the basis of the same levels, in which the level of the CNC system as a whole and the level of any module that implements a specific control task are executed as a virtual multiprocessor computer; the communication system is built in the form of a global server with at least the following functions: configuration of the communication environment; management of the type and content of sessions, i.e., transactions; control the selection of the type and group of the screen image; control the formatting of the transmitted data; dispatching tool is implemented as a notification manager with subscription functions, i.e. service requests, modules for receiving and updating data and control commands; each block of the lower level is implemented similar to the general architecture of the CNC system and with similar functions, i.e. in the form of architectural management components tied to a local communication environment based on a local server with a local notification manager and shared memory.