Please ensure Javascript is enabled for purposes of website accessibility
Powered by Zoomin Software. For more details please contactZoomin

Hull and Outfitting

Command Syntax

  • Last UpdatedJan 15, 2026
  • 7 minute read

The syntax used in Pipe Router is to allow customers to build Router into their own systems, especially batch input, and to adapt the standard Applicationware. For most users, this should not be necessary as all important functionality is available via Applicationware.

These commands can only be used in ROUTER mode. To switch from standard Design to Router, give the command:

ROUTER

The following errors will result if Router is not available.

(61,701)

Cannot open router DSO due to:- <TEXT>

(71,702)

Incorrect Router Library version. It is <INT> but should be <INT>

(61,791)

No licences available for Piperouter

(61,792)

Piperouter security error <INT>

(61,792)

Piperouter security error

To return to Design, give the command:

EXIT

Note on element identifiers

Use names as element identifiers.

  • If a reference is output and then re-input, it can result in an invalid reference.

  • Avoid referring to Elbows using "ELBO n of /B1": Pipe Router re-creates Elbows every time a Branch is re-routed, and the numbering can easily get changed.

Conventions Used in the Syntax Graphs

The commands described in this chapter are presented in the form of syntax graphs.

  • Commands are shown in a combination of uppercase and lowercase letters, where the capital letters indicate the minimum abbreviation.

    Note:
    The convention does not mean that the second part of the command must be typed in lowercase letters; commands may be entered in any combination of uppercase and lowercase letters.

  • For example, the command ICONSTraint can be input in any of the following forms:

    ICONST

    ICONSTR

    ICONSTRA

    ICONSTRAI

    ICONSTRAIN

    ICONSTRAINT

  • Commands shown in all uppercase letters cannot be abbreviated.

  • Command arguments are shown in lowercase letters. These are just descriptions of what you need to enter. For example:

    CLEAR n

  • means that to remove the constraint number 3, enter:

    CLEAR 3

  • Syntax graphs are read from top left to bottom right. The start point is shown by >, and you can follow any path through the graph until the exit point, shown by >, is reached.

  • Points marked with a plus sign (+) are option junctions which allow you to input any one of the commands to the right of the junction. For example:

        >----+--- ABC -----.

             |             |

             |--- PQR -----|

             |             |

             ‘-------------+--->

  • means you can type in ABC or PQR or just press Enter to get the default option.

  • Text in angle brackets <. . . > is the name of another syntax graph. The convention is used for syntax which occurs in many places. The graphs referred to are described at the end of this section. For example:

        >----+--- ABC -----.

             |             |

             |--- PQR -----|

             |             |

             |--- <dia> ---|

             |             |

             ‘-------------+--->

  • means you can type in ABC or PQR or any command allowed by the syntax given in diagram <dia> or just press Enter to get the default option.

  • Points marked with an asterisk (*) are loop back junctions. Command options following these may be repeated as required. For example:

                  .-----<-------.

                 /              |

            >---*--- option1 ---|

                |               |

                |--- option2 ---|

                |               |

                ‘--- option3 ---+--->

  • means that you can enter any combination of option1 and/or option2 and/or option3, where the options can be commands, other syntax diagrams, or command arguments.

  • The simplified format:

                 .----<------.

                /            |

           >---*--- name ----+--->

  • means that you may type in a list of PDMS names, separated by at least one space.

Standard Syntax Graphs

Some graphs contain references to other, standard syntax graphs which are widely used throughout AVEVA Design. References to standard syntax graphs are shown in angle brackets:

<example>

Ordering and Routing Branches

Ordering is required when routing a number of branches so that the main branches are routed first before sub-branches such as drains and vents, which requires two commands:

ORDER---<SELATT>-+--<SELATT>---.

                |             |

                ‘-------------+-->

and then

VAR <VARNAME>  ROUTE ORDer

Can give the following error

(61,723) Could not order <REF> for routing

The ORDER command returns a collection of branch references sorted so that the main branches are first.

A network of branches for a given branch can also be found with the command:

VAR <VARNAME>  ROUTE  NETwork name

And then to route the branches:

ROUTE --- <SELATT>-+--<SELATT>---.

                  |             |

                  ‘-------------+-->

If no branches or pipes are in the selection you get the following error:

(2,563) Wrong element type

Branch Constraints

A route can be constrained to pass through points, along planes or to use pipe racks with the following syntax. The current element must be a Branch.

Points

NEW POINT -+- AT <DOPE>-+-DIRection <DOPE>-+-LEAVedir <DOPE>-+-AFTER name -.
           |            |                  |                 |             |
           ‘- name -----+------------------+-----------------+-------------+-->

Creates a point in space with optional arrive and leave directions after either the head of the bran or one of its members.

Planes and Racks

NEW PLANE  name AFTER name --+-- LAST name ---.
                            |                |
                            ‘----------------+-->

A plane should be defined by referencing a RPLA. When using a RPLA, the direction of travel is fixed as the X direction for single planes and travel planes and Y direction for entry and exit planes.

For a rack the first name should be an RPLG which owns at least one RPLA with PURP PREX (that is, an entry/exit plane) and at least one RPLA with PURP not set to PREX (the travel plane).

To remove a constraint use:

CLEAR -+---- n ----.

       |           |

      ‘---ALL ----+-->

To move one constraint after another in the branch list.

REORDer -- n ---+--AFTER---.

               |          |

               ‘--BEFORE--+--<INT> ->

To move a constraint to after a different component in the branch list.

EDIT -- n ---+--AFTER--- name ->

To query constraints:

Q ICONSTraint NUMBer

will return the number of point and plane constraints for a branch.

Q ICONSTraint TYPE <INT>

will return the type for a given constraint.

Q ICONSTraint POINt <INT>-+--POSition ---------------------------.
                         |                                      |
                         |--DIRection --------------------------|
                         |                                      |
                         |--LEAVdirection ----------------------|
                         |                                      |
                         |--COMPonent --------------------------|
                         |                                      |
                         |--RELAtion ---------------------------|
                         |                                      |
                         |--ACTUal-+--POSition------.           |
                         |         |                |           |
                         |         |--DIRection-----|           |
                         |         |                |           |
                         |         ‘--LEAVdirection-+-WRT name -|
                         |                                      |
                         |                                      |
                         ‘--------------------------------------+->

To allow the component parts of a point constraint to be queried. As the position and directions can be stored as expressions, the ACTUAL command returns the calculated values.

Note:
RELATION and FIXED need not be queried as they are always respectively AFTER and FIXED.

If a DATUm is used as a point constraint, its position can be found by exiting from Router and querying its attributes in the normal manner.

Q ICONSTraint PLANe  n ---+-- STARt --------------------------------.
                         |                                         |
                         |-- FINIsh -------------------------------|
                         |                                         |
                         |-- DIRection ----------------------------|
                         |                                         |
                         |-- COMPonent ----------------------------|
                         |                                         |
                         |-- LAStconent ---------------------------|
                         |                                         |
                         |-- RELAtion -----------------------------|
                         |                                         |
                         |-- RPLAne -------------------------------|
                         |                                         |
                         |-- ACTUal -+--STARt ---.                 |
                         |           |           |                 |
                         |           |--FINIsh --+-- WRT name -.   |
                         |           |                         |   |
                         |           ‘--DIRection -------------+---|
                         |                                         |
                         |-- ACTUal -------------------------------|
                         |                                         |
                         |-- FIXed --------------------------------|
                         |                                         |
                         ‘-----------------------------------------+-->

Since a plane is defined using a RPLA, its dimensions are found by exiting from Router and querying its attributes in the normal manner.

Configuration

Allows the behavior of Router to be modified. It has the following syntax:

CONFiguration -+-- ERROR <WORD> ------|
               |                      |
               |-- DIRection <WORD> --|
               |                      |
               |-- PRSP <REAL> -------|
               |                      |
               |-- PRRO <REAL> -------|
               |                      |
               |-- ORDER <WORD> ------|
               |                      |
               |-- MODE <WORD> -------|
               |                      |
               ‘-- ITERation-- n -----+-->

ERROR can be set to MESS, in which case extra diagnostic messages are output during routing.

DIRECTION can be set to BEND, ELBO or RULE and allows the change of direction elements to be specified.

PRSP is the basic gap for pipe-rack spacing.

PRRO is the gap rounding value for pipe-rack spacing.

ORDER, MODE and ITERATION are not currently used in core PDMS Router, but can be used for the appware.

To query configuration setting, use:

Q CONFiguration -+-- ERROR -------.
                 |                |
                 |-- DIRection ---|
                 |                |
                 |-- PRSP --------|
                 |                |
                 |-- PRRO --------|
                 |                |
                 |-- ORDER -------|
                 |                |
                 |-- MODE --------|
                 |                |
                 |-- ITERation ---|
                 |                |
                 ‘----------------+-->

General Rule Setting

The following syntax is for setting the SELECTION, LOGICAL and ACTION attributes of GRULES. The current element must be a GRULE.

GENEral RULEs SELEction <SELATT>

GENEral RULEs LOGIcal <EXPZL>

GENEral RULEs ACTIon <EXPRG>

GENEral RULEs ACTIon  UNSET

To query the attributes set:

Q GENEral RULEs SELEction

Q GENEral RULEs LOGIcal

Q GENEral RULEs ACTIon

Rules can be used for routing in two ways. They can be SET, which means that a selection of GRULEs are set and then used in subsequent routing during the design session. Alternatively, rules can be STORED, which means that the same GRULES will be used in future routing, thus maintaining design intent. To specify which:

GENEral RULEs USE --+--SET-----.
                    |          |
                    ‘--STOREd--+-->

To SET rules:

GENEral RULEs SET -+-HIGH-.
                   |      |
                   |-LOW--| 
                   |      |
                   ‘------+-APPEnd------.
                          |             | 
                          |-OVERWrite---|
                          |             |
                          ‘-------------+-<SELATT>-+-<SELATT>-.
                                        |          |          |
                                        ‘----------+----------+->

The defaults are LOW priority and OVERWRITE.

Rules can then be UNSET with the following syntax.

GENEral RULEs UNSET --<SELATT>--+--<SELATT>---.
                               |             |
                               ‘-------------+-->

To query the set rules, the following syntax will return an array of GRULE references and their priority.

VAR <VARNAME> GRULEs SET

To STORE rules, the current element must be either a Bran, Pipe, Zone or Site. The stored rules will then apply to branches owned by that element. However, when determining which rules to use, the program navigates up until it finds some rules to apply. Thus, if rules have been saved for Zone and Site say, then only the Zone rules will be used.

GENEral RULEs SAVE -+-HIGH-.
                    |      |
                    |-LOW--|
                    |      |
                    |------+-<SELATT>-+-OVERWrite --.
                    |                 |             |
                    |                 |--APPEnd ----|
                    |                 |             |
                    |                 ‘-------------|
                    |                               |
                    ‘-- SET ------------------------+-->

The defaults are LOW priority and OVERWRITE.

To query the rules saved:

Q GENEral RULEs SAVED

To remove the saved rules for a particular element:

GENEral RULEs UNSAVE

Rule Testing

As writing rules is not always straightforward, the following functionality is provided to provide feedback.

To test a branch member to see what rules apply to it and whether it passes them:

VAR <VARNAME> GRULEs TEST --+--<WORD>---.
                            |           |
                            ‘-----------+-->

The word is the type of rule to be tested, MAJO, MINO etc, and if not specified, all rules are tested.

To test plane rules the current element needs to be the branch to be tested.

VAR <VARNAME> GRULEs PLANE name

where the GID is the RPLG to be tested. The returned results are the travel, entry and exit planes.

A branch member can also be tested by applying the action part of a rule to it with:

GENEral RULEs APPLY WORD

The word is the type of rule to be tested, MAJO, MINO Note if the element passes the rule already, then no action is carried out.

Router Banner

Pipe Router has its own banner which can be queried (in Router mode) with the command:

Q BANNer

In This Topic
TitleResults for “How to create a CRG?”Also Available in