; 3D PartStream Studio
Documents
Resources
Learning Center
Upload
Plans & pricing Sign in
Sign Out
Your Federal Quarterly Tax Payments are due April 15th Get Help Now >>

3D PartStream Studio

VIEWS: 13 PAGES: 30

  • pg 1
									                                  3D PartStream.NET Studio

The 3D PartStream.NET studio is a development environment that allows the authoring and
testing of XML based rules (see below for details on XML based rules authoring).

Projects

The studio works with project files. A project file defines the XML rules files as well as any
other dependent files, such as the related SolidWorks model. It also holds onto all custom
environment settings that the user has set for the particular project. The studio can multiple
projects open at any time and each open project in the studio is represented by its own window.

To define a new project:
   1. Select one of the following to initiate a new project operation:
           a. Select ‘File->New->Project’ from the main menu
           b. Pick the ‘New Project’ standard toolbar button.
   2. The New Project File dialog appears. Select a folder and filename to save the project to
       and pick Save.
   3. The ‘Rules Filename’ dialog displays. Every project needs a rules document. This dialog
       allows you to either select an existing rules document or make a new rules document to
       associate with the project. In this case, select ‘Make a new rules filename of name:’ and
       enter your desired rules document filename. Select OK.
   4. A new MDI window is created that contains the project.

To open an existing project:
   1. Select one of the following to initiate a open project operation:
          a. Select ‘File->Open->Project’ from the main menu
          b. Pick the ‘Open Project’ standard toolbar button
          c. Pick the ‘Open Project’ button on the header of the ‘Project Explorer’ task pane.
   2. The Select Project File dialog appears. Browse to the folder and select an existing project
      filename. Pick Open.
   3. A new MDI window is opened that contains the project.

Project Explorer Task Pane

The project explorer task pane lists all the open projects. It can be turned on and off via the
‘View->Project Explorer’ main menu item. The root items in the project explorer tree is the open
project names and the child items are the dependent items for the project, including the XML
rules document, the SolidWorks model, etc. Each project in the project tree will have an
associated MDI project window. Selection of the project name in the project tree activates its
associated project window.

Project MDI Window

Each open project in the studio has its own MDI project window. The project window contains 2
tabbed views: the XML rules source editor and the Test UI view.
XML Rules Source Editor

The XML rules source editor within the project window is a fully functional editor that allows
editing of the rules document associated with the project. Any edits made to the XML rules
source will automatically update the test UI view.

Test UI View

The test UI view within the project window allows access to numerous testing and QA
operations. The view is a 3 pane splitter window. The top pane, or header, contains numerous
testing buttons. The second pane contains the UI display of the associated rules document. The
bottom pane is the output window for various types of operations.

       Header View

               ‘Parameters’
               Selection of the parameters button will display the current values of any defined
               <swparameters> in the rules document.

               ‘Recursive Solve’
               The recursive solve button will start a recursive solve of the current rules
               document. A recursive solve is a procedure in which every possible combination
               of values is selected within the rules document. Each solve within a recursive
               solve will be displayed in the output window.

               ‘Count Total’
               The count total button will calculate all the possible combinations of values that
               can be selected in the rules document. The total count will be displayed in the
               output window.

               ‘Update External Design Table’
               The update external design table button will make a copy of the SolidWorks
               master design table and then drive it with the current rule values, creating
               additional informative worksheets containing the results of the operation.
               SolidWorks must be running and the model associated with the current rules must
               be the active document before starting this operation. A filename dialog will
               appear before the operation starts requesting the name of the external design table
               filename to use. If a name is entered without a path, then the specified filename
               will be created in the same folder where the project file resides. The steps of
               operations are as follows:
               1. The design table is extracted from the active model of the active SolidWorks
                   session and saved to the specified filename.
               2. The current values of all defined <swparameter> entries are written to the
                   external design table. The external design table solves with these new values.
3. A new sheet is made in the external design table called
   ‘RulesParameterValues’. This sheet contains the rules source parameters and
   values used in the solve.
4. A new sheet is made in the external design table called ‘RulesDTInput’. This
   is a copy of the actual design table, but with just the source parameter values
   (IE, <swparameter>) that were used in the design table.
5. A new sheet is made in the external design table called ‘RulesDTOutput’.
   This is a copy of the actual design table that was solved after the source
   parameter values (IE, <swparameter>) were passed into it.

‘Update Model’
The update model button will pass the current rule values to the design table
active model of the active running SolidWorks. It will then update the model
based upon the design table changes. SolidWorks must be running and the model
associated with the current rules must be the active document before starting this
operation. Any errors will be displayed in the output window.

‘QA Test’
The QA test button displays the QA test dialog which allows for more extensive
QA operations including recursive and random solving and writing output to
various output formats. The main items of this dialog are:
 - ‘Edit Values for Solving’
        o All Edit type parameters that are defined in the rules document will be
            in the droplist. For each of these Edit parameters, you can define any
            number of default values to be used with the parameter when the rules
            is solved
 - ‘Range Values for Solving’
        o All Range type parameters that are defined in the rules document are
            listed in the 1st column of the grid. For each of these Range
            parameters, you can specify what default value(s) should be used with
            the parameter when the rules is solved by selecting the appropriate
            check box as follows:
                  Default – Uses an acceptable default value for the Range
                     parameter. It will most likely be the lowest value of the Range
                     definition.
                  Low – Uses the lowest value of the current Range definition
                  Mid – Uses the mid value of the current Range definition
                  High – Uses the highest value of the current Range definition
                Any combination of Low, Mid and High can be selected.

-   ‘What type of QA process do you want to do:’
      o This determines the main QA operation as follows:
               Drive rules only
                      Only exercises the rules, does not drive any
                        SolidWorks model, design table or external design
                        table.
                  Drive external design table
                       Exercises the rules, creates and drives an external
                          design table. SolidWorks must be running and the
                          model associated with the current rules must be the
                          active document in order to use this operation. For
                          further details on an external design table, see above
                          description on the ‘Update External Design Table’
                          button found in the header view.
                  Drive SolidWorks design table and update model
                       Exercises the rules, updates the SolidWorks design
                          table and updates the SolidWorks model. SolidWorks
                          must be running and the model associated with the
                          current rules must be the active document in order to
                          use this operation. For further details on this operation,
                          see above description on the ‘Update Model’ button
                          found in the header view.

-   ‘What type of iteration of the parameters do you want to do:’
      o This determines how many times you want to do the main operation
           as follows:
                Just once based upon the current rules settings
                        Does just 1 rule solve based upon the current settings
                           of the rules in the rules UI view.
                Recursive – complete
                        Complete exercises all possible solves of the current
                           rules document.
                Recursive – random number
                        Exercises a specified random number of solves of the
                           current rules document.

-   ‘ Where do you want the results to be displayed:’
       o Determines where the output of the operation will be written to as
          follows:
               Show results in IDE output window
                      Writes all output to the output window. You have the
                         option of just writing errors only by checking on the
                         sub item ‘Show errors only’
               Output to filename:
                      Write all output to the specified filename. Output can
                         be written to either a text or Excel format file (see
                         Options description). If a filename is entered without a
                         path, then the specified filename will be created in the
                         same folder where the project file resides. You have
                         the option of just writing errors only by checking on
                         the sub item ‘Show errors only’
       Rules UI View

              The rules UI view displays the current rules.

       Output View Window

              The output window displays any required output produced by the testing and QA
              operations.


Options

The 3D PartStream.Net Studio options are accessed via the ‘Tools->Options’ main menu item.
When selected, the options dialog appears. Option settings are:

              -   Reload model on each solve
                     o When QA testing in either recursive complete or recursive random
                          and updating the SolidWorks model, the model will be reloading on
                          each solve if this is checked on.
              -   Restart SolidWorks on each solve
                     o When QA testing in either recursive complete or recursive random
                          and updating the SolidWorks model, Solidworks will be restarted and
                          the model will be reloading on each solve if this is checked on.
              -   Stop on solve errors when recursive or random solving
                     o Execution will stop on the first rules solve error if this is checked on
              -   Stop on model errors when recursive or random solving
                     o Execution will stop on the first model error if this is checked on
              -   Output results in Excel spreadsheet
                     o If checked on, any output requested to a file will be written to an
                          Excel spreadsheet. If not checked, the default format will be a text
                          file.
              -   Load last project on startup
                     o If checked, the studio will automatically load all the projects that were
                          open the last time the studio was shut down.
              -   Show line numbers on XML documents
                     o If checked, line numbers will be displayed on the left side of the XML
                          rules source editor view
                              Rules XML document format

Overview

This document explains how to create a rules document for use with a 3DPartStream model. The
rules document describes the user interface, or “questions” you wish to ask in order to configure
a model. It also contains the choices for these “questions”, typically in the form of “core data”.

The rules document is made up of the following sections:

   1)   Check dimensions
   2)   Settings (optional)
   3)   Rule definitions
   4)   Core data tables

A Rules document has the following structure:

<rules_data>
    <checkdimensions>
      <dimension>D1@Layout_Horizontal</dimension>
      <dimension>Worm_Case_Limit@Layout_Horizontal</dimension>
      <dimension>Housing-1/D1@Sketch4</dimension>
      <dimension>Housing-2/D1@Sketch4<dimension>
    </checkdimensions>
    <settings>
       <showdefaultrangevalues>3</showdefaultrangevalues>
    </settings>
    <rules>
       <rule_def id=”??”>
       </rule_def>
       <rule_def id=”??”>
       </rule_def>
       .
       .
       .
    </rules>
    <core_data_tables>
       <core_data_table id=”??”>
       </core_data_table>
       <core_data_table id=”??”>
       </core_data_table>
       .
       .
       .
    </core_data_tables>
</rules_data>


The optional check dimensions element is only used by 3D PartStream Studio and defines
dimensions to check when QA testing SolidWorks models in the studio.

The optional settings element contains optional child elements to set certain global conditions of
the rules.
The rules element contains multiple rule_def elements and the core_data_tables element contain
multiple core_data_table elements.

All sections are children of the root element, rules_data.

Solving

The purpose of creating a rules document is to provide the user a mechanism to choose valid
values for configuring a model. This is done by “solving” the rules document. Solving is done
on the PartStream server, using the XML Interface, or in a testing environment by using the
rules document directly in the rules testing application.

The rules document is solved in a “top-down” manner – meaning the rule definitions are sorted
by ID, and solved in that order.

Solving creates a list of rule definitions with each having a valid result set. The result set can be
one of the following:
   a) A single, fixed value
   b) A list of values
   c) A range specification

The result set also contains a current value.

Initial Solve

If the result set contains multiple values, the current value will be the first value in the list. If the
result set is a range specification, the current value will be empty.

Subsequent Solve

The results of a solve are typically displayed in a HTML page, in the form of input and select
elements. When the user changes a value in one of these controls, a “resolve” is required.
Resolving consists of posting a list of rule name/value pairs to the partstream server, using the
SwGetParamValues interface.


Check Dimensions

The optional <checkdimensions> element is only used by 3D PartStream Studio. It allows the
specification of dimensions that will be checked after every update of a SolidWorks model when
QA testing within the studio.

The child <dimension> elements specify the actual names of the dimensions to check. They can
be root level model dimensions or dimensions in child models of the root model. To specify
child models, then name of the child model(s), including any multiple instance number, is
specified before the actual check dimension name, delimited by ‘/’. For example, let’s say the
root model is an assembly with 2 instances of the part model named ‘Housing’ contained within
it. To check the dimension ‘D1@Sketch4’ within each assembly instance of the ‘Housing model,
the syntax would be:

<checkdimensions>
 <dimension>Housing-1/D1@Sketch4</dimension>
 <dimension>Housing-2/D1@Sketch4</dimension>
</checkdimensions>

Examples:

Defines a check dimension found in the root model:
 <dimension>D1@Layout_Horizontal</dimension>

Defines a check dimension found in the 2nd instance of the model ‘Housing’ contained in the root
model:
 <dimension>Housing-2/D1@Sketch4</dimension>

Defines a check dimension found in the 4th instance of the model ‘Housing’ that is contained in
the 2nd instance of child model ‘SubAssem’ within the root model:
 <dimension>SubAssem-2/Housing-4/D1@Sketch4</dimension>

Settings

The settings element and any child setting element is optional. Child elements of the setting node
specify certain conditions. The valid child element settings are as follows:

<showdefaultrangevalues>
      Determines the default value of range parameters (SwxRange…) defined within
      the rules. The value specifed with this setting must be one of the following:

       0 =   Do not show default range values
       1=    Show default minimum value for all range parameters (default)
       2=    Show default mid value for all range parameters
       3=    Show default maximum value for all range parameters

       Example (sets the default value for all range parameters to the maximum value):

       <rules_data>
         <settings>
           <showdefaultrangevalues>3</showdefaultrangevalues>
         </settings>
       <rules>
         <rule_def id=”??”>
          </rule_def>
          <rule_def id=”??”>
          </rule_def>
              .
              .
              .
       Note: You can additionally control default range values with an optional 4th argument
       specified with the SwxRange() function. Refer to the SwxRange() function
       documentation for further details.

Rule definitions

Here is a sample rule definition:
 <rule_def id=”1”>
   <display_name>Width</display_name>
   <swparameter>D1@Sketch1</swparameter>
   <control>Combo</control>
   <display_data>SwxCoreDataFieldValue(“width_values”, “width”)</display_data>
   <rule></rule>
 </rule_def>




This rule definition defines the name (Width), the sketch parameter it drives (D1@Sketch1), the
type of control to display choices (Combo box) and the choices to display (Values from the
“width_values” core data table, “width” field). Since the rule element is empty, it will retrieve
ALL values from the rule’s referenced core data table.

<rule_def> element, a child of the <rules> element

The rule_def element requires the id attribute, which must be unique in each rule_def element.
The rules engine processes rules in order of “id”. When creating rule_def elements, it is
recommended that you increment your id’s by 5 or 10. This allows you to easily insert a new
rule between two existing rules, without having to renumber existing rules.

The rule definition element (rule_def) has the following child elements:
   - display_name
           o Required, and must be unique, meaning no other rule definition can have the same
               name.
        o This is the “name” of the rule definition, which, if the rule_def does not have the
            “hidden” control type, is shown to the left of the choice list/edit control in the rules
            tester application.

-   control
       o The type of control used to display value(s) for this rule_def.
       o Required, and must be one of the following values:
             Combo – Multiple values displayed in a combo box
             Edit – Single value displayed in an edit field
             Static – Single value displayed in a non-editable field
             Hidden – Not displayed
             Checkbox – Represents a single boolean value of either 1 (checked) or 0
                (unchecked) displayed as a checkbox control.

-   swparameter
         o The SolidWorks sketch dimension this rule_def drives. The sketch dimension must
           exist in the model’s design table.
         o Optional

-   display_data
        o Specification of what data (choices) is displayed for this rule_def.
        o Required.
        o Used for displaying the following types of data:
                Fixed value
                Concatenation of strings
                Fixed list of values
                Range specification
                Value(s) from core data
        o If the control type is checkbox, the display_data should be either 1 (checked) or 0
           (unchecked)

-   sort
         o Specifies field to sort core data records by, in ascending order.
         o Used only if display_data element uses a SwxCoreDataFieldValue() specification.
         o Optional. If not used, all values specified by the display_data element will be
           displayed in the order they appear in core data.
         o By default, a string sort will be performed. If the field you wish to sort by contains
           numeric data, prefix the sort field with a # character.
         o Multiple sort fields may be used, separate field names with a comma.
         o Presence of a sort string takes precedence over a sort specified in a core data table.

-   rule
        o Filters values from core data.
        o Used only if display_data element uses a SwxCoreDataFieldValue() specification.
        o Optional. If not used, all values specified by the display_data element will be
          displayed.


Paging

Paging is optional and involves segmenting rule definitions into groups or ‘pages’. To define a
page, a <page id=’name’> element is specified before the 1st rule definition belonging to that
page and the corresponding ending </page> element after the last rule definition of that page.
The ‘id’ attribute specifies the page name desired. An optional ‘state=”active” attribute can also
be specified any one page element to designate this is the default active page. If ‘state=”active”
is not specified on any page within the rules definition, the first page specified will be assumed
to be the default active page. If paging is specified, then all rule definition must be within a page
definition element, IE, ‘orphaned’ page rule definitions are not allowed.

Here is a sample rule package using paging:
<rules_data>
    <rules>
        <page id="main">
             <rule_def id="11">
               <display_name>Base Length</display_name>
               <control>Combo</control>
               <display_data>SwxChoiceList("10","20","30")</display_data>
             </rule_def>
             <rule_def id="22">
               <display_name>Base Width</display_name>
               <control>Combo</control>
               <display_data>SwxChoiceList("20","40")</display_data>
             </rule_def>
             <rule_def id="33">
               <display_name>Base Height</display_name>
               <control>Edit</control>
               <display_data>SwxRange(0, 40, 2)</display_data>
           </rule_def>
        </page>
        <page id="options">
             <rule_def id="44">
               <display_name>Add mounting bracket</display_name>
               <control>Checkbox</control>
               <display_data>1</display_data>
           </rule_def>
             <rule_def id="55">
               <display_name>Mounting bracket size</display_name>
               <control>SwxIf(SwxRuleValue(44) = "1", Combo, Hidden)</control>
               <display_data>SwxChoiceList("5","10","20","30")</display_data>
           </rule_def>
        </page>
   </rules>
</rules_data>
Core Data

Core data is considered the “raw” data/choices that are available for configuring a model. Core
data is grouped in logical “tables”, similar to a relational database. Each table has multiple
“records”, again, similar to a relational database. Each record has multiple “fields”. The core
data “tables” are the mechanism for storing data that is displayed by a rule definition.

core_data_table element, a child of the core_data_tables element

The core_data_table requires the id attribute, which must be unique between all other
core_data_table elements.

The core data table element can have an optional “sort” attribute, which specifies which field to
sort by when a rule_def uses this core data. It will perform an ascending, text based sort. A
numeric sort can be done by prefixing the sort field with a # character.

The core_data_table contains multiple rec elements. Each rec element can have multiple, user
defined attributes, representing fields in a database table. Each rec element must have the same
name and number of attributes.

Here is an example of a valid core data:
 <core_data_table id=”lengths”>
   <rec length=”10” stroke=”8” />
   <rec length=”12” stroke=”10” />
   <rec length=”13” stroke=”11.4” />
   <rec length=”15” stroke=”12.6” />
 </core_data_table>




Rule function reference

Below are “functions” that can be used in various elements of the rule_def rule definition.


SwxString(“sample value”) – static string display

Arguments:     Single string value
Used in:       display_data element

Sample use:
 <rule_def id=”2”>
   <display_name>Height</display_name>
   <display_data>SwxString(“10”)</display_data>
   .
   .
   .
SwxStringCat(function1(), function2(), …) – Concatenates return values from functions into a
single string.

Arguments:      Multiple
Used in:        display_data element

Sample use:
 <rule_def id=”5”>
   <display_name>Part Number</display_name>
   <display_data>SwxStringCat(SwxRuleValue(1), SwxString(“ - ”),
 SwxRuleValue(2))</display_data>
   .
   .
   .


With the above example, the solved value of this rule_def would be the concatenation of rule
value 1, a dash character, and rule value 2.


SwxRuleValue(id) or SwxRuleValue(“display_name”) – Solved value of a previous rule_def

Arguments: Either a numeric value that corresponds to a previous rule_def’s id -
SwxRuleValue(2), or a string that corresponds to a previous rule_def’s display_name -
SwxRuleValue(“height”).
Used in:    display_data element

Sample use:
 <rule_def id=”5”>
   <display_name>Part Number</display_name>
   <display_data>SwxStringCat(SwxRuleValue(1), SwxString(“ - ”),
 SwxRuleValue(“height”))</display_data>
   .
   .
   .


An error will occur if you try to reference a rule that is defined after this rule definition.


SwxChoiceList(“choice1”, “choice2”, …) – Static choice list

Arguments:      One or more quoted string values, separated by commas
Used in:        display_data element

Sample use:
 <rule_def id=”5”>
   <display_name>Width</display_name>
   <display_data>SwxChoiceList(“10”, “20”, “30”)</display_data>
   .
   .
   .
SwxRange(lower limit, upper limit, step,default,round) – Range specification.

Arguments:     lower limit: Optional. Lower limit of range specification. Numeric
               upper limit: Optional. Upper limit of range specification. Numeric.
               step: Optional. Numeric
               default: Optional. The default value to be used. Numeric
               round: Optional. The number of places to round the value to. Numeric

All five arguments are optional, however, at least one argument must be valid. Any of the
arguments can be a numeric value or one of the following statements:
        o SwxRuleValue
        o SwxRuleFieldValue
        o SwxString
        o SwxIf
        o SwxStringCat
        o Any of the SwxMath* functions

Used in:       display_data element

Sample use:
 <rule_def id=”5”>
   <display_name>Width</display_name>
   <display_data>SwxRange(10, 100, .5)</display_data>
   .
   .


Sample use (no upper limit specified):
 <rule_def id=”5”>
   <display_name>Width</display_name>
   <display_data>SwxRange(0, , 2)</display_data>
   .
   .
   .


The optional 4th value specifies the default value and can be any valid reference that equates to a
number; for example, a static number (IE, ‘30’), a reference to a previous rule (IE,
SwxRuleValue(10)), etc. There are also 3 special keywords that can be used as the 4th argument
as follows:

       SwxMinRange() – Uses the minimum value as the default value
       SwxMidRange() – Uses the mid value as the default value
       SwxMaxRange() – Uses the maximum value as the default value

Examples:

15 is the default value:
        SwxRange(10,20,1,15)

The value of rule 10 is the default range value:
       SwxRange(10,20,1,SwxRuleValue(10))

The mid value of the current range is the default range value:
      SwxRange(SwxRuleValue(5),SwxRuleValue(10),1,SwxMidRange())

Notes:
   o Both the global '<showdefaultrangevalues>' settings option as well as a default value
       argument on the SwxRange function can be used at the same time. Any default value
       argument takes precedence over the global setting. If a default SwxRange value is not
       specified, then the global setting is used.

   o If a default SwxRange value is specified and is invalid for the current range settings (IE,
     it's out of range), then it will automatically be replaced as follows:

              If the value is out of range:
               - The value will be set with whatever the global setting is set to; if the global
                    setting is not set, then the minimum value will be used.
               - If the value is in range, but the step is wrong (IE, not evenly divisible by the
                    step increment):
                        o The value will be adjusted to be as close to the original value and
                            within the step increment.

The optional 5th argument controls the rounding of the range values (especially useful when
using default range parameter values).

Example:

Rounds off the default value (current value of rule 10) to 3 places:
      SWxRange(10,100,1,SwxRuleValue(10),3)

SwxIf(condition, true value, false value) – If statement

Arguments:     condition – statement to evaluate
               true value – this statement is executed if condition evaluates to true
               false value – this statement is executed if condition evaluates to false
Used in:       control, display_data and rule elements

The “condition” argument is comprised of three parts, the left side comparison, the comparison
operator and the right side comparison.

Left or right side comparisons can be any of the following:
        o SwxRuleValue
        o SwxRuleFieldValue
        o SwxString
        o SwxIf
        o SwxStringCat
       o Any of the SwxMath* functions

The comparison operator can be any of the following:
       o =            (equal to)
       o &gt;         (greater than)
       o &gt;=        (greater than or equal to)
       o &lt;         (less than)
       o &lt;=        (less than or equal to)
       o !=           (not equal to)
Please note that the greater than (>) or less than (<) symbol cannot be used within an element
in an XML document. The substitute for these characters are the four character sequence for
greater than (&gt;), and for less than (&lt;).

If the left and right side comparison values evaluate to numeric values, a numeric comparison
will be performed, otherwise a string comparison will be performed.

If the condition evaluates true, the “true value” will be used. Otherwise, the “false value” will be
used.

SwxIf statements can be nested inside the “true value” and “false value” arguments, allowing
you to create complex if … then … else conditions.

Sample use:
 <rule_def id=”5”>
   <display_name>Width</display_name>
   <display_data>SwxIf(SwxRuleValue(2) = SwxString(“Metric”),
 SwxCoreDataFieldValue(“widths”, “met_widths”),
 SwxCoreDataFieldValue(“widths”, “inch_widths”))</display_data>
   .
   .
   .
The above sample checks if the solved value of rule id 2 is equal to metric. If so, it uses the core
data from widths, field met_widths. If not, it uses the core data from widths, field inch_widths.

Sample use (Another way to perform same check as above):
 <rule_def id=”5”>
   <display_name>Width</display_name>
   <display_data>SwxCoreDataFieldValue(“widths”, SwxIf(SwxRuleValue(2)
 = SwxString(“Metric”), “met_widths”, “inch_widths”))</display_data>
   .
   .
   .


Sample use (Change control type based on previous rule value):
 <rule_def id=”5”>
   <display_name>Stroke length</display_name>
   <control>SwxIf(SwxRuleValue(“stroke type”) = SwxString(“Fixed”),
 SwxString(“Edit”), SwxString(“Hidden”))</control>
   <display_data>SwxRange(0, SwxRuleFieldValue(“models”,
 “max_stroke”), )</display_data>
   .
   .
   .
SwxCoreDataFieldValue(“core data id”, “core data field”) – Values displayed for rule
definition come from a core data table.

Arguments:     core data id – id of core data that contains the values to display.
               core data field – field name from above core data.
Used in:       display_data element

This statement tells the rules engine to get it’s choices for this rule definition from a core data
table. This statement is frequently used in conjunction with the rule element’s SwxFilter
statement. If no SwxFilter statement is used, all values in the specified core data table are used.
If duplicate values exist in the core data table for the specified field, they will be filtered out
upon solving.

Sample use:
 <rule_def id=”5”>
   <display_name>Width</display_name>
   <display_data>SwxCoreDataFieldValue(“widths”,
 “width”)</display_data>
   .
   .
   .
This will result in a choice list containing as many values as there unique values in the specified
core data table.

Choices can also be created by concatenating fixed values with core data values.
 <rule_def id=”5”>
   <display_name>Width</display_name>
   <display_data>SwxStringCat(SwxCoreDataFieldValue(“widths”,
 “width”), SwxString(“mm”))</display_data>
   .
   .
   .
The above sample will append the string “mm” to each value from core data.
SwxRuleFieldValue(rule id OR rule name, core data field) – Returns the value of a core data
field based on the solved state of a previously defined rule. This may only be used if the rule
you are referencing (the rule id or name you specify in the first argument) uses core data.

Arguments:      rule id / rule name – the id or name of a previously defined rule definition.
                core data field – the field name from the core data table in the referenced rule.
Used in:        control, display_data and rule elements

This statement returns a single value from the core data table in the referenced rule. For
example, if the following core data exists:
 <core_data_table id=”sizes”>
   <rec size=”10mm” clearance_hole=”5”         />
   <rec size=”11mm” clearance_hole=”6”         />
   <rec size=”12mm” clearance_hole=”7”         />
   <rec size=”13mm” clearance_hole=”8”         />
   <rec size=”14mm” clearance_hole=”9”         />
 </core_data_table>
And the following rule definition exists:
 <rule_def id=”4”>
   <display_name>Size</display_name>
   <control>Combo</control>
   <display_data>SwxCoreDataFieldValue(“sizes”, “size”)</display_data>
   <rule />
 </rule_def>
An appropriate use of SwxRuleFieldValue would be the following:
 <rule_def id=”5”>
   <display_name>Clearance Hole Diameter</display_name>
   <swparameter>clear_dia@sketch1</swparameter>
   <control>Static</control>
   <display_data>SwxRuleFieldValue(4, “clearance_hole”)</display_data>
   <rule />
 </rule_def>
When the rules document is solved, rule definition id 5 will have the clearance_hole value
corresponding to the selected size.

An error will occur if you try to reference a rule that is defined after this rule definition.
SwxFilter(core data id, core data field, comparison operator, comparison value) – Filter
core data values

Arguments:     core data id - id of core data that contains the values to filter
               Core data field – core data field that has value to compare to comparison value
argument
               Comparison operator –
               Comparison value – value to compare to core data field
Used in:       rule element

This statement filters a rule definition’s values from core data to those which pass the specified
comparison operation. This is similar to a SQL “where” statement.

The core data id must be the same as that used in the display_data element
SwxCoreDataFieldValue statement.

The comparison operator can be any of the following:
       o =            (equal to)
       o &gt;         (greater than)
       o &gt;=        (greater than or equal to)
       o &lt;         (less than)
       o &lt;=        (less than or equal to)
       o !=           (not equal to)
Please note that the greater than (>) or less than (<) symbols cannot be used within an
element in an XML document. The substitute for these characters are the four character
sequence for greater than (&gt;), and for less than (&lt;).

The comparison value can be any of the following:
      o SwxRuleValue
      o SwxRuleFieldValue
      o SwxString
      o SwxIf
      o SwxStringCat
      o Any of the SwxMath* functions

Sample use:
 <rule_def id=”3”>
   <display_name>Size</display_name>
   <control>Combo</control>
   <display_data>SwxCoreDataFieldValue(“sizes”, “size”)</display_data>
   <rule />
 </rule_def>
 <rule_def id=”5”>
   <display_name>Shank Length</display_name>
   <control>Combo</control>
   <display_data>SwxCoreDataFieldValue(“bolt_lengths”,
 “length”)</display_data>
   <rule>SwxFilter(“bolt_lengths”, “length”, “=”,
 SwxRuleValue(“size”)</rule>
 </rule_def>
 </rules>
 <core_data_tables>
   <core_data_table id=”sizes”>
     <rec size=”10mm” />
     <rec size=”12mm” />
     <rec size=”14mm” />
   </core_data_table>
   <core_data_table id=”bolt_lengths”>
     <rec size=”10mm” length=”50mm” />
     <rec size=”10mm” length=”75mm” />
     <rec size=”10mm” length=”100mm” />
     <rec size=”12mm” length=”50mm” />
     <rec size=”12mm” length=”80mm” />
     <rec size=”12mm” length=”120mm” />
     <rec size=”14mm” length=”75mm” />
     <rec size=”14mm” length=”100mm” />
     <rec size=”14mm” length=”150mm” />
     <rec size=”14mm” length=”200mm” />
     <rec size=”14mm” length=”250mm” />
   </core_data_table>
 </core_data_tables>
This example limits the values for shank length to be those that match the rule value of size.

SwxAnd(filter 1, filter 2)
SwxOr(filter 1, filter 2)

Arguments:     filter 1 – either a SwxFilter statement, or another SwxAnd or SwxOr statement.
               filter 2 – same as filter 1
Used in:       rule element

These are used to combine SwxFilter statements. If the SwxAnd statement is used, only records
that pass both filter statements will be included. If the SwxOr statement is used, records will be
included which pass either filter statement.

Sample use:
 <rule_def id=”7”>
   <display_name>Thread Length</display_name>
   <control>Combo</control>
   <display_data>SwxCoreDataFieldValue(“lengths”,
 “thread_len”)</display_data>
   <rule>SwxAnd(SwxFilter(“lengths”, “size”, “=”,
 SwxRuleValue(“size”)), SwxFilter(“lengths”, “length”, “=”,
 SwxRuleValue(“length”)))</rule>
 </rule_def>
SwxMathAdd([value 1], [value 2]) – Add two values
SwxMathSubtract([value 1], [value 2]) - Subtract two values
SwxMathMultiply([value 1], [value 2]) – Multiply two values
SwxMathDivide([value 1], [value 2]) – Divide two values
SwxMathRound([value],[number of places]) – Rounds the specified [<value] to the
                                               specified [number of places]
SwxMathSqrt([value]) – Returns the square root of the specified [value].
SwxMathSin([value]) – Returns the sine of the specified [value] (in degrees).
SwxMathCos([value]) – Returns the cosine of the specified [value] (in degrees).
SwxMathTan([value]) – Returns the tangent of the specified [value] (in degrees).
SwxMathInt([value]) – Returns the integer portin of the specified [value]
SwxMathFabs([value] - Returns the absolute value of the specified [value]

Either argument can be a numeric value, or one of the following statements:
        o SwxRuleValue
        o SwxRuleFieldValue
        o SwxIf
        o Any of the SwxMath* functions

Used in:      control, display_data and rule elements

Sample use:
 <rule_def id=”3”>
   <display_name>Thread Length</display_name>
   <control>Edit</control>
   <display_data>SwxRange(0, SwxMathMultiply(SwxRuleValue(“diameter”),
 2), )</display_data>
   <rule></rule>
 </rule_def>
This sample defines a range between 0 and the diameter value multiplied by 2.
General guidelines

No forward referencing

Rule definitions can refer to previously defined rules by using the SwxRuleValue and
SwxRuleFieldValue statements. It is important that you order your rule definitions in a logical
sequence.

Relationships between rule definitions

-   None: There are no dependencies between this rule definition and any others. This can be
    done by having a fixed value (SwxString), a fixed choice list (SwxChoiceList), or by using
    core data (SwxCoreDataFieldValue) with no rule element. An example of this is rule_def id
    1, in Sample 1 below.
-   One-To-One: This means for a single value in a previously defined rule definition, there is
    only one possible value for the current rule definition. This can be done by using the
    SwxRuleFieldValue statement, as seen in rule_def id 2, in Sample 4 below.
-   One-To-Many: This means for a single value in a previously defined rule definition, there
    are one or more values for the current rule definition. This can be done by using the
    SwxCoreDataFieldValue statement in conjunction with the SwxFilter statement inside the
    rule element. This can be seen in rule_def id 3, in Sample 3 below.
-   Many-To-Many: This means that for each combination of two or more previously defined
    rule values, there are many values available. This is done by using two or more SwxFilter
    statements, as seen in the Wheel sample below.


Using the rules testing application

The rules testing application (RulesTester.exe) is a stand-alone program which allows you to
validate rules document validity, and test operation of rule definitions.

Start the rules testing application, and press the Browse button to select an xml rules document.
When the file has been opened, it will be “solved”. Syntax errors, if present, will result in error
messages being displayed. Otherwise, you will see your visible rule definitions displayed. Each
time a value is changed in the rules tester application, the rules document is “re-solved”,
reloading values below the rule definition.

Use of the rules testing application is highly recommended prior to uploading the rules document
to 3DPartStream.

Using the rules document with a 3DPartStream model

Rule definitions can drive model parameters that have been defined in the model’s design table.
As the rules package is used, each rule definition has a current rule value. When model creation
is requested, the model will be created using values from rules which have swparameter elements
defined. You must create rule definitions for each design table parameter you wish to drive with
a rules document.

Uploading rules with batch upload tool.

When you should use rules
- hidden rules
- rules that don’t map out to a parameter directly

When you shouldn’t use rules


Putting it all together - Building a Box

The following samples will show you different ways of creating a rules package for a box, which
has SolidWorks model parameters for length, width and height.

Sample 1: No core data, no relationships between rule definitions
 <rules_data>
    <rules>
       <rule_def id="1">
          <display_name>Length</display_name>
          <control>Combo</control>
          <display_data>SwxChoiceList(“10", “20", “30")</display_data>
          <swparameter>length@sketch1</swparameter>
       </rule_def>
       <rule_def id="2">
          <display_name>Width</display_name>
          <control>Combo</control>
          <display_data>SwxChoiceList(“20", “40")</display_data>
          <swparameter>width@sketch1</swparameter>
       </rule_def>
       <rule_def id="3">
          <display_name>Height</display_name>
          <control>Edit</control>
          <display_data>SwxRange(0, 40, 2)</display_data>
          <swparameter>height@base-extrude</swparameter>
       </rule_def>
    </rules>
 </rules_data>
This sample results in three “questions” displayed to the user, with each question having no
dependency on another.
Sample 2: Uses core data, but still no relationships between rule definitions
 <rules_data>
    <rules>
       <rule_def id="1">
          <display_name>Length</display_name>
          <control>Combo</control>
          <display_data>SwxCoreDataFieldValue(“lengths",“length")</display_data>
          <swparameter>length@sketch1</swparameter>
       </rule_def>
       <rule_def id="2">
          <display_name>Width</display_name>
          <control>Combo</control>
          <display_data>SwxCoreDataFieldValue(“widths","width")</display_data>
          <swparameter>width@sketch1</swparameter>
       </rule_def>
       <rule_def id="3">
          <display_name>Height</display_name>
          <control>Edit</control>
          <display_data>SwxRange(0, 40, 2)</display_data>
          <swparameter>height@base-extrude</swparameter>
       </rule_def>
    </rules>
    <core_data_tables>
       <core_data_table id="lengths">
          <rec length="10"/>
          <rec length="20"/>
          <rec length="30"/>
       </core_data_table>
       <core_data_table id="widths">
          <rec width="20"/>
          <rec width="40"/>
       </core_data_table>
    </core_data_tables>
 </rules_data>
Sample 3: Uses core data, one-to-many relationship between Length and Width rule definitions
 <rules_data>
    <rules>
       <rule_def id="1">
          <display_name>Length</display_name>
          <control>Combo</control>
          <display_data>SwxCoreDataFieldValue(“lengths",“length")</display_data>
          <swparameter>length@sketch1</swparameter>
       </rule_def>
       <rule_def id="2">
          <display_name>Width</display_name>
          <control>Combo</control>
          <display_data>SwxCoreDataFieldValue(“widths","width")</display_data>
          <swparameter>width@sketch1</swparameter>
          <rule>SwxFilter(“widths", “length", “=", SwxRuleValue(1))</rule>
       </rule_def>
       <rule_def id="3">
          <display_name>Height</display_name>
          <control>Edit</control>
          <display_data>SwxRange(0, 40, 2)</display_data>
          <swparameter>height@base-extrude</swparameter>
       </rule_def>
    </rules>
    <core_data_tables>
       <core_data_table id="lengths">
          <rec length="10"/>
          <rec length="20"/>
          <rec length="30"/>
       </core_data_table>
       <core_data_table id="widths">
          <rec length="10" width="20"/>
          <rec length="10" width="25"/>
          <rec length="10" width="30"/>
          <rec length="20" width="50"/>
          <rec length="20" width="55"/>
          <rec length="20" width="60"/>
          <rec length="30" width="80"/>
          <rec length="30" width="85"/>
          <rec length="30" width="90"/>
       </core_data_table>
    </core_data_tables>
 </rules_data>

When this rules document is solved, it will display a unique set of width values for each length
value.

As you notice, there are two core data tables, with the “length” field as the common “key”
between the two.
Sample 4: In this example, rule definitions are created that do not have a direct relationship with
a SolidWorks model parameter. A rule definition is created that lists available box “sizes”, and
hidden rule definitions have a one-to-one relationship with the size selected.
 <rules_data>
    <rules>
       <rule_def id="1">
          <display_name>Box Size</display_name>
          <control>Combo</control>
          <display_data>SwxCoreDataFieldValue("boxsizes","size")</display_data>
       </rule_def>
       <rule_def id="2">
          <display_name>Length</display_name>
          <control>Hidden</control>
          <display_data>SwxRuleFieldValue(1,"length")</display_data>
          <swparameter>length@sketch1</swparameter>
       </rule_def>
       <rule_def id="3">
          <display_name>Width</display_name>
          <control>Hidden</control>
          <display_data>SwxRuleFieldValue(1,"width")</display_data>
          <swparameter>width@sketch1</swparameter>
       </rule_def>
       <rule_def id="4">
          <display_name>Height</display_name>
          <control>Static</control>
          <display_data>SwxRuleFieldValue(1,"height")</display_data>
          <swparameter>height@base-extrude</swparameter>
       </rule_def>
    </rules>
    <core_data_tables>
       <core_data_table id="boxsizes">
          <rec size="1.2 Cu. Ft." length="10" width="14" height="10"/>
          <rec size="1.8 Cu. Ft." length="12" width="14" height="11"/>
          <rec size="2.4 Cu. Ft." length="16" width="14" height="12"/>
       </core_data_table>
    </core_data_tables>
 </rules_data>
Complex example

Let’s create a rules document for an automobile wheel.

First Question is what material for the wheel, either Steel or Aluminum.

Second question is Wheel Diameter, with steel sizes from 13” to 17”, and aluminum sizes from
13” to 20”.

Third question is Wheel Width, with different widths available depending on wheel diameter.

If Steel is selected, our fourth question is finish, with the choices being Painted Silver or Painted
Black.

If Aluminum is selected, our fourth question is also finish, with choices being Polished, Painted
Silver or Chromed.

If Steel is selected, our fifth question is Hub Cap Style. If Aluminum, hide this question.

Last is a display of the part number based on the above configuration selections.

 <rules_data>
    <rules>
       <rule_def id="1">
          <display_name>Wheel Material</display_name>
          <control>combo</control>
          <display_data>SwxCoreDataFieldValue("wheel_types", "material")</display_data>
          <rule/>
       </rule_def>
       <rule_def id="2">
          <display_name>Wheel Diameter</display_name>
          <control>combo</control>
          <display_data>SwxCoreDataFieldValue("sizes", "size")</display_data>
          <rule>SwxAnd(SwxFilter("sizes", "size", ">=", SwxRuleFieldValue(1,
 "size_min")), SwxFilter("sizes", "size", "&lt;=", SwxRuleFieldValue(1,
 "size_max")))</rule>
       </rule_def>
       <rule_def id="3">
          <display_name>Wheel Width</display_name>
          <control>combo</control>
          <display_data>SwxCoreDataFieldValue("widths", "width")</display_data>
          <rule>SwxAnd(SwxFilter("widths", "width", ">=", SwxRuleFieldValue(2,
 "width_min")), SwxFilter("widths", "width", "&lt;=", SwxRuleFieldValue(2,
 "width_max")))</rule>
       </rule_def>
       <rule_def id="4">
          <display_name>Wheel Finish</display_name>
          <control>combo</control>
          <display_data>SwxCoreDataFieldValue("finishes", "finish")</display_data>
          <rule>SwxFilter("finishes", "material", "=", SwxRuleValue(1))</rule>
       </rule_def>
       <rule_def id="5">
          <display_name>Hub Cap Style</display_name>
          <control>SwxIf(SwxRuleValue(1) = SwxString("Steel"), SwxString("combo"),
 SwxString("hidden"))</control>
          <display_data>SwxCoreDataFieldValue("hub_cap_styles", "style")</display_data>
          <rule/>
       </rule_def>
       <rule_def id="6">
          <display_name>Part Number</display_name>
         <control>Static</control>
         <display_data>SwxStringCat(SwxRuleValue(2), SwxString("/"), SwxRuleValue(3),
SwxRuleFieldValue(4,"part_code"), SwxIf(SwxRuleValue(1) = SwxString("Steel"),
SwxRuleFieldValue(5, "part_code"), SwxString("")))</display_data>
         <rule/>
      </rule_def>
   </rules>
   <core_data_tables>
      <core_data_table id="wheel_types">
         <rec material="Aluminum" size_min="13" size_max="20"/>
         <rec material="Steel" size_min="13" size_max="17"/>
      </core_data_table>
      <core_data_table id="finishes">
         <rec material="Aluminum" finish="Polished" part_code="AL-POL"/>
         <rec material="Aluminum" finish="Painted Silver" part_code="AL-PAINT"/>
         <rec material="Aluminum" finish="Chromed" part_code="AL-CHROME"/>
         <rec material="Steel" finish="Painted Black" part_code="ST-BL"/>
         <rec material="Steel" finish="Painted Silver" part_code="ST-SIL"/>
      </core_data_table>
      <core_data_table id="sizes">
         <rec size="13" width_min="5" width_max="6.5" />
         <rec size="14" width_min="5" width_max="6.5" />
         <rec size="15" width_min="6" width_max="7.5" />
         <rec size="16" width_min="6" width_max="8" />
         <rec size="17" width_min="6.5" width_max="8.5" />
         <rec size="18" width_min="7" width_max="9.5" />
         <rec size="19" width_min="7" width_max="11" />
         <rec size="20" width_min="8" width_max="10" />
      </core_data_table>
      <core_data_table id="hub_cap_styles">
         <rec style="None" part_code="" />
         <rec style="Swirl" part_code="-SW" />
         <rec style="Star" part_code="-ST" />
         <rec style="Spoke" part_code="-SP" />
      </core_data_table>
      <core_data_table id="widths">
         <rec width="5.0" />
         <rec width="5.5" />
         <rec width="6.0" />
         <rec width="6.5" />
         <rec width="7.0" />
         <rec width="7.5" />
         <rec width="8.0" />
         <rec width="8.5" />
         <rec width="9.0" />
         <rec width="10.0" />
         <rec width="11.0" />
      </core_data_table>
   </core_data_tables>
</rules_data>

								
To top