Spiral bevel gears transmit motion between intersecting or offset shafts, and their tooth flanks are generated by a rotating cutter head while the workpiece is rolled relative to a virtual generating gear. The shape of the flank is therefore not set by a single feed or speed value but by a group of machine settings — cradle angle, roll ratio, horizontal and vertical wheel position — together with auxiliary values such as saddle infeed and withdrawal times, indexing time and cutter spindle speed. Every change of product, and often every change of cutting method for the same product, produces a new set of these values.
On a standard SINUMERIK Operate interface these settings are not exposed as an operator-level object. They live as R parameters inside the part program, so a change of product means locating and rewriting R variables in the NC code. For a shop running many gear variants on the same machine this is slow and error-prone: the operator must understand both the cutting process and the program structure, and a single mistyped R index propagates directly into the tooth form.
The alternative described here is to keep the standard CNC kernel and replace only the presentation and data-entry layer. A dedicated HMI holds the cutting settings in an editable parameter file, writes them into the system R variables, displays live machine values back to the operator, and generates the NC program from the parameter set. The operator enters gear-cutting data; the interface handles the mapping to the control.
Why an open control is the right platform
The SINUMERIK family is an open control system in the sense that the machine-tool builder can add its own operator dialogs to the standard HMI without modifying the CNC kernel. Selection between the 828D and 840D sl variants is driven mainly by the number of controlled axes required by the machine concept; both support the same configuration mechanism. The builder-side development environment for these dialogs is EasyXML, in which screens are described declaratively rather than compiled as a separate application.
This matters for a gear-cutting machine because the dialog content is process knowledge, not control knowledge. The gear design and cutting-adjustment calculations remain with the machine builder and can be revised without touching the CNC software stack, while the real-time execution, axis interpolation and R-parameter storage remain with the control.
Configuration file layout
An EasyXML project is a set of XML and bitmap files placed in fixed directories on the control’s System CF card, from which the system compiles the new interface at start-up. No separate build step or download of an executable is involved.
| Content | Location | Function |
|---|---|---|
Entry configuration (e.g. xmldial.xml) |
/System CF card/oem/sinumerik/hmi |
Compiled automatically at boot; declares the start-up screen and pulls in other dialogs through INCLUDE tags |
| Dialog XML files | /System CF card/oem/sinumerik/hmi/appl |
One file per screen: file management, editing, new file, process parameters, machining |
| Bitmaps (BMP or PNG) | /System CF card/oem/sinumerik/hmi/ico |
Start-up images and softkey icons referenced by the dialog files |
The xmldial.xml file acts as the root of the tree. Its INCLUDE tags bind the developer’s dialog windows into the CUSTOM operating area of SINUMERIK Operate, and each included file may in turn reference further XML files and bitmaps. Editors of any kind can be used to create the files, since the format is plain XML.
Functional decomposition of the gear-cutting interface
The interface is organised around three operator tasks rather than around control objects: entering the cutting process data, managing the files that hold that data, and running the job. A start-up screen provides the softkey navigation between them and carries the machine builder’s identification image.
| Module | Configuration file | Operator function |
|---|---|---|
| Start-up screen and navigation | xmldial.xml |
Defines the softkeys (process parameters, file management, machining), the start-up bitmap and the screen calls |
| File management | rcp_manage.xml |
Lists parameter files, reads the selected file and displays its contents, deletes files |
| File editing | recipe_modify.xml |
Same layout with editable fields; adds a Save softkey |
| New file | recipe_new1.xml |
Creates a parameter file, default name defaultpara.txt, pre-filled with the associated program’s parameters |
| Process parameters | canshu.xml |
Displays and writes the cutting adjustment values mapped to R parameters |
| Machining | jiagong.xml |
Shows current axis coordinates, cutter spindle speed and other run-time values |
The navigation itself is declared as a menu of softkeys, each with a bitmap icon, a caption and a target form. A start-up image is painted into a form by absolute position and size, in the same coordinate system used for every other control on the screen:
<menu name="main">
<open_form name="main_form"/>
<softkey POSITION="2" picture="f:/appl/ico/canshu.png">
<caption>Process%nparameters</caption>
<navigation>menu_rparameterform</navigation>
</softkey>
</menu>
<form name="main_form">
<paint>
<img xpos="0" ypos="23" width="620" height="400"
AspectRatioMode="Ignore" name="f:/appl/ico/jcmt_manufacture.jpg"/>
</paint>
</form>
<?include src="f:\appl\jiagong.xml" ?>Parameter files and file management
Each gear variant is stored as a plain semicolon-delimited text file. This is a deliberate choice: the files are human-readable, can be copied between machines, and can be regenerated by the builder’s gear design software. All four management operations are implemented with the file and string functions that the control exposes to the dialog layer.
| Operation | Implementation call | Effect |
|---|---|---|
| Read selected file | doc.readfromfile, then string.split on ";" |
Splits the record into a value list; individual fields are converted with type_cast to float for display |
| Edit and save | doc.writetofile with the current file path and the collected context |
Writes all edited fields back to the same file |
| Delete | doc.remove |
Removes the file identified by the current path |
| Create | Copy of the associated program’s parameters into defaultpara.txt |
Provides a valid starting point so the operator edits rather than types from scratch |
The read path illustrates how declarative binding and scripting combine. The file is loaded, split and cast inside a function body triggered when the form initialises, and the result is assigned to the variable bound to a read-only display field:
<function_body name="readpara_subfunc">
<function name="doc.readfromfile" return="paralist_readall">currentconfigfile_path</function>
<function name="string.split" return="paralist_splitname">
paralist_readall, _T";", value_num
</function>
<type_cast name="paralist_splitname[1]" type="float"/>
<op>sp_namevar0 = paralist_splitname[1]</op>
</function_body>Editing reuses the same window definition with one structural difference: the field type is switched from readonly to edit, and a Save softkey is bound to the write function. Keeping one layout for viewing and editing reduces the number of dialogs the operator has to learn, and the read-only/write distinction is enforced by the interface rather than by operator discipline.
Mapping cutting settings and machine status to R parameters
The link between the dialog layer and the cutting process is the R parameter. Each display field declares a reference variable in the control’s NCK address space; because the field is declared with hotlink="true", the control refreshes it cyclically without any polling code in the dialog.
| Quantity | Referenced variable | Display format |
|---|---|---|
| Roll ratio (process parameter screen) | nck/Channel/Parameter/R[153] |
%.0f, read-only |
| Cutter spindle speed | nck/Channel/Parameter/R[112] |
%6.3f, read-only |
| Axis position (first geometric axis) | nck/Channel/GeometricAxis/actProgPos[1] |
%6.3f, right-aligned, time="superfast" |
The form-level declaration <data_access type="true"/> permits the same screen to write as well as read, so the process parameter page serves both as a viewer for a stored gear variant and as the data source for a new program. Reading a roll ratio is expressed as a single control bound to R[153]:
<form name="R_PARAMETER_LIST">
<init>
<caption>Current process parameters</caption>
<data_access type="true"/>
<control name="c05" xpos="163" ypos="230"
refvar="nck/Channel/Parameter/R[153]"
hotlink="true" fieldtype="Readonly" format="%.0f"/>
</init>
<paint>
<text xpos="23" ypos="230">Roll ratio</text>
</paint>
</form>Axis positions and spindle speed on the machining screen follow the same pattern, with a faster refresh attribute assigned to the axis coordinate so that the displayed position tracks the slide during a cut. The operator therefore sees the values that matter during machining — X coordinate and cutter spindle speed among them — in one dedicated screen instead of navigating the standard diagnosis and machine areas.
From parameter set to NC program
The regeneration step closes the loop. When the operator presses the upload softkey on the process parameter screen, the control takes the R-parameter values currently displayed — cradle angle, roll ratio, horizontal and vertical wheel position, plus the auxiliary timing and speed values — and generates the NC part program for the gear to be cut. The parameter file remains the record of the job, and the R variables are the working copy that the program consumes.
This separation is what makes the interface usable across a product mix. A new gear variant requires a new parameter file, not a new dialog, and the operator never edits NC code. The failure mode of the standard interface — a wrong R index or a stale value left in the program — is removed because the values are entered once, in a labelled field, with the data type enforced by the configuration.
Deployment status and design observations
The EasyXML-based interface has moved past the prototype stage: it is used in commercial series production on the builder’s spiral bevel gear cutting machines, and operator feedback on the dedicated screens has been favourable. Several properties of the approach are worth noting for other machine builders considering the same route.
- Configuration, not programming. Screens, softkeys and data bindings are declared in XML; the only procedural code is short function bodies for file input/output and string handling.
- No kernel modification. The dialogs occupy the
CUSTOMoperating area, so standard SINUMERIK Operate functions remain available and control software updates do not invalidate the builder’s screens. - Fixed-geometry layout. Controls are positioned in absolute pixel coordinates with explicit width and height, and bitmaps must be supplied as BMP or PNG. Layout changes are therefore file edits and require a control restart to recompile, which favours a stable screen design agreed before commissioning.
- Refresh behaviour is a design variable. Cyclic binding through
hotlinkand thetimeattribute replaces manual polling, but the refresh rate has to be chosen per field: fast for axis position, slower for parameters that change only at setup.
The broader point is that a gear-cutting machine’s usability is set as much by the operator’s data path as by the CNC’s interpolation performance. Exposing the cutting adjustment parameters as named, typed, file-backed fields — and binding them directly to the R variables the part program reads — converts a program-editing task into a parameter-entry task, which is where the reduction in setup effort and operator error comes from.