STEP Interface (STEP) Subsystem

The STEP subsystem is the top level subsystem in the STEP interface. The STEP subsystem provides STEP dependent functions for initializing, and terminating STEP information models. The reader should be familiar with the mda and ddf subsystems (see mda_intro and ddf_intro) before reading this manual page.

The step_Initialize() and step_Terminate() functions set up the required data structures that all STEP applications will use. These functions will call the initialize and terminate functions for all of the other STEP related subsystems except s203 and s214 (all such subsystem prefixes consist of four characters with the first being "s" for STEP). The function step_Initialize must be called once before any other STEP interface function. The call to step_Initialize must follow the pdx_Initialize call. Once processing is complete, the function step_Terminate should be called prior to calling pdx_Terminate.

The STEP interface currently provides three possible methods of creating a STEP model. The first two methods simplify creation of a model that uses one of our precompiled DDF's, p203is.ddf (AP 203 IS) or p214cd.ddf (AP 214 Committee Draft). Please see the s203_intro or s214_intro man pages for examples. The third method should be used if your application requires its own special schema. Remember that this should only be used if you have compiled your own special DDF. The following code sequence demonstrates this:

#include "ddf_Interface.h"
#include "mda_Interface.h"
#include "step_Interface.h"
#include "your_schema_ddf.h"
        .     
MDA_MODEL_INFO m_info;
int model;
        .
pdx_Initialize (PDX_NOOPT);
step_Initialize (STEP_NOOPT);
        .
mda_GetModelDefaults (MDA_NOOPT, &m_info);
step_InitModelInfo (STEP_NOOPT, &m_info);
        .
/*  Other m_info fields set  */ 
/* explicitly set the ddf field in the MDA_MODEL_INFO */
m_info.ddf = &your_schema_ddf;
        .
mda_AllocateModel (MDA_NOOPT, &m_info, &model);

The model is now ready to have STEP entities added. The model can be populated with the contents of a STEP Physical file by calling mda_ParseFile. The contents of a model can be written to a STEP Physical file by calling mda_FormatFile. The mda_intro manual page describes how additional entities are added to the model.

The Header and Data section entities are stored as entities in the model. The Header section entities will have a type of 9000, and a form of 1 or greater. The Data section entities will have type numbers starting at 1 and incrementing by 1. For internally mapped entities, the form number will be 0 and the form number will be 1 for externally mapped entities.

An internally mapped entity is one in which the entities ancestor tree does not contain any AND operations. An externally mapped entity is one in which this occurs. An example of the EXPRESS corresponding to an internally mapped entity would be:

ENTITY point 
     SUPERTYPE OF (ONEOF(cartesian_point, point_on_curve))
END_ENTITY;
ENTITY cartesian_point
SUBTYPE OF (point);
  x_coordinate  : REAL;
  y_coordinate  : REAL;
  z_coordinate  : OPTIONAL REAL;
END_ENTITY;
 
ENTITY point_on_curve
SUBTYPE OF (point);
  basis_curve     : curve;
  point_parameter : REAL;
END_ENTITY;
For the example above, a possible physical file representation would be:
  #11=CARTESIAN_POINT(1.2, 2.0, 3.45);

An example of the EXPRESS corresponding to an externally mapped entity would be:

ENTITY edge SUPERTYPE OF (edge_curve ANDOR oriented_edge)
  edge_start   : vertex;
  edge_end     : vertex;
END_ENTITY;
 
ENTITY edge_curve
  SUBTYPE OF(edge);
  edge_geometry  : curve;
  same_sense     : BOOLEAN;
END_ENTITY;
 
ENTITY oriented_edge
  SUBTYPE OF (edge);
  edge_element : edge;
  orientation  : BOOLEAN;
END_ENTITY;
 
For the example above, some possible physical file representations would be
(#13 is an externally mapped entity instance):
  #11=EDGE_CURVE(#10,#9,#8,.T.)
  #12=ORIENTED_EDGE(#10,#9,#11,.F.)
  #13=(EDGE(#10, #9)EDGE_CURVE(#8,.T.)ORIENTED_EDGE(#11,.F.))

The externally mapped entities will be stored as a single entity of type T_EXTERNAL_MAP (tf = 8999:0) which contains a list of pointers to the other entities which make up the externally mapped entities. These will have a form number of 1.

 DDF Representation
entity 8999:0 external_map {
        $STEP_HEADER;
        ptr type[];
}attr=(extern_map);
The field type will contain the list of entities that make up the externally 
mapped entity.  For the example:
  #13=(EDGE(#10, #9)EDGE_CURVE(#8,.T.)ORIENTED_EDGE(#11,.F.))
It will contain ptrs to the EDGE, the EDGE_CURVE, and the ORIENTED_EDGE.

Since the database pointers resulting from a parsed STEP Physical file do not correspond to the original Physical file ID, a T_STP_HDR structure is included into every entity. This structure contains a field for the pfid and also one for the SCOPEing entities pfid. This data structure is instantiated by the STEP Physical File parser (safp_ParseFile). However, STEP/Lib does not make any other use of these data structures nor does it maintain them outside of the parser. But this information is invaluable for debugging and may have other uses in your application.

Note that for entities which are externally mapped, the pfid of the entity in the Physical file will be found in all of the entities which go into making up that externally mapped entity.

The MDA subsystem provides the capability of storing backpointers to referencing entities. The STEP Physical file parser updates backpointers as a file is parsed.

There are three major log file functions. SFMT_FILE_STAMP and SFMT_DATA_SECTION and SFMT_ERROR_SUMMARY. The SFMT_FILE_STAMP will output a user specified title, the filename, and the current date and time. The SFMT_DATA_SECTION will output a listing of the Header Section entities, as well as the entity counts for entities in the model. The SFMT_ERROR_SUMMARY will output a summary of error and processing time information.

The mpm_IssueMessage function may be invoked to output the three sections as follows:

#include "mda_Interface.h"
#include "mpm_Interface.h"
#include "sfmt_Interface.h"
        .
int model;
char logfile[80], stepfile[80], title[80];
        .
mpm_OpenLog (MPM_NOOPT, logfile);
mpm_SetOption (MPM_NOSTD);
mpm_IssueMessage (MPM_NOOPT, SFMT_FILE_STAMP, title, stepfile);
mda_ParseFile (MDA_NOOPT, model, stepfile, NULL);
mpm_IssueMessage (MPM_NOOPT, SFMT_DATA_SECTION);
        .
mpm_IssueMessage (MPM_NOOPT, SFMT_ERROR_SUMMARY);
mpm_CloseLog (MPM_NOOPT);

Tolerances in PDElib are considered associated to a particular model. The tolerances used by the STEP subsystem are only used when converting STEP data to and from GDX and must be set in the STEP model prior to calling the sgdx_GetSTEPData or sgdx_GetGDXData functions. Tolerances can be accessed through the mda_SetTol, mda_SetTol2, mda_GetTol, and mda_GetTol2 functions. A complete list of the tolerance names and their default values can be found in gdx_intro.

The default decoder for the old step parser (SAFP) is safp_DecodeString; it performs only basic STEP decoding (except \S and P sequences) and does not encode to another encoding (UTF-8, SJis, etc...). The new step parser (SNFP) uses step_STEPToUTF8 by default and decodes everything except P sequences. step_STEPToUTF8 encodes the decoded STEP string to UTF-8. Decoding behavior can be overrided by a call to step_SetDecoder. The following decoders are provided by PDElib:

safp_DecodeString
step_STEPToEUC
step_STEPToSJis
step_STEPToUTF8

The default encoder is saff_EncodeString. An encoder function takes in a pointer-to-char and a pointer-to-FILE and writes out a STEP encoded string to the given file pointer. The encoder can be overrided with a call to saff_RegisterEncoder; the encoder is global to all step models. These encoders are provided by PDElib:

saff_EUCToSTEP
saff_EncodeString
saff_SJisToSTEP

Before using these functions, the PDElib native lanuage utility subsystem must be intialized with unl_Initialize. When done, the unl_Terminate function must be used to release pre-allocated memory.