1.1 Problem Statement

The problem being addressed here is the one stated in Section 4.3 of the DSR

Machine Control Events may vary significantly from controller to controller. The variations pose problems because there is a predefined set of Machine Control Events in UG and the data contained by these events is also fixed. Following are some of the problems

If a Machine Control Event does not exist in the UG predefined set then the Event will have to be specified as text in a certain format so that it can be interpreted during the post processing time.
A Machine Control Event present in the UG predefined set might not have the same data requirements of the Machine Control Event for a particular controller. Even in this case the Event will have to be specified as text in a certain format so that it can be interpreted during the post processing time.
Adding each and every event understood by each and every controller into the UG predefined list is not a practical option.

1.2 Project Description

This project proposes to provide a general mechanism to define the structure of any Machine Control Event such that UG can present the Event as per the structure definition.
UG will save the Event structure definition and the data.
The same mechanism will be used to define the currently defined set of Machine Control Events present in UG.
The presentation of the Events within interactive UG will continue to be the same as before.

1.3 Project Scope

This project will provide a general mechanism by which the structure of Machine Control Events is user definable. These Events will than be presented during the specification of the Start of Path, End of Path and In Path Machine Control Event sets. The description of the Event structure and the data associated with the Events will be stored in UG and will be output during post processing appropriately.
Additional functionality will be provided to make the Start of Path Machine Control Events and the End of Path Machine Control Events independent of Path Generation so that any changes to these Events will not require the regeneration of the Path.
The Machine Control Events associated with boundary elements( In Path Machine Control Events )will also be independent of path generation in some situations while other situations will require path regeneration for updating of the Event information.
The output of specific Events at specific positions by the tool path generation processors will continue to work the same.

2.0 Functional Description

Defining the context in which machining is to be done is a really important part in the process of machining. The description of the Machine tool being used and the constraints that have to be adhered to are a part of defining the context of machining. The type of Machine Control Events to be used are usually dictated by the Machine Tool Controllers that are being used. So the most logical place for describing the Machine Control Events would be where the Machine Tool and the Controller are described. The definition of the structure of the Machine Control Events will be made as a part of the Machine definition file.

The main steps involved in the use of Machine Control Events are

Defining the Event structure.
Defining the data of the Event to be used in operations.
Interpreting the Events when they are output.

The defining of the Event structure is done as a part of defining the overall context in which machining has to take place. Because the Machine definition file has the capability of inheritance the Events that have been specified as a part of the definition of -one machine can be inherited by other machines which use this definition.

Using the Event's structure description the Event will be presented wherever required during the specification of the operation parameters. When data has been specified for the Events the description and the data of the Event is stored.

When the operations are posted the Machine Control Events specified for that operation will be output in a generic manner so that the interpretation of the Events will be simple.

2.0.1 Machine Control Event Structure Definition

The Machine Control Events will be defined using a language whose syntax is specified by UG. The syntax for the language will be as follows:

EVENT <name

{

POST_EVENT <post_name

UI_LABEL <ui_name

CLASS Type, subtype, subtype; Type, subtype, subtype;

PARAM <param_name1

{

TYPE i | d | s | o | p

DEFVAL <default value as string

TOGGLE Off | On

OPTIONS <string1, string2, string3.......

UI_LABEL <ui_name

}

PARAM <param_name2

PARAM <param_name3

}

All the words appearing in uppercase are keywords as understood by the language. An EVENT can have many PARAM's and the description of all the attibutes if as follows

EVENT <name defines the event of name "name"

POST_EVENT <post_name specifies that the Event of name "name" will be output to the Post Processor as an Event with name "post_name". This attribute of the EVENT is optional and if not specified the event will be output to the Post Processor as an Event with name "name".

UI_LABEL <ui_name specifies that "ui_name" will be the string used in the title of the dialog presented to define the event. This attribute of the EVENT is optional and if not specified the event name itself is used as the "ui_name".

CLASS attribute specifies the domain in which the EVENT is valid. The Type and subtype get the same meaning as in the context of Templates. This is an optional attribute and when not specified implies that the EVENT is valid for all Types and subtypes.

CATEGORY attribute specifies the Machining Mode in which the Event is relevant. This attribute is optional. The possible values it can have are

Mill - Relevant in all milling operations

Drill - Relevant in Drilling operations

Lathe - Relevant in all Lathe operations

WEDM - Relevant in Wire EDM operations

The Event can be specified to be relevant in more than one Machining Mode. When this attribute is not specified the Event becomes relevant in all Machining Modes.

NOTE: If the CLASS and the CATEGORY attribute are both specified then the Event is relevant in only those situations which satisfy both requirements.

PARAM <param_name1 specifies a parameter of the Event. The parameter has a name "param_name1".

TYPE is an attribute of the parameter and specifies what the type of the parameter is. The possible values for TYPE are

i - an integer

d - a real number

s - a string

o - one of a possible set of options

p - a point

DEFVAL <default value as a string specifies the default value that the parameter can have. This is an optional attibute and if not specified the following will be the defaults according to the TYPE of the parameter

i - default value is 0

d - default value is 0.0

s - default value is an empty string

o - default value is the first one of the list of options provided

p - default value does not apply

TOGGLE is an attibute of the parameter which specifies that the parameter may be optionally defined and that the default value is either On or Off. The TOGGLE attribute is optional and if not specified the parameter is mandatory.

OPTIONS is an attribute of the parameter which applies only when the TYPE of the parameter is 'o'. This is a mandatory attribute when the TYPE is 'o'. This provides all the possible values that the parameter can have. The values are specified as comma separated strings.

UI_LABEL <ui_name specifies that "ui_name" will be the string that will appear in the dialog presented to define the event. This is an optional attribute and if not specified the "param_name1" itself is used as the "ui_name".

The definition of the Events will be done in a .cdl file. The file can contain as many Events as desired. This file is specified as a part of the Machine Definition.

2.0.2 Definition of Data for the Events

The Event structures that have been defined in the Machine definition will be the basis for the Available list of Machine Control Events that are presented during the specification of the Start of Path, End of Path and In Path Machine Control Events. All the Events will be presented at all times( Start of Path, End of Path and In Path) and there will be nothing to categorize the Events as being available only for certain situations.

When one of the possible Events is picked to be defined then the data for the Event can be specified for all the parameters of the Event and it will be stored in the UG part file. The various locations in UG where Machine Control Events could be specified will continue to be the same.

2.0.3 Interpreting Events during Output

During the posting of an operation the Machine Control Events specified in the operation will be output as Events with the specified POST_EVENT name. The variables loaded for that Event will be variables whose names will be the name of the parameters and the values of the variables will be the values of the parameters. In case the parameter is of TYPE 'p' the variable will be an array of size 3.

2.0.4 System Machine Control Events

There are some Machine Control Evens which have special significance to the tool path generation processors of UG. These will be termed System Machine Control Events. Among these Events there are some Events whose parameters are set by the tool path generation processors which we term Dependent System Events, while there are others which are output as is at particular locations in the tool path by the tool path generation processors, which we term Independent System Events.

2.0.4.1 Dependent System Events

The following are the Dependent System Events in which certain parameters will be set by the tool path generation processors.

Delay Event

Cutcom Event

Spindle On Event

Coolant On Event

There are two possible ways of handling the definition of the structure of these Events. They are

Provide a UG definition for their structure and disallow the user definition of any Events with this name.
Allow the user definition of the structure for these Events but document the names of the parameters that are set by the tool path generation processors and make it mandatory for these parameters to be specified along with any other parameters that may be specified.

These Events will appear in the Available list automatically whether they have been specified in the .cdl file or not

2.0.4.2 Independent System Events

The following are the Independent System Events in which are output as is will be set by the tool path generation processors.

Spindle Off Event

Coolant Off Event

Opstop Event

Opskip On Event

Opskip Off Event

There are two possible ways of handling the definition of the structure of these Events. They are

Provide a UG definition for their structure and disallow the user definition of any Events with this name.
Provide a UG definition for their structure and allow the user definition of any Events with this name to override the default UG definition.

These Events will appear in the Available list automatically whether they have been specified in the .cdl file or not.

2.0.5 Placement Markers

Placement Markers are special Events that will enable the grouping of Machine Control Events to be output at particular points in the Tool Path. Different Markers will be relevant when specifying Start of Path and End of Path Events.

The Markers relevant when defining Start of Path Events are

FROM Marker - This Marker is for specifying the output of Events relative to the FROM Point. All Events placed prior to the FROM Marker will be output just before the FROM Point is output and Events placed after the FROM Marker will be output after the From Point has been output.

NOTE: The FROM Marker will not have any significance if the FROM Point has not been defined.

START Marker - This Marker is for specifying the output of Events relative to the START Point. All Events placed prior to the START Marker will be output just before the STARTPoint is output and Events placed after the START Marker will be output after the START Point has been output.

NOTE: The START Marker will not have any significance if the START Point has not been defined.

APPROACH Marker - This Marker is for specifying the output of Events relative to the final APPROACH move. All Events placed prior to the APPROACH Marker will be output just before the final APPROACH move is output and Events placed after the APPROACH Marker will be output after the inal APPROACH move has been output.

The Markers relevant when defining End of Path Events are

RETURN Marker - This Marker is for specifying the output of Events relative to the RETURN Point. All Events placed prior to the RETURN Marker will be output just before the RETURN Point is output and Events placed after the RETURN Marker will be output after the RETURN Point has been output.

NOTE: The RETURN Marker will not have any significance if the RETURN Point has not been defined.

GOHOME Marker - This Marker is for specifying the output of Events relative to the GOHOME Point. All Events placed prior to the GOHOME Marker will be output just before the GOHOME Point is output and Events placed after the GOHOME Marker will be output after the GOHOME Point has been output.

NOTE: The GOHOME Marker will not have any significance if the GOHOME Point has not been defined.

2.0.6 Incremental Editing

Incremental Editing of operation will be possible in case of Machine Control Events. Creating and editing of Start of Path and End of Path sets of Machine Control Events will not require the regeneration of the tool path of the operation. The changes will be reflected when posting the path.

Editing of Events in an existing In Path set will also not require tool path regeneration for the edits to take effect but creating new In Path sets will require tool path generation for the addition to take effect.

2.0.7 Conflict resolution

As the Event structures are user definable it is possible that the structure of an existing Event may be changed. This will cause a conflict because the structure definition of any existing Events of that kind stored by UG will be different from the new definition. There are three possible ways of handling this kind of conflict

Convert all the Events that are saved in the UG part file to conform to the changed definition. This approach can handle the situation of new parameters being added to the Event, by adding the new parameter with a default value to the existing Events. But the problem is in cases where the type of a parameter is changed the data of the existing parameter may not map to the new type.
Leave the existing Events alone and only create new ones with the new structure definition. The problem in this approach is that the interpreting of the Events during output will have to account for the different possible structures.
The most practical approach will be to avoid changing the structure definition. If any changes are necessary then a new Event can be with the new structure.

2.0.8 Part Conversion

The changes proposed above will call for conversion of Machine Control Events that have already been defined.

The structure definitions for all the Events in the predefined sets of Machine Control Events will be provided with UG. By default all the events will have no CLASS attribute specification but only the relevant CATEGORY attribute specification. The Available list of Events presented during the specification of Start of Path , End of Path and In Path Events will all be the same, and it will be based on all the Event definition structures present in the Event definition file.

3.0 Interaction

The Available list of Machine Control Events that will be displayed in the dailog that is dictated by the Event structures that have been defined during Machine definition. Also the System Events and Markers will be added to this Available list automatically. Once an Event is selected to be defined all the parameters of the of the Event will be presented in a dialog. The structure of the Event for presenting in the dialog will be picked up from the definition that was provided during Machine definition. The structure of the System Events and the Markers will be hardcoded in the system.

Once an Event is accepted the data of the Event as well as its structure definition will be stored in the part file. The defined Event will also appear in the Defined list. The format of the presentation of the defined Event will be User configurable.

4.0 Language Interfaces

4.1 UG/Open GRIP

Exisitng commands which create Machine Control Events will continue to work as before. The structure definition for the Events created by the existing commands will be the default definitions that will be documented.

4.2 UG/Open API (User Function)

UFUNC TEMPLATE

Name UF_PATH_create_ude( char *event_name, ... );

Internal & External

Synopsis

Parameter	I/O	Type	Descrption
event_name	I	char *	The name of the event being created
...			A variable length argument list
return	O	int	Return Code: 0 = No error = 0 = Error code

Description

This function is used to create a User Defined Machine Control operation. This is a variable length argument list function. The first argument is the name of the Event. Subsequent arguments appear in pairs and each pair consists of the parameter name and value. If only one argument is specified an Event of that name with all the Event parameters having default values will be created.