2 the patran command language (pcl) introduction€¦ · · 2015-03-311991-05-01 · process the...

Chapter 2: The PATRAN Command Language (PCL) IntroductionPCL and Customization

2 The PATRAN Command Language (PCL) Introduction

Introduction 6

Basic Concepts 7

PCL Variables and Constants 10

PCL Operators and Expressions 19

Control Statements 21

PCL Functions 25

The C Preprocessor 31

Finding Programming Errors with PCL 33

Initializing the Session 35

Session Files to PCL Files 42

PCL and CustomizationIntroduction

6

IntroductionThe PATRAN Command Language (PCL) is a programming language which is an integral part of the Patran system. It can be used to write application or site specific commands and forms, perform variational or connatural modeling, and completely integrate commercial or in-house programs. The entire Patran user interface is driven by PCL.

PCL is a high level block structured language. It provides many features found in traditional programming languages including:

• Operators for arithmetic, relational, and string expressions.

• Intrinsic functions for math, string, and other operations.

• Variables with type, scope, and dimension attributes.

• Dynamically allocated virtual strings and arrays.

• Loop control structures such as WHILE, FOR, LIST, and REPEAT.

• Conditional control such as IF-THEN-ELSE and SWITCH-CASE.

• Subroutine and function calls from within PCL functions.

• Class grouping of related functions.

• Read/write access to external files.

• Support for PATRAN 2.5 NOODL rule.

• Preference to user interfaces, applications, databases, and graphics.

• PCL specific start-up files.

• Text output to the history window, session file, or TTY terminal.

PCL is a complete MCAE programming environment that greatly enhances the versatility of the Patran system.

Some of the benefits of PCL include:

• Application specific commands provide more accurate modeling. For example, pressure applied as a function of chord length along a turbine blade.

• In-line expressions make Patran more versatile for the everyday user.

• Allows Patran to be integrated more easily and completely with other commercial or in-house codes.

• Provides a mechanism for parametric design studies.

• Patran may be customized to service specific customer requirements.

7Chapter 2: The PATRAN Command Language (PCL) IntroductionBasic Concepts

Basic Concepts

Patran and PCLPCL is tightly coupled with Patran. The user interface system is integrated with PCL via callbacks. What this means is whenever a menu item is selected or a button clicked on, a PCL function is called to process the operation. In a similar fashion, after entering a line into the command line, that line is sent to PCL for processing. If a session file for processing is selected, the session file manager passes to PCL any lines that it does not handle itself.

PCL CommandsPCL statements come in many forms. Some examples of PCL statements include:

theta = 360.0 - MTH_ASIND( value )IF ( radius > 20.0 ) THEN radius = 20.0make_gear ( 30, 100 )

PCL commands may be entered interactively through the command line, or processed in a session file or retrieved from an external PCL file or library.

A PCL statement is normally terminated by a carriage return. A statement can be continued across multiple lines by using an at sign “@” as the last non-blank character of the line to be continued. It is not permissible to break a statement in the middle of an identifier, keyword, or constant value. It is possible to have multiple statements on a single line by separating them with a semicolon “;”. In general, break a line at a space, comma, or operator. Multiple spaces and/or tabs are treated as a single space.

Example:

IF( str_length( mystring ) >= 100 || @bigarray(n) < bigarray(n+1) ) THEN quit = TRUEx = 5; y = 10; z = x * ( y + 5 )

PCL CommentsIn PCL a comment is specified by starting with the sequence /* and ending with the sequence */. Comments may appear anywhere within a PCL statement except in the middle of a string constant. A comment may span multiple lines. A one line comment can also be specified by a dollar or pound sign as the first non-blank character. Examples of PCL comments include:

FillRadius = 5.0 /* Outside fillet radius */

and the following sequence:

/* * A typical header block comment might look like this */

Important:Examples in the following sections are excerpts from working PCL functions. By themselves, they are incomplete and will not execute properly.

PCL and CustomizationBasic Concepts

8

or a one line comment with:

$ This is a comment.# This is a comment too.

PCL Embedded in NOODL Commands and DataboxesA PCL expression can be embedded within any NOODL command by enclosing it in a set of backquote characters, ( ` ). Also PCL expressions can be embedded within most of the user interface databoxes in the same manner.

An example use of PCL within a NOODL would be:

LI,3#,ARC,5(0)/1/`30 + offset`,10

To use Patran as a calculator for example, enter:

!$` SQRT(250.) * 12.4`

and the response is made into the originating TTY window:

$ 196.0612

Be sure to preface any calculator directives with the “!$” sequence so that Patran does not attempt to process the line as a Patran command.

Another way to use Patran as a calculator is to use the write function.

WRITE (SQRT(250.) *12.4)

And the response is made into the command line:

$# 196.0612

In a user interface databox, use the backquote syntax such as:

Angle: ‘360/5‘

IdentifiersAn identifier is a one to thirty-one character name containing letters, digits, and underscores and beginning with a non-digit character. Variable names and function names are identifiers. PCL is not sensitive to uppercase and lowercase for all uses of identifiers and keywords. String contents are retained as case sensitive, but string comparisons are case insensitive.

Keywords are identifiers reserved for use by PCL. These cannot be used as variable or function names. Current PCL keywords include:

9Chapter 2: The PATRAN Command Language (PCL) IntroductionBasic Concepts

Some examples of valid identifiers are:

a, b, c, X1, x_2, InnerRadiusTryAgain, not_done

While the following are invalid:

_status, 10b(Variable names must begin with a letter.)

real, list(Variable names must not be reserved.)

This_is_Much_Much_Much_Much_too_long(Variable names may contain up to 31 characters.)

DirectivesDirectives begin with “!!” and are processed differently than regular PCL statements. Directives are processed immediately when encountered. Do not embed directives into PCL functions. Unexpected results may occur. Directive key words are:

BREAK BY CASE CLASS CLASSWIDE

CONTINUE DEFAULT DUMP ELSE END

FALSE FOR FUNCTION GLOBAL

IF INFORMATIVE INTEGER LIST

LOCAL LOGICAL ON READONLY REAL

REPEAT RETURN STATIC STRING SWITCH

THEN TO TRUE UNTIL VIRTUAL

WHILE WIDGET WIDGET_NULL

!!INPUT file Direct Patran to process all further input from the specified file.

!!LIBRARY file Access PCL libraries.

!!PATH Directory Specific directory search path for opening files.

!!TRACE option PCL execution verification.

!!DEBUG option Store PCL line contents in file for future reference when debugging PCL code.

!!COMPILE file into library

Compiles a PCL text file into library format.

!!OPTIONS option PCL environment options setting.

!!SIZE CODE newsize Set new size for compiler code area.

!!CLEAR GLOBAL name Erase definition of global variable.

!!CLEAR FUNCTION name Erase definition of a function.

PCL and CustomizationPCL Variables and Constants

10

PCL Variables and ConstantsPCL variables have the attributes of type, scope, and dimension. All variables must be defined before they are used. Variable names may be 1 to 31 characters in length. Valid variable types are integer, real, logical, string, and widget. Scope defines a variable's visibility and lifetime.

Data TypesAll PCL variables must be declared before they are used. The declaration specifies the variable's type, scope and dimension.

Dynamic

A dynamic data type is a data type that is used to describe an input argument, output argument, or return value from a built in PCL function that can be any combination of an integer, logical, real, string, or widget data type.

This data type is denoted in a PCL function description in this manual using an acronym: DYNAMIC_ILRSW. The ILRSW component in the acronym will be used to denote the exact data types that can be used with that value where I is used for an integer, L is used for logical, R is used for a real, S is used for a string, and W is used for a widget data type.

The dynamic data type is not supported by the PCL language and trying to declare a variable with a dynamic data type will generate an error. While it is possible for built in functions to use the dynamic data type, it is not possible to write a PCL function that uses this data type.

An example of a PCL function that returns a dynamic data type is the function sys_eval, 206.

Integers

An integer variable is defined by prefixing the variable name with the keyword INTEGER.

Example:

INTEGER a, b, c

An integer constant is represented by an optional plus or minus sign followed by a set of digits. The range of an integer is machine dependent but will always be able to represent a number between -2147483647 and 2147483647. It is also acceptable to use a hexadecimal constant by having the prefix 0x or 0X followed by hexadecimal digits in uppercase or lowercase.

Examples:

11Chapter 2: The PATRAN Command Language (PCL) IntroductionPCL Variables and Constants

Logicals

A logical variable is defined by prefixing the variable name with the keyword LOGICAL.

Example:

LOGICAL exit_flag

A logical constant is represented by the reserved identifiers TRUE and FALSE.

Examples:

exit_flag = TRUE

or

exit_flag = FALSE

Reals

A real variable is defined by prefixing the variable name with the keyword REAL.

Example:REAL x, y, z, height

A real constant is represented by an optional plus or minus sign followed by an optional set of digits, a required decimal point, another optional set of digits, and an optional “E” followed by an optional plus or minus sign and a set of digits. There always needs to be at least one digit before or after the decimal point. The range and precision of real numbers is machine dependent, but count on 5 digits of accuracy and an exponent range of 1.E-30 through 1.E30.

Examples:

x = 4100.06; y = -22.E-4; z = -1.0E3

Strings

A string variable is defined by prefixing the variable name with the keyword STRING and appending the maximum string length as a positive integer within square brackets.

Example:

STRING name[20], option[130]

A character string constant is represented by a double quote, a string of characters, and another double quote. A character string which spans lines should do so by splitting it into smaller pieces and

4510, -17, 0X11E0 (The first two examples show positive and negative integer constants. In the third example, the prefix 0X indicates that 11E0 is a hexadecimal constant.)


12

concatenating the pieces together. A character string has both a maximum length and a current length. The current length of a character string can be anywhere from zero up to its maximum length.

Examples:

name = “I”multiplier = “23*A”option = “A CHARACTER STRING WHICH SPANS LINES SHOULD DO SO “// @ “BY SPLITTING IT INTO SMALLER PIECES AND “// @ “CONCATENATING THE PIECES TOGETHER.”

PCL strings are variable length up to the maximum size that they are declared. Therefore, the series of statements:

STRING line[40]line = “ABC”line = line // “ ”line = line // “DEF”

produces the variable line defined as “ABC DEF” with no trailing blanks. This is quite different than the way FORTRAN strings work.

Widgets

A widget variable is defined by prefixing the variable name with the keyword WIDGET and is used only for working with the user interface routines. A widget can be assigned from a user interface function or other widget or can be compared against another widget.

Example:

WIDGET myform, mybutton

The only widget constant defined is WIDGET_NULL. If a user interface routine fails to operate sucessfully, the widget value returned will normally be WIDGET_NULL. To initialize widget variables, initialize them to WIDGET_NULL.

Examples:

IF ( myform == WIDGET_NULL ) THEN WRITE (“Form not initialized”)

ScopeScope defines a variable's visibility and lifetime. Variables that are not assigned a scope behave like LOCAL variables if declared within a function definition or like GLOBAL variables if declared outside of a function. PCL variables may have the scope of global, local, static, or classwide. These scopes are defined below.


Examples:

Arrays

Directly Allocated Arrays

Any variable, regardless of its data type, can be made into an array. Arrays can have any number of subscripts. Subscripts are contained in parentheses separated by commas appended to the variable identifier. Each subscript may have a lower and upper bound separated by a colon. If the subscript range

GLOBAL Variable definition is available to all functions. Global variables become undefined when Patran terminates.

LOCAL Variable definition is local to a single function. A local definition temporarily overrides any global definition. Local variables become undefined when the function exits.

STATIC Variable definition is local to a single function. A Static variable retains its value between function calls. Static variables become undefined when Patran terminates.

CLASSWIDE Variable definition is local to a group of functions. A classwide variable retains its value between function calls. Classwide variables become undefined when Patran terminates.

Important: PCL uses a flat name space for both function names and variable names. The user should be careful not to use conflicting names for PCL variables and functions.

GLOBAL LOGICAL flag. Flag is defined global and since outside of a function definition is defined for use in the command line and in databoxes.

CLASS my_classCLASSWIDE STRING line[80]

The string line is defined within all the functions within the class my_class.

FUNCTION MY_FUNCTION (arg_list)STATIC INTEGER entries

The value established for entries in MY_FUNCTION remains the same between function calls.

LOCAL REAL x,y,z. These variables are only defined within my_function.

REAL arg_list () Since arg_list is an argument to the function, its scope is inherited from the calling function.

GLOBAL LOGICAL flag. Even though flag is defined GLOBAL outside the function, within each function definition it needs to be declared the same way. All references to flag affect the same global value.

END FUNCTIONEND CLASS


14

is not specified with a lower and upper bound, the lower bound is assumed to be one (not zero as in the C programming language). Subscript bounds may be negative or zero.

Arrays are stored in sequential order starting from the subscript to the right and moving to the left. This is opposite to the way FORTRAN stores array data, see Figure 2-1

LOCAL arrays are only allocated when the function is called and the memory is freed up when the function exits. Memory for arrays of other scopes remains allocated for the duration of the program’s execution.

Examples:

An array constant can be specified by enclosing a set of constant values in square brackets. The following examples will best illustrate the syntax.

STATIC INTEGER entries(100)

The subscript 100 creates a STATIC array of 100 integers referenced by 1 to 100.

REAL table(-5:10, 20, 5:7)

The first subscript of table, -5:10, allocates 16 rows which are referenced by the bounds of -5 to 10. The second subscript allocates 20 rows. The third subscript allocates three sets of data referenced by 5 to 7. The total array occupies 16*20*3 or 960 storage locations.

GLOBAL LOGICAL flags(0:8192)

The logical array flags occupies 8193 storage locations referenced by 0 to 8192.

STRING line[80](100),

ch[1](10,5) 100 strings of variable line, 80 characters each and 10 x 5 strings of variable ch, one character each.

INTEGER I(3,5) The integer array I occupies 15 storage locations arranged in order where the rightmost subscript varies most rapidly.


Figure 2-1 PCL Array Storage

When referencing arrays, a portion of the array may be specified by using a colon to separate the upper and lower bound.

Examples:

Virtual Arrays

Any variable can be defined as a virtual array instead of a directly allocated array. Virtual arrays do not have storage locations assigned to them at program initialization. The size and amount of storage is allocated as requested and can be reused for other virtual arrays. To declare a virtual array, use the keyword VIRTUAL in place of the subscripts for the declaration. For example:

REAL mydata(VIRTUAL)

To allocate storage and specify lower and upper bounds, use the function SYS_ALLOCATE_ARRAY( array, lb1, hb1, lb2, hb2, lb3, hb3, lb4, hb4) passing 3, 5, 7, or 9 arguments depending on whether to allocate a virtual array to be one, two, three, or four dimensional. Once allocated, a virtual array can be used interchangeably with a non-virtual array. A different size array can be re-allocated with a subsequent SYS_ALLOCATE_ARRAY call, but the original contents of the array are lost. A different size array can be re-allocated to retain the old contents of the array with the SYS_REALLOCATE_ARRAY function. Storage can be freed with a SYS_FREE_ARRAY call. A virtual array with LOCAL scope is automatically freed when the function it is declared in exits. SYS_ALLOCATE_ARRAY returns a zero status on success and a non-zero if the allocation failed.

Or, to allocate a two dimensional array, enter:

[1, 2, 3] A three element integer array.

[“Ace”, “King”, “Queen”,“Jack”] A string array constant.

[1.1, 2.2], [17,5], [-8,0]] A real array constant dimensioned (3,2).

my_function( node_list(10:30) )

In this example, elements 10 through 30 of the node_list array are passed to my_function.

err = SYS_ALLOCATE_ARRAY (mydata, 1, 1000 ) Allocate a one dimensional array.


16

err = SYS_ALLOCATE_ARRAY (mydata, 1, 1000, 1, 20000)

Or, to re-allocate the two dimensional array, enter:

err = SYS_REALLOCATE_ARRAY (mydata, 1, 30, 1, 20000)

To find out the dimension associated with any array, use the PCL command SYS_ARRAY_NBOUND( array ).

The lower and upper bounds of an array are found by using the commands, SYS_ARRAY_LBOUND( array, bound ) and SYS_ARRAY_HBOUND( array, bound ).

Virtual Strings

A string can be defined as a virtual string instead of directly declaring the size of the string. Virtual strings do not have storage locations assigned to them at program initialization. The size and amount of storage is allocated as requested and can be reused for other virtual data. To declare a virtual string, use the keyword VIRTUAL in place of the string size for the declaration. For example:

STRING line[VIRTUAL]

To allocate storage and specify the maximum size of the string, use the function SYS_ALLOCATE_STRING( string, maxsize). Currently, the string size must be between one and 32767. Once allocated, a virtual string can be used interchangeably with a non-virtual string. A different size string can be re-allocated with a subsequent SYS_ALLOCATE_STRING function, but the original contents of the string will be lost. A different size string can be re-allocated to retain the old contents of the string with a SYS_REALLOCATE_STRING function. Storage can be freed with the SYS_FREE_STRING function. A virtual string with LOCAL scope is automatically freed when the function it is declared in exits. SYS_ALLOCATE_STRING returns a zero status on success and a non-zero if the allocation failed. Virtual strings arrays are allowed, but currently a SYS_REALLOCATE_STRING may not be performed on one.

SYS_FREE_ARRAY (mydata) Free up the array storage space.

err = SYS_ALLOCATE_ARRAY (moredata, -200, 200, 0, 20)

Allocate a two dimensional array.

SYS_FREE_ARRAY (moredata) Free up the array storage space.


To find out the maximum size of any string, use the PCL function STR_MAXLENGTH(string).

Variable InitializationVariables may be initialized with a value when they are declared. Initializations are specified by following the variable declaration with an equal sign (“=”) and then a constant of the correct type for the item being declared. If an array is being declared, there must be enough constants to initialize the entire array, separated by blanks or commas optionally enclosed in square brackets.

GLOBAL variables defined within a FUNCTION definition cannot be initialized. CLASSWIDE variables also cannot be initialized currently. If a STATIC variable is initialized, the initialization takes place at compile time, and any modification to the value of the variable remains intact for the duration of the session. When GLOBAL or LOCAL variables are initialized, the initialization is identical to including the assignments following the declaration. This means that a LOCAL variable with initialization will be re-initialized on each entry into the FUNCTION in which it is defined.

Some example initializations are:

REAL TABLE(2,3) = [ 10, 20, 30, 11, 21, 31 ]STRING PROMPT[20] = “This is a prompt”INTEGER I = 0, J = 17

err = SYS_ALLOCATE_STRING (line, 500) Allocate a 500 character string.

err = SYS_REALLOCATE_STRING(line, 800) Now reallocated as a 800 character string.

SYS_FREE_STRING (line) Free up the string storage space.

STRING lines1[VIRTUAL](20), lines2[VIRTUAL](VIRTUAL)

err = SYS_ALLOCATE_STRING(lines1,100)

Allocate the array to have strings of 100 characters.

err = SYS_ALLOCATE_STRING(lines2,80)

err = SYS_ALLOCATE_ARRAY (lines2,1,20)

Allocate a 20 element array of strings of 80 characters.

SYS_FREE_STRING (lines1)

SYS_FREE_STRING (lines2)

SYS_FREE_ARRAY (lines2)

Important:Multi-dimension arrays are stored in row major order. This is opposite of FORTRAN's definition. Virtual arrays and virtual strings can not be initialized.


18

Argument DeclarationThe input and output parameters that are passed back and forth to a function are called arguments. Arguments to a function must be declared and must match the datatypes used within the function.

Within a function, it is permissible and recommended that the values within an array or string definition be omitted. The function uses the dimension values of the arrays or strings specified in the calling argument in any case so it can be misleading to specify values for dimensions for the arguments. Some examples are:

REAL ENTRY(5,20), ELEMTABLE(20,40)STRING ENTRYTITLE[40] = “This is the title for the Entry Table”STRING ELEMTITLE[15] = “Type of Element”INTEGER N, K...R = MY_FUNCTION (ENTRY, N, ENTRYTITLE )...R = MY_FUNCTION (ELEMTABLE, K, ELEMTITLE )...FUNCTION MY_FUNCTION (TABLE, POINTER, TITLE )REAL TABLE()STRING TITLE[]INTEGER POINTER

19Chapter 2: The PATRAN Command Language (PCL) IntroductionPCL Operators and Expressions

PCL Operators and Expressions

Hierarchy of OperatorsPCL supports a wide range of operators including basic math and Booleans. Expressions are built from a set of operators, constants, variables, and functions. User functions and intrinsic functions can be used as operands. Unary operators take a single operand to the right, and binary operators are placed between two operands. Numeric, logical and string operators are provided.

Certain operators take precedence over others (i.e., multiplication is done before addition). The precedence can be overridden by use of parentheses. The following list gives the operators in order of precedence from highest to lowest.

The following table is list of operators giving the datatypes that they can operate on and the result datatype for the operation. In the table, the letters I, R, S, L, and W stand for INTEGER, REAL, STRING, LOGICAL, and WIDGET respectively.

Table 2-1

Operators Definitions

+ - ! Unary Plus or Minus, Logical Not

** Exponentiation

* / Multiplication and Division

+ - Addition and Subtraction

// String Concatenation

< > <= >= == != Relational Operators

|| && Logical Or, Logical And

+= -= = Increment, Decrement, Assignment

PCL and CustomizationPCL Operators and Expressions

20

.

Examples:

An example of using operators to find the two real roots of a quadratic equation in PCL:

IF ( b**2 > 4.0 * a * c && ABS(a) >= 1.0E-7) THEN root(1) = ( -b + SQRT( b**2 - 4.0 * a * c )) / (2.0*a) root(2) = ( -b - SQRT( b**2 - 4.0 * a * c )) / (2.0*a)END IF

String Comparisons:

The string comparison operators are special in that they ignore trailing blanks and uppercase and lowercase. Therefore, all the following expressions are TRUE.

“ABC” == “ABC”“ABC” == “abc”“TEST” == “TEST”“HELLO” < “help”“hello” < “HELP”

Table 2-2

Operators Operands Result

** * / + - += -= I,R I,R

// S S

< > <= >= I,R,S L

== != I,R,S,L,W L

= I,R,S,L,W I,R,S,L,W

|| && L L

Note: Expressions with a mixture of INTEGER and REAL data types are valid and will be converted to the assigned data type. Real to integer conversion truncates the fraction. All arithmetic expression evaluations are done in single precision.

IVAL += 4 * SIND( MYANGLE )

IVAL is incremented by the integer value resulting from the calculation of (4 x sin(MYANGLE) and the truncation of all digits after the decimal point.

MYFUNC( ) >= (A+1)*2 && STR1 // STR2 == “TESTING”

Test for MYFUNC( ) greater or equal to (A+1)*2 and the concatenation of STR1 with STR2 logically equal to the string “TESTING”.

21Chapter 2: The PATRAN Command Language (PCL) IntroductionControl Statements

Control StatementsControl statements are used to transfer control to another section of the program. The following syntax conventions are observed in the following examples:

REQUIRED KEYWORDSAll required keywords are identified in bold Courier font.entryItems in plain Courier font are descriptions of the expected entry.[label]Items enclosed in brackets are optional.

BranchingPCL is a block structured language. Language elements that control branching and skipping are the IF THEN ELSE, SWITCH CASE, BREAK and CONTINUE statements.

Break and ContinueThe BREAK and CONTINUE statements are only allowed within the body of FOR, WHILE, REPEAT, SWITCH and LIST statements. In addition, if the optional label field is given, the label must match one of the above block structures the statement is within. The CONTINUE statement causes transfer to the END statement processing for the block structure indicated by the label field or the most current block structure if no label is provided. This essentially causes the loop to repeat. The BREAK statement is similar except that it transfers control past the END statement, thereby terminating execution of the loop. The format of the two statements is as follows:

BREAK [ label ]CONTINUE [ label ]

Examples:

CONTINUE active_set_loop

BREAK

Simple If ThenThe simple IF statement evaluates the logical expression in the clause. If the result is TRUE, the single statement immediately following the THEN keyword is executed. If the result is FALSE, then nothing happens. The IF statement structure is as follows:

IF( logical_expression ) THEN statement

If Then ElseThe IF statement evaluates the expression in the clause. If the result is TRUE, the group of statements immediately following is executed and then control skips to the matching END IF clause. If the result is FALSE, then if there is an ELSE IF clause, it is evaluated and the preceding logic is repeated. If all results evaluate to FALSE, then the statements following the ELSE are executed. Multiple ELSE IF clauses are allowed. The IF statement structure is as follows:

PCL and CustomizationControl Statements

22

IF( logical_expression ) THENstatements...ELSE IF( logical_expression ) THENstatements ...ELSEstatements ...END IF

The program statements within a conditional structure are normally indented to make it easier to read. PCL and Patran ignore all leading blanks in a line.

Examples:

In the following example of the IF THEN statement, a patch model is being adaptively meshed based on the previously evaluated strain energy density for the region defined by the patches in patch_list:

IF ( strain_energy > max_threshold ) THEN

el_length = el_length / 2.0do_my_mesh( patch_list, “QUAD”, I,el_length )

ELSE IF ( strain_energy < min_threshold) THEN

el_length = 2.0 * el_lengthdo_my_mesh( patch_list, “QUAD”, I,el_length )

ELSE

BREAK adapting /* Break out of loop called adapting */

END IF

Switch and CaseThe SWITCH statement starts by evaluating the expression in the clause. It then scans for each CASE statement in turn. Upon reaching the CASE statement, each expression in the CASE is evaluated. If there is an equality match of the CASE expression result and the SWITCH expression result, the statements up to the next CASE or DEFAULT are executed, and then control passes to the statement after the END SWITCH. If the DEFAULT is reached with no CASE expressions matching, then the statements following the DEFAULT will be executed. The DEFAULT clause is optional. See the Break and Continue, 21 statement for a description of the SWITCH label. The SWITCH statement structure is as follows:

SWITCH(expression) [ label ]CASE(expression1,expression2,...)statements ...CASE(expression1,expression2,...)statements ...DEFAULTstatements ...END SWITCH

As an example of using the SWITCH statement, a PCL function is used to interactively construct the element property cards based on the element configuration code. The function UI_READ_REAL prompts the user with the argument string and returns the real value input from the keyboard.

SWITCH (el_config) CASE (2)

23Chapter 2: The PATRAN Command Language (PCL) IntroductionControl Statements

midm = UI_READ_REAL(“ENTER MEMBRANE MATERIAL ID:”)CASE (3)mids = UI_READ_REAL(“ENTER SHELL MATERIAL ID:”)CASE (mconfig)mass = UI_READ_REAL(“ENTER TOTAL MASS:”)CASE (sconfig)spring = UI_READ_REAL(“ENTER SPRING CONSTANT:”)DEFAULTWRITE_LINE(“WARNING: ELEMENT CONFIG”, el_config,“UNDEFINED”)END SWITCH

LoopingA loop is a repeated execution of a particular segment or group of statements. Loops include initialization, incrementation, execution and test. Loops may be nested within one another. Block structures used for looping in PCL are WHILE, REPEAT, LIST and FOR statements.

ForThe FOR statement begins by evaluating the first numeric expression and assigning it to the variable. Next, the second expression is evaluated and saved as the TO result. The third expression is evaluated and saved as the BY result. If the BY result is zero, an error occurs. If the BY result is positive and the variable value is greater than the TO result, control passes to the statement following the matching END FOR. If the BY result is negative and the variable value is less than the TO result, control also passes to the statement following the matching END FOR. Otherwise the statements in the body are executed. When the END FOR is reached, the variable is incremented by the BY result. The preceding logic is then repeated starting at the point after the expressions were evaluated. Also see the description of the Break and Continue, 21 statements. The FOR statement structure is as follows:

FOR(variable=numeric_expr.TO numeric_expr. [ BY numeric_expr. ]) [ label ]statements...END FOR

WhileThe WHILE statement evaluates the expression in the clause. If the result is FALSE, control passes to the point after the matching END WHILE. Otherwise, the statements are executed and the preceding logic is repeated. Also see the description of the Break and Continue (p. 2-21) statements. The WHILE statement structure is as follows:

WHILE( logical_expression ) [ label ]statements...END WHILE

The program statements within a loop structure are normally indented to make it easier to read.

The following is an example of the use of WHILE and FOR statements. A text file containing node displacements in FORTRAN format 6E16.9 is read and stored in array “node_disp” with library utility function TEXT_READ. The file “fid” has previously been opened with a call to the library function TEXT_OPEN. The integer function TEXT_READ returns the value 0 for a successful read and non-zero otherwise.

PCL and CustomizationControl Statements

24

count = 0WHILE ( TEXT_READ ( fid, “%OF%%6E16.9%”, O, node_dis ( count +1, 1:6)) == 0)count += 1IF ( count > 10000) THENWRITE_LINE(“* DISCONTINUED READING FILE AT” // @“10,000 RECORDS”)BREAK END IFEND WHILE

RepeatThe REPEAT statement starts by executing the statements up to the matching UNTIL clause. Then the expression in the clause is evaluated. If the result is FALSE, the preceding logic is repeated. Otherwise, execution continues with the statement after the UNTIL. Also see the description of the Break and Continue, 21 statements. The REPEAT statement structure is as follows:

REPEAT [ label ]statements ...UNTIL( logical_expression )

As an example of the REPEAT structure, the user is requested to input a grid ID. If an invalid ID is entered, the user is prompted until a valid ID is entered.

REPEATgrid_id = UI_READ_INTEGER( “ INPUT GRID ID ”)UNTIL ( VALID_GID(grid_id) )

ListThe LIST statement executes the statements in the body for each expression in the expression list. Each expression is evaluated in turn and assigned to the variable. For each assignment done, the statements in the body are executed. Also see the description of the Break and Continue, 21 statements. The LIST statement structure is as follows:

LIST( variable=expression1 [,expression2, ...] ) [ label ]statements ...END LIST

In the following example of a LIST statement, the variable “diameter” is used to create both the inside and outside surface of a sphere. The variables x0, y0 and z0 are the global coordinates of the sphere’s origin.

LIST ( diameter = inside_diameter, inside_diameter + thickness )!GR,#,,`x0`,`y0 - diameter`,`z0`!LIN,2#,ARC,`x0`/`y0`/`z0`/`x0`/`y0`/`z0 + 1`/180,#!PA,8#,ARC,`x0`/`y0`/`z0`/`x0`/`y0 + 1`/`z0`/360,2#END LIST!HP,8#,2P,,`maxpid + 1`T`maxpid + 8`,`maxpid + 9`T`maxpid + 16`

25Chapter 2: The PATRAN Command Language (PCL) IntroductionPCL Functions

PCL FunctionsA PCL function is a self-contained program unit consisting of PCL statements. It can perform as a subroutine, breaking programs into logical modules and passing arguments back and forth to other PCL functions or to the main program. Or, it can return a calculated output quantity for the function. In addition, a PCL function can be used to perform both tasks.

PCL functions are defined in files which can be created and modified with system level text editors. PCL functions are then compiled during a Patran session. A PCL function can call other functions. PCL functions can be called recursively.

PCL provides the ability to group functions into named libraries using the LIBRARY command with options to ADD, REMOVE CREATE, DELETE and LIST. An extensive Patran library of functions is also available. The library contains the following categories of functions:

Structure of a PCL ClassPCL functions may optionally be grouped into PCL classes. A PCL class is simply a group of functions that may share a common set of variables. PCL classes are used primarily for working with the user interface routines.

The first statement in a PCL class must contain the word CLASS and the name of the class. The last statement in a PCL class must be an END CLASS statement.

Patran Function Type Function Prefix

Mathematical MTH_

String STR_

System Utility SYS_, UTL_

Block I/O BLOCK_

File I/O FILE_

Record I/O RECORD_

Stream I/O STREAM_

String I/O STRING_

Text I/O TEXT_

Virtual I/O VIRTUAL_

Miscellaneous XF_, UI_, IO_, MSG_, EM_

Session File SF_

PCL and CustomizationPCL Functions

26

A PCL class may have a set of “classwide” variables. These variables are declared the same as other variables but must specify the scope CLASSWIDE and must appear between the CLASS statement and the first function definition.

The syntax of a PCL class definition is:

CLASS classnameCLASSWIDE declarations...functions (see Structure of a PCL Function, 26)... END CLASS

Where classname is the name given to the class.

To refer to a function that resides in a class, specify the classname, a period, and then the function name, i.e., classname.functionname.

Structure of a PCL FunctionThe first statement in a PCL function must start with the word FUNCTION. The last statement in a PCL function must be an END FUNCTION statement.

A PCL function may have an argument list and may also calculate an output quantity for the function. If an argument list is present, it may contain input parameters from the calling program and/or output parameters which pass values back to the calling program or function. The RETURN [value] statement is used to return a calculated output quantity for the function.

Since a FUNCTION may have more than one logical ending, the RETURN [value] statement can appear more than once. The optional value associated with the RETURN statement is the calculated output quantity of the function.

The syntax of a PCL function definition is:

FUNCTION fname( arglist ) declarations... statements... (and/or) NOODL commandsEND FUNCTION

Where fname is the function identifier. arglist is the argument list passed by the function. For the function to return a value, the following statement must be contained in the function:

RETURN value

Whenever the statement RETURN is encountered in a PCL function, processing of the current function terminates and control is passed to the calling function. The return value is optional.

The WHILE loop discussed in a previous example is shown in the context of a complete function. The array “node_disp” is a GLOBAL variable which will hold the node displacement data for use later on

Important:Variable names and function names conflict in PCL. PCL uses a flat name space for both.


during the Patran session. The function TEXT_OPEN opens a file and returns the integer value -1 when it is finished reading a file. The following listing is the complete PCL function:

FUNCTION DISP_READ( file_name)

/* ABSTRACT: Read a file containing node displacements** INPUT:* file_nameOS level name of file containing*formatted records* SIDE EFFECTS:* GLOBALnode_dispNode displacements read and stored here*/

GLOBAL REAL node_disp(10000,6)INTEGER count, i, fidSTRING file_name[80]REAL nodes (6)

/* Open file containing node displacements*/

IF ( TEXT_OPEN( file_name, “or”, 0, 0, fid) == 0 ) THENcount = 0

/* Read and store the data in the global variable “node_disp”*/

WHILE(TEXT_READ ( fid, “%OF%%6E16.7%”, O, nodes, “ ”) == 0 ) count += 1

/* File is too large */

IF ( COUNT > 10000 ) THENWRITE_LINE(“* DISCONTINUED READING”, file_name, @“AT 10,000 RECORDS” )BREAK END IF

/* Each record contains six entries, three displacements* and three rotations. file is formatted FORTRAN 6E16.7 */

node_disp (count, 1:6) = nodesEND WHILE

/* Close the file */

TEXT_CLOSE(fid, “ ”)ELSEWRITE_LINE(“* CANNOT FIND FILE”, file_name)END IFEND FUNCTION

To use the DISP_READ function during a Patran session, the following command is entered in the command line.

DISP_READ(“displacements.dat”)

If, for example, the file displacements.dat contains the desired data, DISP_READ accesses the file to read the displacement data into variable “node_disp.” To access the array “node_disp,” it must be defined as GLOBAL in the session by entering:

GLOBAL REAL node_disp(10000,6)


28

Accessing PCL FunctionsOnce a text file has been created which defines the function, the file must be read into Patran so that it is accessible. There are two directives for achieving this:

!!INPUT file

!!COMPILE file [INTO] library_file

A directive is recognized by the two “!!” exclamation marks at the start of the line. Unlike a PCL statement, which is first compiled making it available for execution, PCL directives are executed immediately.

The INPUT directive allows selection of an input file for further PCL or Patran commands. After receipt of an INPUT directive, commands will now be read from the specified operating system text file. When the end of that file is reached, input will return to the previous file or to the user. Input files can be nested several layers deep. This allows INPUT directives to be used similarly to the concept of including files found in other programming languages.

PCL functions are always compiled into a binary format before being executed. If a function is simply entered or !!INPUT, the compile takes place “on the fly.” The COMPILE directive allows the function to be compiled into the binary format in advance and save the compiled form in a library file with other compiled PCL functions. Using this method the user avoids having to compile the function each time Patran is used.

For the previous two function examples, the directives:

!!INPUT nx !!INPUT disp_read

read the files nx.pcl and disp_read.pcl and allow access to the functions during the session in which the directives are issued. If the file type is not specified .pcl is assumed.

To put the same two functions into the library my_library.plb, issue the directives:

!!COMPILE nx my_library!!COMPILE disp_read my_library

If the library my_library does not exist in the current directory, executing the COMPILE directive will create it with maximum entries set to 256, otherwise, the files will be placed in the existing my_library. If a function by the same name exists in the library, it will be replaced and a message will be issued to the history window.

LibrariesA LIBRARY is a binary file containing any number of compiled PCL functions. A library provides a convenient mechanism for accessing and organizing compiled PCL functions. Whenever PCL is requested to execute a PCL function, it will search the set of libraries that have been specified in LIBRARY directives. The format of the LIBRARY directive is:

!!LIBRARY [ ADD ] file [ file ....]!!LIBRARY REMOVE file [ file ....]!!LIBRARY NONE


!!LIBRARY!!LIBRARY CREATE file [ max_entries ]!!LIBRARY MERGE sourcefile destfile!!LIBRARY SORT file!!LIBRARY REHASH !!LIBRARY KEEPOPEN file [ file ....]!!LIBRARY DELETE file function [ function ...]!!LIBRARY LIST file [ function ... ]

Where file is the operating system name of a library to include in future searches. LIBRARY ADD directives are cumulative. Each one adds an additional library for which to search. The libraries are searched in the reverse order from when specified. The REMOVE option removes a library from the search. The NONE option clears the library search list. A null library command displays the current library search list.

The CREATE option creates a new library which can contain up to the number of functions specified by max_entries, or if max_entries is zero, a “growable” library is created. (If max_entries is not specified it defaults to 256.)

The MERGE option allows the entries to be merged or added from one library into another library. This operation can also be used to compress a library by creating a new library, merging the old library into the new library, and then replacing the original library with the new library.

The SORT option allows the entries in the library to be sorted alphabetically to obtain a nicer listing.

The REHASH option is rarely used but, it can recognize that the contents of the libraries in the library list may have been changed by another user or process and causes Patran to rebuild its optimization tables for all libraries.

The KEEPOPEN option can be used for any library that is already in the library list and attempts to increase performance of accessing frequently used PCL libraries by keeping the operating system library file open all the time.

The DELETE option is used to delete functions from a library. The LIST option lists the contents of a library providing date and size for each function.

To access the library, my_library, issue the directive:

!!LIBRARY my_library

The functions NX and DISP_READ may now be used at any time during the session. To eliminate the need for compiling functions each time they are used, try creating and saving libraries. Use the start-up files to issue the LIBRARY directive.

The sys_library (option, data) function also allows access to the library functions and can be compiled into PCL functions or used within IF statements in PCL start-up scripts. Generally, the “option” is a string containing the operation such as “ADD” and the “data” is a string with the file or function names.

Path DirectiveTo exercise more control over the use of PCL files, the PATH directive defines the order in which a set of directories is searched to find files needed by PCL. These include the files referenced by the other directives as well as files used by many of the PCL intrinsic functions. Examples of files are libraries,


30

INPUT files, start-up files, and files opened by the file I/O utilities. The current directory is always searched first. The default PATH is often configured by the init.pcl file but normally contains the user’s home directory followed by any needed Patran system directories. The format of the PATH directive is:

!! PATH [ ADD ] directory [directory ...]!! PATH REMOVE directory [directory ...]!! PATH NONE!! PATH

where directory is the operating system name of a directory to search. The directories are searched in order. The latest ADD is used first. Within an ADD, the directories are searched first to last. REMOVE will remove entries from the PATH. NONE will clear the PATH. A null PATH command will list the current PATH setting.

The sys_path (option, data) function also allows access to the path and can be compiled into PCL functions or used within IF statements in PCL start-up scripts. Generally, the option is a string such as “ADD” and the data is a string with the directory name(s).

31Chapter 2: The PATRAN Command Language (PCL) IntroductionThe C Preprocessor

The C PreprocessorDuring the development of Patran, the C preprocessor is used with C, FORTRAN and PCL source code. In other words, our source files are automatically sent through the C preprocessor prior to being sent to the specific compiler.

Use of the C preprocessor has many advantages. It allows for substitutions which make the source much more readable. For example, with the C preprocessor a section of code could be written like this:

#define NODE 1#define ELEMENT 2 IF ( entity == NODE ) THEN xxx ELSE IF ( entity == ELEMENT ) THEN xxx END IF

instead of like this:

IF ( entity == 1 ) THEN xxx ELSE IF ( entity == 2 ) THEN xxx END IF

Furthermore, these substitutions can be placed into an include file which would allow for centralization of the “#define” statements. Centralization of definitions into include files allows for cleaner and simpler code, ensures consistency and allows for changes throughout the code to be made very simply. If the two “#define” statements mentioned above were put into an include file called “entity_codes.p” then the above piece of code would be as follows:

#include “entity_code.p” IF ( entity == NODE ) THEN xxx ELSE IF ( entity == ELEMENT ) THEN xxx END IF

If the “entity_codes.p” include file were used consistently through out all source then the element entity code could change from 2 to 3 by simply changing one line in the “entity_code.p” file. The same idea applies to character strings. If all character strings used in code are placed into include files then changing the text strings is a simple task. If the name of an application changed from “in-house-code 5.3” to “in-house-code 5.4” it would only require one change in one file.

The naming convention for include files in Patran is that PCL include files are suffixed with a “.p,” FORTRAN include files are suffixed with a “.i” and C include files are suffixed with a “.h.” An include file is only used for one language, so if the same type of file is to be used in FORTRAN, C and PCL there would be three files. In such a case there is always one master include file and then slave files which merely “#include” the master file. Continuing with our “entity_code.p” example, if this file were to be used in PCL, FORTRAN and C then there would be three include files (entity_codes.p, entity_codes.i and entity_codes.h) whose contents would be:

-------- Contents of entity_codes.p -------------- /* Include file containing entity codes */ #define NODE 1 #define ELEMENT 2

PCL and CustomizationThe C Preprocessor

32

-------- Contents of entity_codes.i -------------- /* Include file containing entity codes */ #include “entity_codes.p”

-------- Contents of entity_codes.h -------------- /* Include file containing entity codes */ #include “entity_codes.p”

Such exclusiveness of include files allows the developer to easily accommodate for the different requirements of different computer languages.

Standard C compilers automatically send source files through the C preprocessor, so C source files do not need to be preprocessed prior to compilation. But, whenever C preprocessor commands are imbedded in FORTRAN or PCL source the source file must first be sent through the C preprocessor and the resulting file sent to the appropriate compiler. A typical C preprocessor command would be:

cpp -P -I$P3_HOME/customization <input_file_name> <output_file_name>

See any C language manual for more on the C preprocessor.

There are many PCL include files which are delivered with Patran in the $P3_HOME/customization directory: appforms.p, appstrings.p, uistrings.p, etc. Two of these include files, appforms.p and uiforms.p, are heavily used in the PCL functions which create Patran forms. The contents of these files are discussed in User Interface and List Processor Functions (Ch. 5).

33Chapter 2: The PATRAN Command Language (PCL) IntroductionFinding Programming Errors with PCL

Finding Programming Errors with PCLThere are two features in PCL that track the PCL program as it is processed: TRACE and DEBUG. These “Debugging tools” can be very useful when finding and correcting errors in the program logic. The first of these tools is the TRACE directive.

Trace DirectiveThe TRACE directive allows specification of tracing options during execution of PCL functions. The TRACE should normally be set to NONE. There are three options that can be enabled in TRACE; they are CALLS, EXITS, and LINES. When CALLS is set, each time a PCL function is called, a message is output. When EXITS is set, messages are output when PCL functions return control to their calling functions. When LINES is set, the current statement numbers are displayed as a function executes. In addition, if DEBUG was ON when the function was compiled, the source statements themselves will be displayed when LINES is set. The format of the TRACE directive is:

!! TRACE NONE(disable tracing)!! TRACE CALLS(enable tracing of function calls)!! TRACE NOCALLS(disable tracing of function calls)!! TRACE EXITS(enable tracing of function exits)!! TRACE NOEXITS(disable tracing of function exits)!! TRACE LINES(enable tracing of function statements)!! TRACE NOLINES(disable tracing of function statements)...

!! TRACE CALLS LINES!! TRACE level mask is CALLS NOEXITS LINES...

Debug DirectiveThe second directive that is useful for debugging PCL programs is the DEBUG directive. The DEBUG directive allows specification of a debugging flag which affects future compilations. With DEBUG ON, the original source lines of the file are compiled into the function. This allows the TRACE command to display the source during execution. The DEBUG option should only be used during development as it creates much larger and slower code. The format of the DEBUG directive is:

!!DEBUG ON(enable DEBUG lines during compile)!!DEBUG OFF(disable DEBUG lines during compile)

Don't forget to set TRACE to LINES when using the debug mode or compiling the function with DEBUG set to ON.

Another feature provided by PCL is the DUMP command. The format of the DUMP command is:

DUMP variable

Where variable is any currently declared variable.

PCL and CustomizationFinding Programming Errors with PCL

34

When the DUMP statement is encountered during execution of any PCL function, the contents of the variable is displayed in the alpha buffer. For an example, we examine the variable xyz by putting the following statement in function NX.

DUMP xyz

When the function NX is executed with a node located at the x=1,y=0,z=0 location, the following is displayed in the alpha buffer:

Array: ( 3 )Data: 1.0, 0.0, 0.0

35Chapter 2: The PATRAN Command Language (PCL) IntroductionInitializing the Session

Initializing the Session

PCL Start-Up FilePCL provides a means to control the session environment by reading the init.pcl file in the current directory when beginning a Patran session.

The init.pcl file does not usually have to be modified. Instead, the init.pcl as delivered will execute the additional start-up files p3prolog.pcl and p3epilog.pcl. These files, if they exist, are executed at the start(p3prolog) and end (p3eiplog) of the init.pcl processing and are a good place to place user or site specific commands.

Typical commands in the start-up files are custom !!PATH and !!LIBRARY settings. In addition, !!INPUT statements can be added to the start-up files to provide additional user or site start-up file capabilities.

Session Files Support in PCLThe purpose of adding session file support to PCL code is to allow a Patran session to be recreated when the session file is played. The sections below describe how an application developer may indicate the PCL commands that need to be recorded and played to duplicate a session. These PCL commands are known as “events of interest.”

Controlling recording file contents

There are tools available to the application developer to control the contents of a session file. They are described in the following sections. In general, it is desired that a session file only contains PCL function calls that affect the database (e.g., open/new/close database, create/modify/delete geometry, etc.). The following sections describe the tools which allow the application developer to control which function calls are recorded and how their parameters should be written to a session file (evaluated or symbolically). Additionally, the issue of recording user rotation events is addressed.

PCL recording directive (>)

The “>” directive is used to indicate that the function call on a line of PCL is an “event of interest.” When these events are executed, they are usually written to the session file. They are also sent to the history window at execution time. In situations where nested “events of interest” occur, only the first/top level event will be written to the session file. This prevents the recording of nested events, which would cause undesirable results. This directive should be placed in column one of a PCL statement.

The intent of this directive is to allow an application that is not invoked from the command line (e.g., forms) to record only those PCL commands that affect the database. In this way, playback can suppress all application dependent user interfacing. Consider the following simple example of PCL code that operates the form to build a grid.

asm_const_grid_xyz( “1”,“[0 0 0]”, “CF 0”,create_grid_xyz_created_ids))

PCL and CustomizationInitializing the Session

36

the > directive is placed on the line containing the call to be recorded as shown:

> asm_const_grid_xyz( “1”, “[0 0 0]”, “CF 0”,create_grid_xyz_created_ids))

If the function is called from the command line or a session file, all the ">" in the function will be ignored. For example,

FUNCTION simpoint() > STRING asm_create_grid_xyz_created_ids[VIRTUAL] > asm_const_grid_xyz( "#", "[1 0 0]", "Coord 0", asm_create_grid_xyz_created_ids ) END FUNCTION

Then execute at the command prompt (or via a session file)

simpoint()

The asm command will not be written to the session file. The reason is that "simpoint( )" is already being written to the session file. If the asm line were written, it would be run twice; once by the simpoint function being called again, and once by the session file itself.

The ">" directive only works if the function is called by a GUI. That is, if an "Apply" button, callback etc. is used in a custom form, then "simpoint()" is not written to the session file, so asm_... is.

Variables in session files

Occasionally, it is desirable to use more than one PCL function call with variables being passed from one function to another. There are two methods to allow this mechanism to work within the confines of a session file.

Combining separate functions

The first method requires the application developer to create a parent function which handles the variable passing from one function to another. This new parent function would be marked as the “event of interest” in the PCL code. For example, assume two functions PCLF1 and PCLF2 are being used. The parameter returned from PCLF1 is passed to PCLF2. This is handled as follows:

FUNCTION PCLF1AND2REAL arg1to2PCLF1 (arg1to2, 45.5, 60, “TRUE”)PCLF2 (arg1to2)END FUNCTION /* PCLF1AND2 */

Variable substitution by name

An alternate method causes Patran to automatically substitute the name of the variable rather than the value of the variable. This is accomplished with the $ directive. By placing the $ before any variable, the variable declaration is automatically written to the session file and the reference is symbolic (the name is used as opposed to its value). The variable declaration is automatically output to the session file. The following example illustrates another technique to handle the previous example.


> PCLF1 ($arg1to2, 45.5, 60, “TRUE”)> PCLF2 ($arg1to2)

Direct writes to the Session File

There are two PCL functions which allow the PCL applications developer to write directly to the session file. They are:

sf_write( string )sf_force_write( string )

The first function writes the string into the session file if session file recording. The second function forces the string into the current session file, assuming one is open and not paused, even if recording would not normally occur, i.e., nested function calls. This second function is probably most useful for either debugging PCL functions or adding comments to session files.

Conditional recording of rotation function calls

Sometimes it is not desirable to record every PCL function call. Some workstations that have hardware graphic accelerators may actually generate hundreds or thousands of function calls for a single user action (e.g., geometry scaling or rotations using a dial). For situations such as these, it is desirable to avoid recording these function calls, as they expand the session file without adding particularly interesting information. There are, however, situations where recording these function calls is desirable. The following PCL function allows the user to optionally record these rotation function calls:

sf_rotation( )

This function call must be executed immediately before the call which performs the rotation. For example:

IF( doit ) THEN sf_rotation()>gm_rot_x( .5 )ENDIF

If the record rotations toggle on the Session File Record form is set, then the call to gm_rot_x is recorded. If the toggle is not set, the function call is not recorded. See Session File Functions, 169 for the location of this toggle.

User controlled conditional recording

There is also a PCL function to allow the user to control recording of the session file. This function allows the user to prevent the next function call from being recorded, based upon the value of its logical argument. The function is:

sf_write_disable ( donext )

If the value of donext is TRUE, then the next function call to be recorded is executed normally, but is not recorded. For example:

sf_write_disable ( not_completed )

Note: Do not start a line with a $ before a variable. Patran recognizes lines that begin with $ as comment lines.


38

> asm_create_patch_xyz ( arg1, arg2 )

In this example, if the value of not_completed is TRUE, then the call to asm_create_patch_xyz is not recorded.

Function calls used as arguments

Although it is sometimes convenient to use the return value from a function as an argument to another function, when using the > directive this should generally be avoided. For example, consider:

> funcx( funcy( x, y, z) )

If session file recording has not been disabled, both funcx and funcy are output. If one level is suppressed, then only funcx is recorded, (funcy recording is suppressed). Note also, that normally funcy gets recorded first, followed by funcx.

Undo support

In order to support the undo feature, applications should insure that all commands that can be written to a session file do not perform any database commits (uil_db_commit) either directly or indirectly (as a consequence of any command). The corresponding PCL code that handles the user interface is expected to perform the commit, passing a string that describes the operation that is about to take place.

Sample PCL Functions with > directive

The following PCL file contains three functions which demonstrate all of the available session file recording controls:

1 FUNCTION sftest2 STRING string1[256], string2[256], string3[256]34 string1 = “FIRST string”5 string2 = “The 2nd string”6 string3 = “This is string 3”78/* Write a line to the session file */9sf_write(“/* Written by ‘sf_write’ */”)1011/* Next function call records in session file */12> sub1 ( string1, string2 )1314/* Record Arg 1 of next func as variable NAME, not VALUE 15> sub1( $string3, string1 )1617/* Record Arg 2 of next func as variable NAME, not VALUE 18> sub2( string2, $string3 )1920/* Demonstrate how nested >’s act */21string3 = “String 3 assigned by sftest”22 sub2 (string2, string3)2324 /* Disable session file recording for the next line */25 sf_write_disable(TRUE)26> sub1 ($string3, string1)27 sf_force_write(“/* Written no matter what!”)2829/* test record rotation functionality */30 sf_rotation()31> ui_writec(“!Recorded only if record rotations is ON”)


32 END FUNCTION /* sftest */3334 FUNCTION sub1 (c, d)35 STRING c[256], d[256]36> UI_WRITEC (“SUB1: Arg1:%s - Arg2:%s\n”, c, d)37 END FUNCTION /* sub1 */3839 FUNCTION sub2 (e, f)40 STRING e[256], f[256]41> sub3 (e, f)42 f = “SUB2 set this string!”43 END FUNCTION /* sub2 */4445 FUNCTION sub3 (g, h)46 STRING g[256], h[256]47 sub3 (g, h)48> UI_WRITEC (“SUB3: Arg1:%s - Arg2:%s\n”, g, h)49 END FUNCTION /* sub3 */

Notes

1. Line 25 prevents line 26 from being recorded in the session file. Line 26 executes normally.

2. Line 30 prevents line 31 from being recorded in the session file if record rotations is off. The default condition is record rotations off. Line 31 always executes normally.

3. Line 36 never appears in the session file because function sub1() is always called from a line which contain the > directive.

4. Line 41 is recorded when function sub2() is called from line 22, but it is not recorded when function sub2 is called from line 18.

The following text is the session file created by the execution of the PCL function sftest() documented above.

1/# Session file recording started: 01/01/1991 00:00:00 2/* Written by ‘sf_write’ */ 3sub1( “FIRST string”, “The 2nd string” ) 4STRING string3[256] 5sub1( string3, “FIRST string” ) 6sub2( “The 2nd string”, string3 ) 7sub3( “The 2nd string”, “String 3 assigned by sftest” ) 8/* Written no matter what! ** 9/# Session file recording stopped: 05/01/1991 12:05:39

Lines 1 and 9 are created by the Session File init and exit functions. They are not passed from one session file to another when playing and recording at the same time.

Line 2 is recorded at execution of SFTEST line 9.


Line 4 is recorded at execution of SFTEST line 15. Because this is the first use of argument ‘string3’ it is declared before it is used as an argument to the call.

Line 5 is also recorded at execution of SFTEST line 15. Note that the first arg is recorded as ‘string3’ rather than the value of ‘string3’ -- this is activated by the $ directive immediately preceding ‘string3’ on line 15.


40

Line 6 is recorded at execution of SFTEST line 18. Note that the second argument is recorded as ‘string3’ rather than the value of ‘string3.’

Line 7 is recorded at execution of line 41 in function sub2. Since sub2 was executed without a > directive, > directives within sub2 are recorded.


The following text is the output created by the execution of the PCL function sftest() documented above.

Output from the PCL function to the startup window:

1. SUB1: Arg1:FIRST string - Arg2:The 2nd string

2. SUB1: Arg1:This is string3 - Arg2:FIRST string

3. SUB3: Arg1:The 2nd string - Arg2:This is string 3

4. SUB3: Arg1:The 2nd string - Arg2:String 3 set by sftest

5. SUB1: Arg1:SUB2 set this string! - Arg2:FIRST string

6. /* Recorded only if record rotations is ON

Line 1 is printed from SUB1 when called from SFTEST line 12.

Line 2 is printed from SUB1 when called from SFTEST line 15.

Line 3 is printed from SUB3 when called from SUB2 line 41, which is called from SFTEST line 18.

Line 4 is printed from SUB3 when called from SUB2 line 41, which is called from SFTEST line 22.

Line 5 is printed from SUB1 when called from SFTEST line 26. Note that SUB1 is called, even though it is not recorded.

Line 6 is printed from SFTEST line 31, but the ui_write call is not recorded in the session file, because the default condition is NOT to record rotations, and the sf_rotation() call on line 30 indicates that line 31 is a rotation function.

The PCL Command Line Interpreter P3PCLCOMP

The executable p3pclcomp provides an interface to a PCL interpreter that can be executed from the command line of a Linux or a Windows command processor.

The p3pclcomp executable functions exactly as the command line for Patran with two main differences. There is no graphics capability, and there is no access to databases. The runtime paths and libraries for p3pclcomp are also different, but this is simply because at start time, $P3_HOME/init.pcl is read by Patran and not by p3pclcomp.

Commands that are supported by p3pclcomp include:

!!input [all known options] !!compile [all known options] !!library [all known options] !!path [all known options]

and most PCL functions that do not deal with graphics or the database.


Possible uses of p3pclcomp include:

Test compiles of PCL function code to check for syntax errors.

Text execution of PCL functions that work without database or graphics, for example, file input and output functions.

The creation and manipulation of PCL function libraries or .plb files.

The p3pclcomp provides a good way to make libraries. A library named make_library.plb can be created using the following commands.

!!compile test.pcl into my_library.plb

The p3pclcomp executable can then be used with input from make_library.plb file.

$P3_HOME/bin/p3pclcomp < make_library.plb

The p3pclcomp executable can also be used to execute PCL commands provided through standard input, listing the results through standard output, allowing p3pclcomp to be used in script and batch files:

echo "!!LIBRARY LIST "make_library.plb | $P3_HOME/bin/p3pclcomp > make_library.lst

This command line will pass the PCL command "!!LIBRARY LIST make_library.plb" through the p3pclcomp executable. The p3pclcomp will create a list of all of the PCL functions included in the make_library.plb file to standard output. Standard output will then be redirected to the file "make_library.lst"

PCL and CustomizationSession Files to PCL Files

42

Session Files to PCL FilesPatran implements the PCL language as a tool used to implement the user interface and much of the functionality presented to the user. As individual tasks are performed by the user the PCL commands used to implement those tasks are listed to a session file with a name such as patran.ses.xx. These session files and the commands listed in them can be used to create custom functions in pcl files to provide new operations. Custom functionality of this type can be used to automate repeated tasks or used to create Tutorial applications.

A custom function can be created by copying a series of commands from a session file into a file with a .pcl extension. As the first line of the file, enter the keyword FUNCTION followed by the custom function's name and the variables that define the inputs and outputs to the function. Place the keyword END FUNCTION at the end of the file.

Most session file commands generated by Patran need to edited to be suitable for general PCL function usage. For instance, values in the arguments to many commands are specific to the recorded session. These should be replaced with variables instead having values returned by preceding function calls. Path and file arguments also have to be modified to be relative rather than absolute. And lines beginning with $# are comments which may be discarded. The PCL file can then be compiled and loaded into Patran, where it can be used like any other PCL function.

We use the following example session file to show this process. It was created by following the "Create the model Geometry step by step" directions of the Clevis Pin Contact Tutorial application.

$# Session file patran.ses.01 started recording at 02-Mar-09 09:55:10 $# FLEXlm initialization complete. Acquiring license(s)... $# Loading dynamic library $# Tutorial version: 2008; Mon Mar 31 13:57:52 PDT 2008; Tutorial shared $# object version: Wed Mar 26 13:52:38 PDT 2008; Tutorial patran version: $# 161062; Tutorial internal version: 31 AAUI.mainpanel_lock_steps() tutorial.setup_app() AAUI.mainpanel_lock_steps() tutorial.setup_app() AAI.html_calls("FUNC:clevis_pin.setup_app") clevis_pin.setup_app() pcc.database_display("pcc.xio","db_open") AAUI.mainpanel_lock_steps() uil_file_new.go( "g:/patran/p3_home/template.db", "d:\tempb\clevis.db" ) $# Copying g:/patran/p3_home/template.db to $# d:\tempb\clevis.db $# Template copy complete. $# Creating journal file d:\tempb\clevis.db.jou at 02-Mar-09 09:55:27 AAI.html_calls("FUNC:pcc.new_db_hide; FUNC:pcc_geo" // @ "m.set_analysis_preference; FUNC:pcc.goto_clevis;S" // @ "TR:pcc_construct_model.xml;STR:pcc.xml;STR:db_not_open") pcc.new_db_hide() pcc_geom.set_analysis_preference() pcc.goto_clevis("pcc_construct_model.xml","pcc.xml","db_not_open") pcc.reset_clevis("pcc_construct_model.xml") AAI.html_calls("FUNC:pcc.goto_geometry;STR:pcc_geometry.xio") pcc.goto_geometry("pcc_geometry.xio") AASTATE.store_objectives() pcc_geom.settings_display(FALSE) $#~ STRING s_cmnd_switch: uil_pref_picking.rectpoly_option( "1","ON" ) AASTATE.store_objectives() pcc_geom.settings_hide() pcc_geom.pref_display(FALSE) $#~ STRING s_cmnd_switch: uil_pref_geometry.switch_value( "25","ON" ) pref_geometry_set_v4( FALSE, TRUE, FALSE, TRUE, 39.370079, FALSE, TRUE ) AASTATE.store_objectives() pcc_geom.pref_hide() pcc_geom.pnt_inner_display(FALSE) STRING asm_create_grid_xyz_created_ids[VIRTUAL]

43Chapter 2: The PATRAN Command Language (PCL) IntroductionSession Files to PCL Files

asm_const_grid_xyz( "1", "[ 1 0 0]", "Coord 0", @ asm_create_grid_xyz_created_ids ) $# 1 Point created: Point 1 AASTATE.store_objectives() pcc_geom.geometry_hide() pcc_geom.rad_inner_display("45.0","0.0",FALSE) STRING sgm_sweep_curve_rev_created_ids[VIRTUAL] sgm_const_curve_revolve( "1", "Coord 0.3", 45., 0., "Coord 0", "Point 1", @ sgm_sweep_curve_rev_created_ids ) $# 1 Curve Created: Curve 1 sgm_const_curve_revolve( "2", "Coord 0.3", 45., 45., "Coord 0", "Point 1", @ sgm_sweep_curve_rev_created_ids ) $# 1 Curve Created: Curve 2 sgm_const_curve_revolve( "3", "Coord 0.3", 45., 90., "Coord 0", "Point 1", @ sgm_sweep_curve_rev_created_ids ) $# 1 Curve Created: Curve 3 sgm_const_curve_revolve( "4", "Coord 0.3", 45., 135., "Coord 0", "Point 1", @ sgm_sweep_curve_rev_created_ids ) $# 1 Curve Created: Curve 4 AASTATE.store_objectives() pcc_geom.geometry_hide() pcc_geom.coord_display(FALSE) STRING asm_create_cord_3po_created_ids[VIRTUAL] asm_const_coord_3point( "1", "Coord 0", 2, "[0 0 0]", "[0 0 1]", "[1 0 0]", @ asm_create_cord_3po_created_ids ) $# 1 Coord created: Coord 1 AASTATE.store_objectives() pcc_geom.geometry_hide() pcc_geom.rad_outer_display(FALSE)

$#~ STRING s_cmnd_switch: sgm_transform_curve_translate.trans_option( "curv","ON" ) $# Warning reported from application Geometry $# Curvilinear transformation requires parametric cubic geometry, $# therefore, an approximation of general curve(s) into parametric cubic(s) $# will occur. The results may not meet your acceptance criteria for accuracy. STRING sgm_transform_curve_created_ids[VIRTUAL] asm_transform_line_translate_1( "5", "<1 0 0>", "Coord 1", 1, TRUE, FALSE, @ "Curve 1 2", sgm_transform_curve_created_ids ) $# The maximum error of 0.000516881 occurred during approximation of general $# curve(s) into Parametric Cubic(s). $# 2 Lines created: Line 5,6 AASTATE.store_objectives() pcc_geom.geometry_hide() pcc_geom.bdy_surf_display(FALSE) STRING asm_create_patch_xy_created_ids[VIRTUAL] asm_const_patch_xyz( "1", "<-4,2,0>", "[-2,0,0]", "Coord 0", @ asm_create_patch_xy_created_ids ) $# 1 Patch created: Patch 1 AASTATE.store_objectives() pcc_geom.geometry_hide() pcc_geom.bdy_crv_srf_display("Curve~1~2","Curve~5~6",FALSE) STRING sgm_surface_2curve_created_ids[VIRTUAL] sgm_const_surface_2curve( "2", "Curve 1 2", "Curve 5 6", @ sgm_surface_2curve_created_ids ) $# 2 Surfaces Created: Surfaces 2,3 AASTATE.store_objectives() pcc_geom.geometry_hide() pcc_geom.bdy_crv_srf_display("Curve~4","Surface~1.1",FALSE) STRING sgm_surface_2curve_created_ids[VIRTUAL] sgm_const_surface_2curve( "4", "Curve 4", "Surface 1.1", @ sgm_surface_2curve_created_ids ) $# 1 Surface Created: Surface 4 AASTATE.store_objectives() pcc_geom.geometry_hide() pcc_geom.bdy_crv_srf_display("Curve~3","Construct~2PointCurve(Evaluate~Geo" // @ "metry(Point~8))(Evaluate~Geometry(Point~10))",FALSE) STRING sgm_surface_2curve_created_ids[VIRTUAL] sgm_const_surface_2curve( "5", "Curve 3", @ "Construct 2PointCurve(Evaluate Geometry(Point 8))(Evaluate Geometry(Point" // @ " 10))", sgm_surface_2curve_created_ids ) $# 1 Surface Created: Surface 5 AASTATE.store_objectives() pcc_geom.geometry_hide() pcc_geom.solid_display(FALSE) STRING sgm_sweep_solid_nor_created_ids[VIRTUAL] sgm_const_solid_normal( "1", "0.25", "", "", "", FALSE, "Surface 1:5", @ sgm_sweep_solid_nor_created_ids ) $# 5 Solids Created: Solids 1:5 AASTATE.store_objectives()


44

pcc_geom.geometry_hide() pcc_geom.mirror_bot_display(FALSE) STRING sgm_transform_solid_created_ids[VIRTUAL] ge_transform_mirror( "6", "solid", "Coord 0.2", 0., TRUE, FALSE, "Solid 1:5", @ sgm_transform_solid_created_ids ) $# 5 Solids Created: Solids 6:10 AASTATE.store_objectives() pcc_geom.geometry_hide() pcc_geom.remain_solid_display(FALSE) $#~ STRING s_sel_cmnd: sgm_transform_trans_cart.eval_magnitude("VALUE_CHANGED") STRING sgm_transform_solid_created_ids[VIRTUAL] ge_transform_translate_v1( "11", "solid", "<0,0,-1>", 0.25, FALSE, "Coord 0", @ 2, FALSE, "Solid 1 6", sgm_transform_solid_created_ids ) $# 4 Solids Created: Solids 11:14 AASTATE.store_objectives() pcc_geom.geometry_hide() pcc_geom.remain_clevis_display(FALSE) $#~ STRING s_sel_cmnd: sgm_transform_trans_cart.eval_magnitude("VALUE_CHANGED") STRING sgm_transform_solid_created_ids[VIRTUAL] ge_transform_translate_v1( "15", "solid", @ "Construct 2PointVector(Evaluate Geometry(Point 10))(Evaluate Geometry(Poi" // @ "nt 40))", 0.5, FALSE, "Coord 0", 1, FALSE, "Solid 2:5 7:10", @ sgm_transform_solid_created_ids ) $# 8 Solids Created: Solids 15:22 uil_file_close.goquit( ) $# Journal file stopped recording at 02-Mar-09 09:58:21 $# Session file patran.ses.01 stopped recording at 02-Mar-09 09:58:21

Delete all unneeded functions such as "AASTATE.XXX", "AAUI.xxx", "AAI.xxx" and "pcc_xxx.xxx" before copying the rest to a file with a .PCL extension. Enclose the code with "FUNCTION" and "END FUNCTION" keywords.

In the example, since we want to define the 3d location of the clevis and the diameter of its hole, we name the function create_clevis and make it take in r_dia, r_x, r_y, r_z as inputs.

Most of the editing is to replace hard-coded geometry ids with the id values returned by function calls used to make the preceding geometry.

Note that this function is incomplete. Some of the items that could be added to this function are:

• Inputs to control the orientation of the clevis.

• Inputs to control the size of the clevis.

• Outputs to list the solids created by this function.

• Error handling. FUNCTION create_clevis ( r_dia, r_x, r_y, r_z ) REAL r_dia REAL r_x REAL r_y REAL r_z INTEGER i_end INTEGER i_strt REAL r_base_x REAL r_base_y REAL r_base_z STRING coord_id_01 [VIRTUAL] STRING coord_id_02 [VIRTUAL] STRING created_ids [VIRTUAL] STRING curve_id_1 [VIRTUAL] STRING curve_id_2 [VIRTUAL] STRING curve_id_3 [VIRTUAL] STRING curve_id_4 [VIRTUAL] STRING curve_id_56 [VIRTUAL] STRING deleted_ids [VIRTUAL] STRING line_ids [VIRTUAL] STRING point_id [VIRTUAL] STRING s_temp [VIRTUAL] STRING s_vect [VIRTUAL] STRING solid_ids [VIRTUAL]


STRING solid_ids_16 [VIRTUAL] STRING solid_ids_610 [VIRTUAL] STRING solid_ids_lst [VIRTUAL] STRING surface_id_1 [VIRTUAL] STRING surface_id_15 [VIRTUAL] s_temp = "[" // str_from_real ( r_x ) s_temp = s_temp // " " // str_from_real ( r_y ) s_temp = s_temp // " " // str_from_real ( r_z ) // "]" # Create a throw away surface to help in the construction # of a coordinate system used to locate the clevis. # The "#" in the first argument tells the function # to use the next available surface id. asm_const_patch_xyz ( "#", "<1 1 0>", s_temp, "Coord 0", surface_id_1 ) # Create a rectangular coordinate system for a starting point # This will make it easier to set the origin of our clevis. asm_const_coord_normal_v2( "#", "Coord 0", surface_id_1, 1, s_temp, TRUE, coord_id_01 ) asm_delete_surface( surface_id_1, deleted_ids ) s_temp = "[" // str_from_real ( r_dia ) s_temp = s_temp // " 0 0]" # Create a starting point for an initial curve. asm_const_grid_xyz( "#", s_temp, coord_id_01, point_id ) # Create the curves for the inner part of the clevis sgm_const_curve_revolve( "#", coord_id_01 // ".3", 45., 0., coord_id_01, point_id, curve_id_1 ) sgm_const_curve_revolve( "#", coord_id_01 // ".3", 45., 45., coord_id_01, point_id, curve_id_2 ) sgm_const_curve_revolve( "#", coord_id_01 // ".3", 45., 90., coord_id_01, point_id, curve_id_3 ) sgm_const_curve_revolve( "#", coord_id_01 // ".3", 45., 135., coord_id_01, point_id, curve_id_4 ) # Delete the no longer needed initial point. asm_delete_point( point_id, deleted_ids ) # Construct a cylindrical coordinate system for use as another construction tool. asm_const_coord_3point( "#", coord_id_01, 2, "[0 0 0]", "[0 0 1]", "[1 0 0]", coord_id_02 ) r_base_x = 2.0 - r_dia s_temp = "<" // str_from_real ( r_base_x ) s_temp = s_temp // " 0 0>" # Construct the outer radius curve for the clevis asm_transform_line_translate_1( "#", s_temp, coord_id_02, 1, TRUE, FALSE, curve_id_1 // " " // curve_id_2, line_ids ) asm_delete_coord( coord_id_02, deleted_ids ) i_end = str_length ( line_ids ) i_strt = str_index ( line_ids, " " ) s_temp = str_substr ( line_ids, i_strt, i_end ) i_strt = str_to_integer ( s_temp ) curve_id_56 = "Curve " // str_from_integer ( i_strt ) // " " i_strt = str_index ( line_ids, "," ) + 1 s_temp = str_substr ( line_ids, i_strt, i_end ) i_strt = str_to_integer ( s_temp ) curve_id_56 = curve_id_56 // str_from_integer ( i_strt ) # Construct a surface that will be used to define the body of the clevis. # The vector and location for this surface do no need to be adjusted # as they are relative to the constructed coordinate system # used to locate the clevis. asm_const_patch_xyz( "#", "<-4 2 0>", "[-2 0 0]", coord_id_01, created_ids ) i_end = str_length ( created_ids ) i_strt = str_index ( created_ids, " " ) s_temp = str_substr ( created_ids, i_strt, i_end ) i_strt = str_to_integer ( s_temp ) surface_id_1 = "Surface " // str_from_integer ( i_strt ) sgm_const_surface_2curve( "#", curve_id_1 // " " // curve_id_2, curve_id_56, created_ids ) s_temp = surface_id_1 // ".1" sgm_const_surface_2curve( "#", curve_id_4, s_temp, created_ids ) r_base_x = r_x r_base_y = r_y + 2.0 r_base_z = r_z s_vect = "[" // str_from_real ( r_base_x ) s_vect = s_vect // " " // str_from_real ( r_base_y ) s_vect = s_vect // " " // str_from_real ( r_base_z ) // "]" r_base_x = r_x + -2.0


46

r_base_y = r_y + 2.0 r_base_z = r_z s_temp = "[" // str_from_real ( r_base_x ) s_temp = s_temp // " " // str_from_real ( r_base_y ) s_temp = s_temp // " " // str_from_real ( r_base_z ) // "]" # Create a line to help construct the last surface. # This line replaces # "Construct 2PointCurve(Evaluate Geometry(Point 8))(Evaluate Geometry(Point 10))" # in the session file. asm_const_line_2point( "#", s_vect, s_temp, 0, "", 50., 1, created_ids ) i_end = str_length ( created_ids ) i_strt = str_index ( created_ids, " " ) s_temp = str_substr ( created_ids, i_strt, i_end ) i_strt = str_to_integer ( s_temp ) s_temp = "Curve " // str_from_integer ( i_strt ) sgm_const_surface_2curve( "#", curve_id_3, s_temp, created_ids ) asm_delete_curve( curve_id_1, deleted_ids ) asm_delete_curve( curve_id_2, deleted_ids ) asm_delete_curve( curve_id_3, deleted_ids ) asm_delete_curve( curve_id_4, deleted_ids ) asm_delete_curve( curve_id_56, deleted_ids ) asm_delete_curve( s_temp, deleted_ids ) i_end = str_length ( created_ids ) i_strt = str_index ( created_ids, " " ) s_temp = str_substr ( created_ids, i_strt, i_end ) i_strt = str_to_integer ( s_temp ) surface_id_15 = surface_id_1 // ":" // str_from_integer ( i_strt ) sgm_const_solid_normal( "#", "0.25", "", "", "", FALSE, surface_id_15, solid_ids ) asm_delete_surface( surface_id_1, deleted_ids ) asm_delete_surface( surface_id_15, deleted_ids ) ge_transform_mirror( "#", "solid", coord_id_01 // ".2", 0., TRUE, FALSE, solid_ids, solid_ids_610 ) i_end = str_length ( solid_ids ) i_strt = str_index ( solid_ids, " " ) s_temp = str_substr ( solid_ids, i_strt, i_end ) i_strt = str_to_integer ( s_temp ) solid_ids_16 = "Solid " // str_from_integer ( i_strt ) i_end = str_length ( solid_ids_610 ) i_strt = str_index ( solid_ids_610, " " ) s_temp = str_substr ( solid_ids_610, i_strt, i_end ) i_strt = str_to_integer ( s_temp ) solid_ids_16 = solid_ids_16 // " " // str_from_integer ( i_strt ) ge_transform_translate_v1( "#", "solid", "<0,0,-1>", 0.25, FALSE, coord_id_01, 2, FALSE, solid_ids_16, created_ids ) i_end = str_length ( solid_ids ) i_strt = str_index ( solid_ids, " " ) s_temp = str_substr ( solid_ids, i_strt, i_end ) i_strt = str_to_integer ( s_temp ) i_strt = i_strt + 1 solid_ids_lst = "Solid " // str_from_integer ( i_strt ) // ":" i_end = str_length ( solid_ids ) i_strt = str_index ( solid_ids, ":" ) + 1 s_temp = str_substr ( solid_ids, i_strt, i_end ) i_strt = str_to_integer ( s_temp ) solid_ids_lst = solid_ids_lst // str_from_integer ( i_strt ) // " " i_end = str_length ( solid_ids_610 ) i_strt = str_index ( solid_ids_610, " " ) s_temp = str_substr ( solid_ids_610, i_strt, i_end ) i_strt = str_to_integer ( s_temp ) i_strt = i_strt + 1 solid_ids_lst = solid_ids_lst // str_from_integer ( i_strt ) // ":" i_end = str_length ( solid_ids_610 ) i_strt = str_index ( solid_ids_610, ":" ) + 1 s_temp = str_substr ( solid_ids_610, i_strt, i_end ) i_strt = str_to_integer ( s_temp ) solid_ids_lst = solid_ids_lst // str_from_integer ( i_strt ) ge_transform_translate_v1( "#", "solid", "<0,0,-1>", 0.5, FALSE, coord_id_01, 1, FALSE, solid_ids_lst, created_ids ) asm_delete_coord( coord_id_01, deleted_ids ) END FUNCTION


Finally, the function can be compiled and run using a session file as follows:

uil_file_close.go ( ) uil_file_new.go( "", "db_session_to_pcl.db" ) $? YES 36000002 ga_viewport_location_set ( "default_viewport", 0.0, 0.0, 1 ) ga_viewport_size_set ( "default_viewport", 4.5, 4.5, 1 ) $# In this example, we saved the file as demo_func.pcl !!compile demo_func.pcl into demo_lib.plb !!library demo_lib.plb create_clevis ( 1.0, 1.0, 5.0, 1.0 ) create_clevis ( 0.5, 0.0, 0.0, 0.0 ) gu_fit_view ( )


48

2 the patran command language (pcl) introduction€¦ · · 2015-03-311991-05-01 · process the...

Documents