Object-Oriented KID

<<< LISP in KID

Chapters

Calling the KI/PK Using KID (FLICK) >>>

Contents

• 3.1 Object oriented programming
  • 3.1.1 Objects and message passing
  • 3.1.2 Parasolid PK functions and KI routines
• 3.2 KID journal file
• 3.3 Starting and stopping the kernel
• 3.4 Parasolid journal file
• 3.5 Rollback during a modeling session
• 3.6 Defining KID objects
• 3.7 Combining tags of KID objects
• 3.8 Receive and transmit
• 3.9 Help
• 3.10 Options

[back to top]

3.1 Object oriented programming

In any object oriented programming environment, an object is used to represent a collection of data and functions. An object can be used to represent a real thing or an abstract idea.

All the information concerning an object, including the functions necessary to manipulate it, are kept within the object. The principles of object orientated programming have been exploited in many languages, PARASOLID LISP has been extended by the inclusion of object oriented functions and these are used extensively within KID.

[back to top]

3.1.1 Objects and message passing

Objects are LISP entities. They consist of some data and a set of operations. The nature of an object's operations depends on the nature of the component it represents. An object representing data structures might store and retrieve information, an object representing a solid body might answer enquiries about its relationships to its component faces and edges, or might perform operations on itself to modify its shape or position in space.

In KID objects are arranged in a predefined hierarchical class structure, see Appendix A, "KID Class Structure".

A message is a request for an object to carry out one of its operations, it specifies which operation is desired, but not how that operation is carried out. The object to which the message was sent determines how that operation should be carried out. A crucial property of messages is that they are the only way to invoke an object's operations.

Operations in KID are generally carried out by passing to the command-line interface messages of the following form:

( object function argument1 argument2 ... )
( object property argument )

[back to top]

3.1.2 Parasolid PK functions and KI routines

Many LISP functions and object operations call a Parasolid PK Function or KI Routine. This provides a convenient, version-independent method of using Parasolid in KID. If timing data is being output (the default action), the name of the function or routine is also output.

• As the Parasolid PK Interface is developed, many operations are being changed to use the PK function equivalent of the KI routine they previously called, but this change is transparent to the user.

[back to top]

3.2 KID journal file

KID opens a journal file with the name kid.jou and journals all KID commands in this file, which can be renamed before another session is started. It should be possible to reproduce the original operations by loading this file in a subsequent KID session. If the file extension is changed to .lsp then it is not necessary to specify it in the argument to load.

> (load "bug_27.jou")       -- file is bug_27.jou
> (load ´bug_27)            -- file is bug_27.lsp
> (load "bug_27" ´reflect)  -- commands used are shown
> (load ´bug_27 ´verify)    -- commands and returns are shown

When a graphical pick is made with the cursor, a point and a direction are recorded. These vectors are written to the journal file and are used when replaying the journal file so no user interaction is needed.

[back to top]

3.3 Starting and stopping the kernel

The kernel is started and stopped using functions of the object modeller, which are pre-defined within the KID class structure.

In the following example, KID is instructed to perform the function start (which requires no arguments) on the object modeller . This has the effect of calling the Parasolid KI routine STAMOD.

Normally the start function should be called before doing anything else.

start function

> (modeller start)

and to stop the modeller:

stop function

> (modeller stop)

[back to top]

3.4 Parasolid journal file

When the kernel is started using (modeller start), a Parasolid journal file is opened, with the default name kid.jnl_txt. This records all the Parasolid PK functions and KI routines called in a KID session, with their received and returned arguments.

The journal file is useful if unexpected errors occur, as it can be inspected to see what functions have been called and when the error occurred.

All GO (Graphical Output) functions are now logged in the journal file. It should be noted that this:

• generates very large files
• increases the KID session elapsed time

Therefore, it is recommended that Parasolid journalling is turned off unless it is required in a particular modeling session.

Journalling options available before (modeller start)

> (option journal t)           -- enables journalling (default)
> (option journal_file "f1_b0")  -- enables journalling, using
                                    this journal file
> (option journal nil)           -- disables journalling

> (option journal)            --> returns whether or not a
                                 journal is being kept
> (option journal_file)       --> returns the journal file name

Journalling options available after (modeller start), if journalling is enabled

> (option journal t)          -- toggles journalling on
> (option journal nil)        -- toggles journalling off

> (option journal)            --> returns whether or not a
                                 journal is being kept
> (option journal_file)       --> returns the journal file name

[back to top]

3.5 Rollback during a modeling session

The function mark provides the means to set marker points in the modeling session, to which it is possible to:

• roll back using roll, thereby undoing everything performed since the last mark was set
• roll forward, after you have previously rolled back, to retrace your steps between operations

mark

> (modeller mark) 
     -- generates a mark name, e.g. mark5, mark6, etc.

roll

> (modeller roll) -- returns to the most recent mark)

When setting a mark you can specify a name for it, and then you can roll to that specifically named mark (or a system defined name, e.g. mark6).

> (modeller mark ´start_here )
   ....
> ( modeller roll ´start_here )

Live KID objects can be rolled back in synchrony with the kernel. Define body, face, edge to be types of KID objects you want managed as follows:

> (modeller roll_class ´( body face edge ) )

No KID object is created or undefined during a rollback, but those objects in the defined roll_class have their tag values updated.

Graphics is kept in step by honoring the current tag values of the objects it is being asked to display.

Only the kernel (without affecting KID objects) is rolled backward/forward, therefore, when a rollback is to a state before the creation of a body in the kernel, KID still acknowledges its existence, while the kernel does not - an error results if any modeling operation referring to such a body is attempted. Conversely if a kernel item has been deleted since the rollmark was set and its corresponding KID object undefined, after a rollback the kernel acknowledges the item's existence, but KID does not.

> (modeller mark)
> (define b0 p_block)
> (b0 x 10; y 20; z 30; create)
> (b0 is)           --> returns body
> (modeller roll)   --> rolls back the kernel
> (b0 is)           --> returns body
> (b0 enquire)      --> returns an error from the kernel

[back to top]

3.6 Defining KID objects

define

In LISP an identifier has a value given it by setq or defun . In object oriented LISP a special function, defun , is used to create an object which returns the identifier of the object.

> ( define b0 body )  -- defines a KID object with the `b0´
                         which belongs to the class `body´

In the above example, no Parasolid entity has been created, only a KID entity.

undefine

To undefine a previously defined KID object:

> ( undefine b0 )     -- undefines the KID object `b0´

redefine

To redefine a previously defined KID object as another class:

> ( redefine b0 assembly )  -- redefines the KID object `b0´ in 
                               the class `assembly´

[back to top]

3.7 Combining tags of KID objects

include, remove

The function include combines the tags contained in the specified KID objects, so that the KID object refers to more Parasolid entities. The function remove removes the specified entities from a KID object. The KID objects must be of the same type.

> (e0 tag)
( 46 50 54 )
> (e1 tag)
( 83 80 )
> (e0 include e1)
( 83 80 46 50 54 )
> (e0 remove e1)
( 46 50 54 )

[back to top]

3.8 Receive and transmit

receive, transmit and state functions

The part class and its subclasses, assembly and body, can be received and transmitted. Text files are used unless changed by the appropriate option setting.

> (define b0 body)      -- the object must be defined before
                        -- before the function can be used
> (define b1 body)
> (b0 receive "b0")          -- receives the file b0.xmt_txt
> (b1 receive "flt4453.xmt") -- receives the file flt4453.xmt
                  -- the extension must be given for .xmt files

> (b0 transmit "b0")    -- transmits the object to the file 
                     -- b0.xmt_txt,overwriting original version
> (b0 transmit "file1") -- transmit body to new file
> (define pump body)
> (pump receive "p9423") -- receives an existing body

Both the receive and transmit functions take a single argument, the key of the relevant part.

[back to top]

3.9 Help

help function

help returns useful information about an object and its functions.

> (modeller help resabs) --> linear resolution in the modeller

> (body help) --> list of valid messages and descriptions

> (b0 help) --> list of valid messages and descriptions

> (p_cone help create) 
            --> create function properties for primitive p_cone

> (face help rmfaso ) 
            --> function rmfaso of object face and arguments

> (b1 help transmit) 
            --> how to use transmit function for body b1

[back to top]

3.10 Options

The option class contains functions which control the interface to the kernel. These functions:

• affect the options when the modeller is started;
• change them (if it can) while the modeller is running or store them until they can be changed.

The current setting of any option may be enquired by calling the function without any arguments. If the option has not been set then the default value is returned. Text files are the default for part files and binary files for snapshots. The use of these options is shown below.

> (option journal "f1_b0") -- if this is done before starting, 
                   the kernel will start with this journal file

> (option journal) 
             --> returns whether or not a journal is being kept

> (option journal_file) --> returns the journal file name

> (option logging [nil | ´ki | ´pk | +ve | -ve )
             -- switch off/on logging with required options set

> (option enquire) --> <list of current settings>

> (option check t) 
       -- switch on local checking, this is the default setting

Options for receive and transmit

Part receive and transmit use the values in the appropriate flags:

(option help receive) --> information

(option receive ´binary) -- binary receive

(option transmit ´text) -- text transmit, default setting

(option transmit ´neutral -- machine independent, binary format

These are initialized in (modeller start) to the global value set using (option receive) and (option transmit):

> (option pk_session_receive)

> (option pk_session_transmit ´binary)

Option check for local operation

When a local operation is performed, there are sometimes a number of possible solutions. When the option check is set to t , each solution is reviewed and checked in the resolution of ambiguous cases. If not set, the first solution is picked.

> (option check t)     -- default setting for local checking on
> (option check nil)   -- local checking off

If local checking has been turned off, an illegal solution is not detected until a complete body check is subsequently done, thus losing a possible legal solution for the local operation, and leaving the body in an invalid state.

> (option pk_session_local_checking)

This local checking flag is initialized in (modeller start) to the global value set using (option check). It is used in various KID functions where the underlying PK function requires the local checking flag.

Options for rollback

The switching on/off of the roll mark facility is controlled by the logging properties. The logging properties that can be set when switching on the logging option are:

• ki or pk or proll (the default) - to select the appropriate rollback system.
• +integer (+ve) - to select KI rollback with the given file size. The file size is specified using the option logging_size .
• -integer (-ve) - to select the PK rollback with the given maximum number of live marks. The maximum number of live rollmarks can be set using the logging_number option (default number is 20).

The roll mark facility creates session marks only. To model in partitions and create partition marks, the appropriate PK functions must be called directly, using the PK FLICK interface. For further details on how to do this, see Chapter 4, "Calling the KI/PK Using KID (FLICK)".

option user_field

The option user_field function is used to set up the user field length which is passed to STAMOD via modeller start . The user field length can not be changed while the modeller is running, however, option user_field does store the current setting

.

> (option user_field 0)

> (option user_field 12)

> (option user_field)

Options reset by new modeling session

It is now possible to specify some options which only persist for a modeling session, i.e. they are reset by (modeller stop;start) . Currently there are only four such options:

(option pk_session_tolerance)
(option pk_session_receive)
(option pk_session_tansmit)
(option pk_session_local_checking)

If the general values are modified these changes are passed on to the session values immediately, for example:

(option receive ´binary)

(option pk_session_receive)

(option pk_session_receive ´text)

(option pk_session_receive)

(option receive)

(modeller stop;start)

(option pk_session_receive)

(option receive ´text)

(option pk_session_receive)

Tolerance setting

The tolerance setting is required by various PK boolean and local operation functions and defaults to 0.000001.

(option pk_tolerance)

(option pk_tolerance 0.001)

(option pk_tolerance)

(option pk_tolerance nil)

(option pk_session_tolerance)

(option pk_session_tolerance 0.1)

(option pk_session_tolerance)

(option pk_tolerance 0.001)

(option pk_session_tolerance)

(option pk_session_tolerance nil)

(option pk_session_tolerance)

(option pk_tolerance)

[back to top]