LabVIEW Code Generation Engine

Overview

The LabVIEW codegen engine was first created in late 2000 to support the first release of the NI
Motion Assistant. It was firmly integrated into system infrastructure with no option to use it
otherwise. A stand-alone version was created later so that the NI Vision Assistant could use it. It has
been under continuous development since.

The LabVIEW codegen engine uses a template based mechanism. VIs (templates), are created which
contain fragments of the code needed in the final target VI. The engine assembles these fragments,
dynamically modifying them and connecting them together, into the final code. The engine serves to
insulate the user from the complexity of full scripting and the changes associated with different
versions of LabVIEW.

A user of the codegen engine creates templates based on the final code desired. A script is then
assembled which contains the template locations, any changes to the templates, and their
connections to each other. The script also contains project level options such as whether or not to
save the final VI or to show its block diagram while scripting.

At present, the codegen engine is only supported on Windows platforms.

Invoking LabVIEW Code Generation

The codegen engine can be launched from LabVIEW using the VI <LabVIEW
x.x>\vi.lib\Platform\codeGenEngine.llb\RunCGEngineDynamically.vi or
RunCGEngineDynamically2.vi. The first of these VIs is available starting in LabVIEW 8.2. The second
is available from LabVIEW 8.6 forward and should be used for all new development. It provides
access to the full current functionality of engine.

Codegen Script Basics

Overview
The codegen engine uses a template based approach to generating code. The user creates code
fragments and saves these in VIs - the templates. A script is then generated which contains the order
to use these templates and how to modify and connect them together and to the connector pane. The
general order of execution is:

1. Open template (revert if previously opened)

2. Modify any variables or code and put “uniquification” strings on all structures, constants, and
any terminal connected to the template connector pane
 3. Move the template code to the destination VI
4. Repeat 1 - 3 until all templates are in place
5. Connect all wires
6. Connect terminals to the connector pane
7. Clean up excess terminals, broken wires, and any user specified objects
8. Save the destination VI and any subVIs tagged for saving

When you create a script, you specify the template locations, how they are modified before drop, how
they are connected together, and how terminals are connected to the connector pane. The script also
contains any options for code generations. Options include such things as the connector pane
pattern and wire routing algorithm used. Legacy options have specific inputs. These are the VI title,
description, icon path, and help link. You can also specify control options for code generation such as
whether or not to show the diagram during generation and the start location on the block diagram of
generation. You can specify a target VI name or not. If a name is not specified, the engine will query
for one.

Starting A Script
Start with the mxwCodeGenCompleteRecipe.ctl and fill in the data structures. A copy of this control
is most easily obtained by creating a constant from the invoking VI. It can also be dropped from the
attached code.

Adding Global Options

A complete set of options can be found in Appendix I. Options are a name/value pair. Both name and
value are strings. Options are added by simply adding another item to the options array of the
CodeGenRecipe. Many options have a fairly complex structure. Use the helper VIs in the supplied
API to generate option name/value pairs. The option helper VIs have names of the form
mxwScript_API_Option_*.vi. The most commonly used of these is probably
mxwScript_API_Option_SetConPanePattern.vi, used to set the connector pane pattern and rotation.

Legacy options are set directly in the CodeGenRecipe. Note that, despite the name, the icon image
can be a BMP or PNG in format.

Creating and Adding Templates

Templates are code fragments which are assembled to produce the final code. Any terminal on the
template which will be connected to another template or to the final connector pane must be
connected to the connector pane on the template. By default, when templates are dropped, they are
aligned to the terminals of the previous template to which they are attached. The final result will look
best if the terminals of your templates are on the same relative vertical places on each template.
Terminals which are not connected to the connector pane of the template will be untouched in the
final code, but cannot be wired to.

To make copying from the template to the final code faster, after you finish writing the template, put
all the code in a single frame stacked sequence with label “mxwFramer”. This allows the codegen
engine to use a Move operation instead of a Cut/Paste (the sequence is moved, then removed, leaving
the original code), at a substantial savings in memory and time. The size and location of the code in
the template does not matter. The codegen engine does all alignment based on the relative code
location, not the absolute location. The size and location of the mxwFramer frame also has no effect
on the final code location.

WARNING - If your template contains an XControl, you must use the “mxwFramer” option. Failure to
do so may cause LabVIEW to crash during code generation.

Adding a template means specifying the absolute location of the template on disk, specifying the
values of any constants which will be changed on its block diagram, and specifying the connections
(wires) to other templates.

Simply add another element to the CodeGenRecipe connections array. The full path to the template
is placed in the absolute path element of the connections cluster. The rest of the cluster is used to
specify wiring and constant value modifications.

To change the value of constants on the block diagram of templates before they are dropped, add
another element to the parameters array in the connections cluster. Names in both cases can be
either the name of the control or a "path" to the control. The "path" is the name of the control and the
names of all its parents, up to the root block diagram. See Appendix II for details of how to specify a
path. The value is usually a new value for the constant or default value for a control terminal.

Setting constant values is highly overloaded. See Appendix II for details. One commonly used
overload is setting a value on a case structure. This operation takes a U32 as its value. It changes the
case structure visible frame to the index given by the value, then removes the case structure, leaving
behind the code in that frame. This is useful for creating conditional code in a template. Note that the
index is based on the order the frames were created. You can NOT use the data type of the input
terminal on the case structure to set the frame. You must use a U32. For a default case structure,
TRUE is 1, FALSE is 0.

Wiring between templates is added in several ways. The codegen engine will automatically convert
constants to controls for wiring purposes. Add another element to the template connections array
in connections for every wire. The values are as follows:

Value Description
name of the terminal on the current
connector name
template to connect to
name of the terminal on another template to
connected to name
connect to
absolute index of the template the connected
connected to index
to terminal is on

The connected to index is absolute. This allows forward connections, but care must be used in
setting these numbers. Terminal tagging is the preferred method for determining terminal locations.
This technique is discussed in the template option Set Terminal ID below.

Adding Connector Pane Connections

Connections are made to the connector pane by adding another element to the connPane array. The
controls in each element are as follows:
Control Description
absolute index of which template the control is
template index
in
control name label of the control
the index of where on the connector pane to
term location
connect the terminal
connectorPaneName final name to set the label of the control

The functionality is overloaded to allow controls to be changed to locals using XML options on the
connectorPaneName. This is discussed in Appendix II as Convert to Local Variable.

Connection to the connector pane removes any uniquification string from a control/indicator and
prevents it from being deleted during final cleanup.

Other Options
There are other control options, inputs, and outputs on the codegen engine. These inputs and their
use is as follows:

Item Description
vi refnum Reference to a VI to script into. If not connected, the user is queried for a VI
This cluster contains several items which control some aspects of code generation.
These are

• frame delay (ms) - the delay, in milliseconds, added between the drop of each
template. This is a legacy control used to slow down code generation so the
user can see it happen more easily. DEFAULT - 0ms
• show diagram? - boolean which determines whether or not the diagram of the
target VI is shown during scripting. Codegen is significantly faster with this
parameter FALSE. DEFAULT – FALSE
• X location offset - When generating code with the block diagram open, the
engine moves the diagram origin so that the code to be dropped is in the
control
upper left corner of the window. This value is how many pixels from the left
edge of the diagram window the code will be dropped. DEFAULT - 20 pixels
• save new VI? - If TRUE, the newly generated VI is saved. If FALSE, it is not.
DEFAULT - FALSE
• Default Save Path - The default location to save the target VI and place a
directory for any subVIs. DEFAULT - location of the target or the default
LabVIEW location
• clear VI? - if TRUE, Clear all code and front panel objects from the target VI
before starting generation; if FALSE generate into the current code. DEFAULT
- TRUE
Item Description
This cluster contains information about the allowed area to drop templates. The area
restriction is due to an obscure LabVIEW diagram bug which produces insane
objects when wiring between objects which are the “correct” distance apart (distance
is a factor, but not the only one. You can wire from one edge of the diagram to the
other, but not from halfway to one edge to halfway to the other). The items in the
cluster are:

• startX - X location, in pixels, of the left edge of the first template drop.
DEFAULT - -7500
drop position • startY - Y location, in pixels of the top edge of the first template drop.
parms DEFAULT - -3800
• maxX - maximum X location of the right edge of generated code. A "carriage
return" will be done with the code if its bounds would be outside this limit.
DEFAULT - 7500
• maxY - maximum Y location of the bottom edge of generated code. A "return
to top" will be done with the code if its bounds would be outside this limit.
DEFAULT - 3800
• YInc - Spacing in pixels used between the bottom previous code and the top
of the next template when a "carriage return" is done. DEFAULT - 500

targetFileName Final name of the target VI

User event reference used to abort the codegen engine. Data type is boolean. Sending
abortEvent
the event will abort the engine.
vi refnum out VI reference of the final target VI
TRUE - the codegen engine was aborted, FALSE - the codegen engine ran to
aborted?
completion
An array containing information on each of the errors which occurred during code
generation. Each item contains the following information:

error stack • command.ID - the internal command which generated the error
• command.data - data used by the command
• error - LabVIEW error cluster which resulted from the command

Array containing all the VIs saved by the codegen engine. Each element corresponds
to a VI generated by the engine. Each element has the following items:

• library - library which contains the new VI. By default, this library will be
savedVIs
automatically generated if the target VI is in a project and has subVIs.
• main - location of the new VI
• subVIs - location of any subVIs of the mainVI saved
Codegen Engine Internals

Program Structure

Overview
The LabVIEW code generation engine is composed of two parts - a parser and a command processor.
The parser converts the input data to an array of commands, the command stack. The command
processor then executes these commands. The use of a command stack allows dynamic modification
of same. An example of this is inline code generation of subVIs.

Parser
The input to the parser is all the inputs to the standalone codegen engine. This is converted to
command format. The command format is a list of name--value pairs. These commands are sorted
into five stages:

1. Set Options
2. Drop Templates
3. Connect Wires
4. Connect To Connector Pane
5. Cleanup

Within each stage, the commands are created in the order they are given in the input data. However,
each stage is executed before the succeeding one. For example, all options are processed before
templates are dropped.

Set Options

Options can be anything to do with the way code is generated. Examples of this are the connector
pane pattern or the global template alignment. The CodeGenRecipe.options input can be used to
generate just about any options necessary. For example, it is currently used for setting the connector
pane pattern and rotation. Options include all information passed to the codegen engine but
CodeGenRecipe.connections and CodeGenRecipe.connPane. All options are processed before any
other code generation.

Drop Templates

At this stage, all templates are dropped. Location is determined either by global options or local
override. If a subVI is dropped which requires code generation, commands are placed on top of the
command stack and the subVI is generated in place before code generation continues. SubVI code
generation uses information from the CodeGenRecipe structure. Options set outside this structure
are taken from the main VI.

Connect Wires

Wires are connected at this stage. Since all templates have been dropped, routing can be efficiently
managed.
Connect To Connector Pane

All connections to the connector pane and to local variables are done during this stage.

Cleanup

At this point, a plethora of cleanup tasks is executed. Some examples are:

• delete temporary items

• remove uniquification
• delete empty structures
• remove bad wires
• save files

Command Processor
The command processor loops through the array of command-value pairs, executing each in turn. In
some cases, a command will result in the modification of the command stack. An example of this is
the generation of a subVI inline. The complete code generation recipe for the subVI is placed on the
top of the command stack and executed before proceeding.

The command processor keeps two stacks - a template stack and a diagram stack. The template
stack has the current working template on the top. The diagram stack has the current working
diagram on top. Both stacks are implemented as functional globals to allow easy access from
anywhere in the code.

All “globals,” with the exception of the command stacks, are implemented as single-element queues
(DVRs did not exist when this architecture was designed). This cuts down on block diagram clutter,
allows universal access and easy data type modification.

If an error occurs during processing of a command, it is dropped onto an error stack and cleared.
This allows the codegen engine to complete as much as possible of the code generation. On exit, the
error stack is output. The first error to occur is output as the standard LabVIEW error cluster.

Status Reporting
The codegen engine creates a notifier named "mxwScript_StatusNotifier". It has a cluster data type
composed of

• string status — this normally contains identifying information for the current task
• I32 loopCount--- the number of remaining items left to be processed. This is −1 on non-
command tasks, except those indicated below. Note that this number can increase during
execution due to generating code for subVIs, chaining wires, and other such tasks.
• U32 msTimer — current value of the millisecond timer
• error cluster error — error resulting from the current step

Creation of the notifier occurs when the codegen engine VI is entered. Notifier events occur at the
following locations in the code. The status string for each is given as the title of the location.

• startScripting — occurs at the beginning of the codegen engine before anything else occurs.
Signals the start of converting the data structures into engine commands.
 • parseData — occurs after data is parsed to include any errors which may have occurred.
loopCount is set to the number of commands generated.
• startCommands — occurs at the beginning of the command processor. Signals the start of the
command processor. loopCount is set to the original number of commands input.
• command — occurs at the end of a command so that any errors associated with execution of
the command can be included. loopCount is set to the number of commands left to execute.
status is set to the actual command string.
• startSaveVI — occurs at the start of the final save of the scripted VI. Will not occur if the VI is
not saved.
• endSaveVI — occurs after the final save of the scripted VI. Will not occur if the VI is not saved.
• abort — occurs after an abort event is processed. loopCount is set to the number of
unprocessed commands.
• endScripting — signals the end of the codegen engine execution and includes the final error, if
any.

At the end of the codegen engine, the notifier is force-destroyed so that all notifiers waiting on it will
exit. The client does not need to destroy the notifier reference. To avoid errors, the client may choose
to exit when the endScripting status is received.

This notification can be used to give the user status from the engine and for debugging purposes.
Look at MonitorCodegen.vi in the attached code for an example of how to use the notifier to monitor
codegen tasks.

Appendix I - Global Options

Overview
Global options are used to change the default behavior of the codegen engine. Most have local
variants, as well. For example, the drop relation can be changed on a global or per template basis.

Set options by setting the value of the options array. Helper functions to generate options can be
found in the attached code. They have the name mxwScript_API_Option_*.vi.

Items are listed in alphabetical order. The option is listed on the first line. Valid values of the option
are then listed, followed by an explanation. Here is an example

MakeCoffee
• Robusta - first option
• Arabica - second option

This option makes coffee for you in the morning. The options give the type of coffee to prepare.
Options

AutoDiagramChange
• True
• False

Set whether the codegen engine automatically changes diagrams. The default is "True". In this case,
the codegen engine searches each template dropped for a text constant with label "tag". If found, the
current diagram is changed to the diagram the text constant is in and the text constant is deleted.
This does not occur when the value is "False". The programmer changes the diagram using XML
options on the template name. Note that the value is case insensitive and only the first letter is used.

This is a legacy option and should not be used for new development. Use the XML options to do this
directly.

CacheTemplates
• True
• False

Sets whether the codegen engine keeps templates open after first use (True) or closes them and
reopens them for each use (False). The default is "False". The value is case insensitive and only the
first letter is used.

CleanupOption
• XML options string — see description for details

Sets what actions will be performed in the cleanup stage at the end of code generation. Note that
legacy operations (e.g. RemoveEmptyStructures) are handled with separate options. This may change
in the future. This command has three main XML tags. They are:

• Option — string containing the name of the option

• Time — string containing an I32 integer giving the ordering of when the option should be
executed. All options with the same Time are executed in the order posted. Options with
different Times are executed in sequential Time order. A Time of -1 always executes in the
last batch.
• Data — XML string containing the data for the particular option.

Available Options and their Data format are as follows:

• RemoveStructure - Remove a structure, leaving the code behind. If the structure is multi-
framed, the currently showing code will be saved. The parameters for the remove are:

◦ StructureName — name of the structure to remove. This can be a "Terminal ID". It

contains two tags
 ▪ Value — the name of the structure or its "Terminal ID"

▪ IsTerminalID — TRUE/FALSE indicating whether or not theValueis a "Terminal ID".

◦ TemplateIndex — absolute index of the template the structure is in. This parameter is not
used if a "Terminal ID" is used forStructureName. Defaults to 0.

◦ FrameIndex — U32 specifier of what frame to expose before removing the structure. Only
needed if the target is a stacked, multi-frame structure. Defaults to 0.

ConnectorPane
• paneID - integer number between 4800 and 4835

Sets the connector pane pattern. See the LabVIEW documentation for what patterns correspond to
what numbers. If the number is invalid or this option is not used, the connector pane is set to
pattern 4815, the 4-4-4 pattern.

ConnectorPaneRotation
• n - integer between 0 and 3 indicating the number of 90° counterclockwise rotations to
perform
• H - flip horizontally (case insensitive)
• V - flip vertically (case insensitive)
• any combination of the above - executed in the order given

Sets the rotation of the connector pane. The string can be of arbitrary length. For example, to rotate
90° clockwise and flip vertically, the value would be "3V"

DropRelation
• XML String

Sets the default relationship between the reference points on the template and block diagram
(specified by the TemplateRef and TargetRef options below). This is used to calculate the drop
position for new templates. The format is given below. If not present, the default value is Right with
zero offset and space added for wire routing. Note that only that data actually used needs to be in the
string.

<Direction>Left/Right/Above/Below</Direction>
<Distance>distance between ref points in pixels</Distance>
<AddWireSpace>T/F</AddWireSpace>
 • Direction — Specifies the direction from the target block diagram reference point to the
template reference point. For example, a value of Right (the default value) would place a
template to the right of the block diagram reference point.
• Distance — Specifies the distance in pixels between the two reference points. The default is
zero.
• AddWireSpace — Specifies whether or not to add space for wiring to the Distance parameter.
Default is "T" (TRUE). Only one letter is read. Capitalization is not important.

ErrorDialog
• True
• False

Sets whether the error dialog is displayed on error (True) or not (False). The default is "False". The
value is case insensitive and only the first letter is used.

LVSpecificTemplatePaths
• XML String

Sets whether or not to use LabVIEW version specific template paths. This is useful if you are
generating code to multiple versions of LabVIEW and need to specify which template set to use. Only
those elements used for a particular specification need to be included in the string. For example, if
PathGenerationType equals "Name", there is no need to include LocationIndex.

<PathGenerationType>IndexFromEnd/Name/BeforeLLB</PathGenerationType>
<LocationIndex>positive integer index from end of path</LocationIndex>
<LocationName>name to search for in path</LocationName>
<PathFormat>format string</PathFormat>
<UseLVVersionIncrement>True/False</UseLVVersionIncrement>

• PathGenerationType — Specification for how the path is modified. There are three options:
1. IndexFromEnd — The new path information is inserted at a specified object distance
from the end of the path. The value 0 results in the path information being inserted
just before the template VI in the path. For example, if this value is 1 and the path is
C:\Program Files\MyAppDirectory\codeGen\library.llb\myVI.vi, the new path
information will be inserted after "codeGen".
2. Name — The name of the directory to put the new information afteris specified. Given
the above path, to get the same effect as the above example, the "Name" would be
specified as "codeGen". Directories and input Name are both coerced to lower case
before checking for match. This option also works if the template VI is in an LLB whose
name is Name.llb. In this case, the new information is put before the LLB in the path,
similar to the BeforeLLB option.
3. BeforeLLB — This option assumes the templates are in an LLB with name suffix .llb.
The extra directory information is inserted just before the LLB.
• LocationIndex — If PathGenerationType equals "IndexFromEnd", this option gives the index
value. The value must be a positive integer.
 • LocationName — If PathGenerationType equals "Name", this option gives the value of the
name. Case sensitivity is platform dependent.
• PathFormat — LabVIEW format string used to generate the path name to be inserted. This
path name may include 1 to 3 "%d" items for the code to fill in with the LabVIEW version
number. If there are no "%d"s, the path is inserted unchanged. If you use one "%d", it will be
replaced with the year version number for LabVIEW 9.0 (LabVIEW 2009) and above, and the
internal version number for LabVIEW 8.6.x and below (increment will be used if
UseLVVersionIncrement is "TRUE"). If you use 2 "%d"s, they will be replaced with the major
and minor version numbers, in that order. If you use three "%d"s, they will be replaced with
the major, minor, and increment versions.
• UseLVVersionIncrement — If "True", the format string will use the major, minor, and
increment version numbers of the LabVIEW the application is running in. If "False", the
default, only the major and minor version numbers will be used. This value is only used if the
PathFormat contains a single "%d".

PasswordProtected
• password

Use this option to unlock the main VI that code generation is occurring in. The password is used to
unlock the VI at the beginning of code generation and lock it at the end. The password is not entered
in the password cache.

RemoveEmptyStructures
• True
• False

Set whether the codegen engine automatically removes empty WHILE loops and flat sequence frames
and structures. The default is "True". In this case, the codegen engine searches the finished code for
empty flat sequence frames and WHILE loops containing three elements (presumed to be a
control/constant, a wire, and the loop terminator node). Any found are deleted. The search/deletion
sequence is WHILE loops — sequence frames — WHILE loops. No search or deletion occurs when the
value is "False". The “True” default exists for legacy National Instruments applications and is not
recommended for general use.

StringTableList
• XML String

Sets values into the internal string tables of the codegen engine. These are used primarily for
localization purposes.
<mxwCGenStringTable type="engine/target">
<string index="n">escaped string table entry</string>
</mxwCGenStringTable>

• mxwCGenStringTable — top level tag for the XML string. It has one optional option, "type",
which specifies whether the string table entries pertain to the engine itself (engine) or the
target VI (target). Codegen engine users will only use the second. If type is not present, it
defaults to "target".

• string — interior tag which defines a string table entry. The index in the string table, an
integer, is specified by the option "n". The string contained between the tag must have all
greater than and less than signs (">" and "<") escaped with ">" and "<" respectively. Multiple
copies of this tag are expected. They must have unique values for index.As of this writing, the
strings associated with the engine (type="engine") are as follows:

Index Default Value Use

Title for codegen target file
0 Save VI
dialog.
Formatting string to create
1 %s_subVIs subdirectory for subVIs from
main VI title.
Title for dialog if selected VI
2 VI Exists in Memory - Choose Another Name
name is in memory.
3 Code Generation Error Title of error dialog.
4 The following errors occurred during code generation: Header text for error dialog.
Header for error code column of
5 Code
error dialog.
Header for explanation column of
6 Explanation
error dialog.
Label for accept button on error
7 Accept Code Generation
dialog.
Use the current code generation. The code may have
8 Explanation of accept button.
errors or not function as expected.
Label for revert button on error
9 Revert to Original Code
dialog.
Change back to the original code. This will also undo any
10 configuration changes that may have been done to Explanation of revert button.
Express VIs (default behavior).
Label for export button on error
11 Export Errors to File
dialog.
12 Save the errors to a text file. Explanation of export button.
13 Internal error Internal error explanation.

TargetRef
• XML String
Sets the default target diagram reference position method. The format is given below. If not present,
the default value is Type set to OutputAverage. Note that only that data actually used needs to be in
the string.

<Type>AbsoluteOnRoot/AbsoluteOnTarget/RelativeToTemplate/RelativeToTerminal/RelativeToExi
stOnRoot</Type>
<AbsoluteData>
<X>X position in pixels</X>
<Y>Y position in pixels</Y>
</AbsoluteData>
<TemplateData>
<Tag>Tag identifying the template</Tag>
<Index>integer -1...∞</Index>
<Type>Absolute/OutputAverage/Terminal</Type>
<RefPosition>TopLeft/Top/TopRight/Left/Middle/Right/BottomLeft/Bottom/BottomRight</R
efPosition>
<TermName>name of terminal</TermName>
<TermIs>Path/Tag</TermIs>
<TemplateData>
<TerminalData>
<Tag>tag to the terminal</Tag>
<Path>path to the terminal</Path>
</TerminalData>
<RelativeToExistData>
<RefPosition>TopLeft/Top/TopRight/Left/Middle/Right/BottomLeft/Bottom/BottomRight</R
efPosition>
</RelativeToExistData>

• Type — Specifies how the target reference point will be calculated. Possible values and their
meanings are as follows.

• AbsoluteOnRoot — The reference point is an absolute position on the root of the block
diagram.
• AbsoluteOnTarget — The reference point is an absolute position on the target block
diagram.
• RelativeToTemplate — (Default) The reference point is relative to a previously dropped
template.
• RelativeToTerminal — The reference point is relative to a terminal.
• RelativeToExistOnRoot — The reference point is relative to existing code on the root of
the target VI block diagram
• AbsoluteData — This value is only used if the Type is AbsoluteOnRoot or AbsoluteOnTarget.
The values specify the X and Y location in pixels from the top left of the coordinate system.
• TemplateData — This value is only used if the Type is RelativeToTemplate. Its contents and
their meanings are as follows.
• Tag — Tag used to look up the template index. Overrides Index. Either it or Index
must be present.
• Index — (Default) Tag used to specify the template index. A value of -1, the default,
means to use the previously dropped template.
• Type — specifies how the template reference position is determined. The options are:
• Absolute - This specifies a point on the edged of the bounding box of the
template. The possible values are:TopLeft, Top, TopRight, Left, Middle, Right,
BottomLeft, Bottom, BottomRight.
 • OutputAverage - The X position is the right edge of the template. The Y position
is the average Y position of the output control terminals which connect to the
template to be dropped. If there are no connections to the template to be
dropped, set toType Absolutewith valueRight. This is the default value.
• Terminal - The XY position starts at the center of the specified terminal (see
TermName and TermIs). It is then projected to the side of the template closest
to the reference point on the block diagram. This is specified by
RefPntRelation.
• RefPosition — This is only valid if Type is “Absolute”. It specifies where on the template
the reference point is located. Default value is “TopLeft”.
• TermName — This is only valid if Type is “Terminal”. It specifies the terminal tag or
path to the terminal.
• TermIs — This is only valid if Type is “Terminal”. It specifies whether TermName is a
terminal tag (value=Tag) or a path (value=Path).
• TerminalData — This value is only used if Type is equal to “RelativeToTerminal”. The
reference point is set to the center of the terminal, reflected to the edge of the terminal's
parent closest to the drop location. Only one of Tag or Path should be present. The last one
specified is the one used. The values and their meanings are as follows.
• Tag — The terminal is located using a tag, specified in the value.
• Path — The terminal is specified using a full path, specified in the value.
• RelativeToExistData — This is only valid if Type is equal to RelativeToExistOnRoot. The
reference position is set to one of the cardinal positions on the bounding box of the existing
code.
• RefPosition — This specifies which cardinal position on the bounding box of the
existing code that the reference point will be located. Default value is TopLeft.

TemplateRef
• XML String

Sets the default template reference position method. The format is given below. If not present, the
default value is Type set to InputAverage.

<Type>Absolute/InputAverage/Terminal</Type>
<RefPosition>TopLeft/Top/TopRight/Left/Middle/Right/BottomLeft/Bottom/BottomRight</RefPosit
ion>
<TermName>name of terminal</TermName>
<TermIs>Path/Tag</TermIs>

• Type — specifies how the template reference position is determined. The options are:
• Absolute - This specifies a point on the edged of the bounding box of the
template. The possible values are: TopLeft, Top, TopRight, Left, Middle, Right,
BottomLeft, Bottom, BottomRight.
• InputAverage - The X position is the left edge of the template. The Y position is
the average Y position of the input control terminals which connect to the
previous template. If there are no terminals connected to the previous template,
Type is set to “Absolute” with value “Left”.
• Terminal - The XY position starts at the center of the specified terminal (see
TermName and TermIs). It is then projected to the side of the template closest
 to the reference point on the block diagram. This is specified by
RefPntRelation.
• RefPosition---This is only valid if Type is “Absolute”. It specifies where on the template
the reference point is located. Default value is “TopLeft”.
• TermName---This is only valid if Type is “Terminal”. It specifies the terminal tag or
path to the terminal.
• TermIs---This is only valid if Type is “Terminal”. It specifies whether TermName is a
terminal tag (value=Tag) or a path (value=Path).

UniquificationObjects
• XML String

This option sets what objects will be uniquified by the codegen engine. Uniquification is the addition
of template specific text to all object names specified to prevent name collision during code
generation. Uniquification is removed in a cleanup step.

<ObjectType>LabVIEW Object Type 1</ObjectType>

<ObjectType>LabVIEW Object Type 2</ObjectType>
&c.

There can be multiple ObjectType elements. Each element specifies an object type (LabVIEW class
name) to be uniquified. By default, FlatSequence, Structure, Constant, ControlTerminal, and XNode
objects are uniquified. Any object type which will be wired to must be uniquified.

UseLibrariesToSave
• XML String

This option sets whether or not to save generated code in a library. If not present, the default value is
to save subVIs in a subdirectory.

<SaveInLibrary>Always/Never/IfSubVIs</SaveInLibrary>
<IconPath>path to the icon image file</IconPath>
<Name>name of the library</Name>
<DisplayName>localized name of the library</DisplayName>
<Description>description of the library</Description>
<HelpPath>path to the help file</HelpPath>
<HelpTag>tag to the help for the library in the help file</HelpTag>

• SaveInLibrary — There are three options.

• Always---The main VI is saved in a library at the save location and all subVIs are saved
in a directory of the library called "subVIs". On disk, the main VI is saved at the save
location and subVIs are in a subdirectory called mainVI_subVIs, where mainVI is the
file name of the main VI. The library is saved parallel to the main VI.
• Never---The library is not created and VIs are saved in the same manner as the Always
option. This is the default value.
 • IfSubVIs---The Always action will be used if the saved VI has subVIs. Otherwise, the
Never action will be used.
• IconPath — Optional value. If present, the library icon is updated to the image in the image
file.
• Name — Optional value. Specify the name to save the library to disk. If not present or an
empty string, the name defaults to the file name of the main VI.
• DisplayName — Optional value. Specify the localized display name to use for the library. If not
present or an empty string, the name defaults to the file name of the main VI.
• Description — Optional value. If present, the description of the library is set to its value.
• HelpPath — Optional value. If present, the help path of the library is set to its value. You
should also specify the HelpTag value if this is specified.
• HelpTag — Optional value. If present, the help tag of the library is set to its value. You should
also specify the HelpPath value if this is specified.

WireRouting
Sets the default wire routing parameters for the project. This can be overridden on a wire-by-wire
basis for optimization using the WireRouting tag. The option string is an XML string with the
parameters for the wire routing. Currently, this is just the algorithm, but will be expanded in the
future to include algorithm parameters.

<Algorithm>None/LV/AI</Algorithm>

Algorithm — The algorithm used to route the wires on the diagram.

• None---No control points will be used on the wire. It will be drawn as a straight line or
an "L" shaped line. This is a high-performance option
• LV---The LabVIEW autoroute algorithms will be used. Note that on complex diagrams,
timeout is likely, resulting in no control points. This is a medium performance,
medium quality option.
• AI---Use an artificial intelligence based method for routing wire. The algorithm is a
modified depth-first Djikstra's algorithm. This is the default value.

Appendix II - Item Specific Options

Overview
Many operations in scripting require sending some sort of text parameters to the scripting engine.
These parameters often go beyond a simple one element text string. For example, connecting a sweep
parameter to the connector pane can involve creating a new element in a cluster which is already
connected to the connector pane and connecting to an element buried in an array of clusters. To
enable an extensible architecture for this type of encoding, XML encoding is used for the text strings.
If no XML tags are present, standard processing is used.

XML encoding is added using the following syntax (all whitespace between XML tags is ignored):
normalTextString~~<engine><GUID>{target scripting engine
GUID}</GUID><otherXML>...</otherXML></engine><engine>...</engine>

• normalTextString - the text string you would normally use for the input
• engine - top level XML container which has all the options for a particular codegen engine.
There can be multiple engine containers after the double tilde.
• GUID - GUID of the target scripting engine (LabVIEW is {68104F7A-688D-4A74-B7E8-
7C76AA560C98})
• otherXML - placeholder for any other XML; see below for valid syntax

This syntax is dictated by other uses for the codegen engine which are not needed by the stand-alone
user. Use of the supplied API functions automatically create this syntax.

Many options are booleans which require a True/False value. True/False values only read the first
character and are case insensitive.

Setting Paths to Objects

When locating an object for wiring or to set its value, the location of the object is specified as a
backslash separated path. The pane of a multi-pane structure or the index of an array element is
specified with a "**" appended to the end of the object name. Terminals are specified by name by
appending "@@" and the name to the object. Terminals are specified by index by appending "###" and
the index to the object name. The general specification is thus:

[container name[**pane number or index]][...]object name[###terminal number][@@terminal name]

For example: you have a constant (MyConstant) buried in a simple True/False case selector
(MyCaseSelector) which is inside a while loop (MyWhileLoop). The constant is in the False case,
which is the first frame (index 0). The constant name should
beMyWhileLoop\MyCaseSelector**0\MyConstant. This format is also used when specifying
constants to be converted to controls and connected to the connector pane. If said constant is an
element of an array, the number following "**" specifies the array index to overwrite with the control
input.

Second example: you wish to find the terminal error out on a just created Express VI, MyExpressVI,
located on the root of the block diagram. The path would be MyExpressVI@@error out. If you knew
the terminal index was four, you could also specify the path asMyExpressVI###4

Template Options and Name Overloading

Options
When using the following options, the template name is in the normalTextString. Options are
encoded as normal in the otherXML.
Change Current Diagram to Diagram on Template

This option is used to move the diagram pointer to a diagram on the current template. The location
on the current template is specified by Path. This option replaces the search for the tag string. When
this option is used, the global option AutoDiagramChange should be set to FALSE.

<SetDiagram>
<Path>pathOnDiagram</Path>
</SetDiagram>

Create a New Diagram Reference

This option is used to create a new diagram reference. It adds an element to the diagram reference
array. The new ID and the Path on the template diagram are specified in the otherXML. Note that
the final diagram may be at a more complex path if the template is being dropped into another
subdiagram. This option can be used multiple times for a single template if the template has multiple
diagrams.

<CreateDiagramRef>
<ID>newUniqueName</ID>
<Path>pathOnDiagram</Path>
</CreateDiagramRef>

Create Controls/Indicators on a Node

This option is used to create controls and/or indicators on a particular node in the template. The
options are specified in the otherXML. All unconnected terminals will create controls and/or
indicators. By default, both controls and indicators are created, although either of these may be
turned off. The controls/indicators may be uniquified so that connection and removal will work
normally. This option may be used multiple times to modify multiple nodes on the same template.

<CreateControlsIndicators>
<Node>match pattern for node name in template</Node>
<Uniquify>T/F</Uniquify>
<Controls>T/F</Controls>
<Indicators>T/F</Indicators>
</CreateControlsIndicators>

• Node — Text string used in a match pattern to find the node.

• Uniquify — If "T", the controls/indicators will be uniquified to match the rest of the template.
If "F", the default, no uniquification will be done. Only use uniquification if connections will be
made to the terminals.
• Controls — Flag to determine whether or not to create controls on the inputs which are not
connected to anything else.
• Indicators — Flag to determine whether or not to create indicators on the outputs which are
not connected to anything else.

Create Space Before Dropping Template

This option is used to create space on the diagram before dropping the new code. The algorithm is
determined by the current drop algorithm. Default is "F" (False).
<CreateSpace><Value>T/F</Value></CreateSpace>

Drop Into Specific Diagram

This option is used to drop a template into a specific diagram instead of the current diagram. It resets
the diagram stack to the diagram dropped into. DiagramRef gives the unique diagram reference of
the diagram to drop into. Diagram references are created with the CreateDiagramRef option. To drop
into the root diagram, specify "mxwRoot" as the DiagramRef.

<DropInto>
<DiagramRef>name</DiagramRef>
</DropInto>

Password

This options is used to allow dropping and using a template which is password protected.

<Password>password</Password>

Reference Point Relationship

The template drop position is calculated by finding reference points on the target block diagram and
the templateand then locating them with a certain relationship. This option specifies that
relationship. The format of the option is as follows.

<RefPntRelation>
<Direction>Left/Right/Above/Below</Direction>
<Distance>distance between ref points in pixels</Distance>
<AddWireSpace>T/F</AddWireSpace>
</RefPntRelation>

• Direction — Specifies the direction from the target block diagram reference point to the
template reference point. For example, a value of Right (the default value) would place a
template to the right of the block diagram reference point.
• Distance — Specifies the distance in pixels between the two reference points. The default is
zero.
• AddWireSpace — Specifies whether or not to add space for wiring to the Distance parameter.
Default is "T" (TRUE).

Revert Before Modifying Template

This option is used to suppress the Revert of a template before it is modified. Normally, a template is
opened, then reverted to ensure that if the template was still in memory from a previous use, the
previous changes, such as uniquification and conditional code, are removed. However, it is not
desirable to revert templates which are only used once and which require a significant amount of
time to revert. This option allows the user to suppress revert. Default is "T". Do not use this option
unless you are very sure of what you are doing.
<Revert>
<Value>T/F</Value>
</Revert>

Set Terminal ID

This option is used to associate a unique string ID with a particular terminal on the template to be
dropped. This is used later when connecting terminals to specify as a connection target. See the
ConnectID option. Note that there can be multiple copies of this option, one for each terminal on the
template.

<TerminalID>
<Path>control label (can be full path)</Path>
<ID>newUniqueName</ID>
</TerminalID>

Set Template ID

This option is used to tag the template with a specific ID so that it can be referred to later in the
scripting process without knowing its template index. If this option is not set, the default value is the
template index.

<ID>
<Value>name</Value>
</ID>

Target Diagram Reference Point

This option sets the method used to generate the reference point on the target block diagram used to
calculate the drop position of the template. If not present, the default values will be used. The format
is as follows.

<TargetRefPnt>
<Type>AbsoluteOnRoot/AbsoluteOnTarget/RelativeToTemplate/RelativeToTerminal/RelativeT
oExistOnRoot</Type>
<AbsoluteData><X>X position in pixels</X><Y>Y position in pixels</Y></AbsoluteData>
<TemplateData>
<Tag>Tag identifying the template</Tag>
<Index>integer -1...∞</Index>
<Type>Absolute/OutputAverage/Auto/Terminal</Type>
<RefPosition>TopLeft/Top/TopRight/Left/Middle/Right/BottomLeft/Bottom/BottomRi
ght</RefPosition>
<TermName>name of terminal</TermName>
<TermIs>Path/Tag</TermIs>
</TemplateData>
<TerminalData>
<Tag>tag to the terminal</Tag>
<Path>path to the terminal</Path>
<RefPosition>TopLeft/Top/TopRight/Left/Middle/Right/BottomLeft/Bottom/BottomRi
ght</RefPosition>
</TerminalData>
 <RelativeToExistData>
<RefPosition>TopLeft/Top/TopRight/Left/Middle/Right/BottomLeft/Bottom/BottomRi
ght</RefPosition>
</RelativeToExistData>
</TargetRefPnt>

• Type — Specifies how the target reference point will be calculated. Possible values and their
meanings are as follows.

• AbsoluteOnRoot — The reference point is an absolute position on the root of the block
diagram.
• AbsoluteOnTarget — The reference point is an absolute position on the target block
diagram.
• RelativeToTemplate — (Default) The reference point is relative to a previously dropped
template.
• RelativeToTerminal — The reference point is relative to a terminal.
• RelativeToExistOnRoot — The reference point is relative to existing code on the root of
the target VI block diagram
• AbsoluteData — This value is only used if the Type is “AbsoluteOnRoot” or
“AbsoluteOnTarget”. The values specify the X and Y location in pixels from the top left of the
coordinate system.
• TemplateData — This value is only used if the Type is “RelativeToTemplate”. Its contents and
their meanings are as follows.
• Tag — Tag used to look up the template index. Overrides Index. Either it or Index
must be present.
• Index — (Default) Tag used to specify the template index. A value of -1, the default,
means to use the previously dropped template.
• Type — specifies how the template reference position is determined. The options are:
• Absolute - This specifies a point on the edge of the bounding box of the
template. The possible values are: TopLeft, Top, TopRight, Left, Middle, Right,
BottomLeft, Bottom, BottomRight.
• OutputAverage - The X position is the right edge of the template. The Y position
is the average Y position of the output control terminals which connect to the
template to be dropped. If there are no connections to the template to be
dropped, set toType “Absolute” with value “Right”. This is the default value.
• Terminal - The XY position starts at the center of the specified terminal (see
TermName and TermIs). It is then projected to the side of the template closest
to the reference point on the block diagram. This is specified by
RefPntRelation.
• RefPosition — This is only valid if Type is “Absolute” or “Terminal”. It specifies where
on the template or terminal the reference point is located. Default value is “TopLeft”.
• TermName — This is only valid if Type is “Terminal”. It specifies the terminal tag or
path to the terminal.
• TermIs — This is only valid if Type is “Terminal”. It specifies whether TermName is a
terminal tag (value=Tag) or a path (value=Path).
• TerminalData — This value is only used if Type is equal to “RelativeToTerminal”. The
reference point is set to “RefPosition”. Only one of Tag or Path should be present. The last one
specified is the one used. The values and their meanings are as follows.
• Tag — The terminal is located using a tag, specified in the value.
• Path — The terminal is specified using a full path, specified in the value.
• RefPosition — The cardinal position on the terminal which is calculated.
 • RelativeToExistData — This is only valid if Type is equal to RelativeToExistOnRoot. The
reference position is set to one of the cardinal positions on the bounding box of the existing
code.
• RefPosition — This specifies which cardinal position on the bounding box of the
existing code that the reference point will be located. Default value is TopLeft.

Template Reference Point

This option sets the method used to generate the reference point on the template used to calculate
the drop position of the template. If not present, the default values will be used. The format is as
follows.

<TemplateRefPnt>
<Type>Absolute/InputAverage/Terminal</Type>
<RefPosition>TopLeft/Top/TopRight/Left/Middle/Right/BottomLeft/Bottom/BottomRight</R
efPosition>
<TermName>name of terminal</TermName>
<TermIs>Path/Tag</TermIs>
</TemplateRefPnt>

• Type — specifies how the template reference position is determined. The options are:
• Absolute - This specifies a point on the edged of the bounding box of the template. The
possible values are: TopLeft, Top, TopRight, Left, Middle, Right, BottomLeft, Bottom,
BottomRight.
• InputAverage - The X position is the left edge of the template. The Y position is the
average Y position of the input control terminals which connect to the previous
template. If there are no terminals connected to the previous template, Type is set to
“Absolute” with value “Left”.
• Terminal - The specified terminal (see TermName and TermIs) is located. The cardinal
position of the terminal, minus its label, specified by RefPosition is then calculated
and returned.
• RefPosition — This is only valid if Type is “Absolute” or “Terminal”. It specifies where on the
template or terminal the reference point is located. Default value is “TopLeft”.
• TermName — This is only valid if Type is “Terminal”. It specifies the terminal tag or path to
the terminal.
• TermIs — This is only valid if Type is “Terminal”. It specifies whether TermName is a terminal
tag (value=Tag) or a path (value=Path).

Name Overloading
The following name overloadings are supported for the template name. Note that these must end in
“.vi” due to legacy application restrictions on the codegen engine.

1. End.vi - Signals the end of code generation in a particular diagram. Causes a pop of the
diagram pointer.
2. NewFrame.vi - Add a new frame to the current flat sequence structure. If the current diagram
pointer is not in a flat sequence frame, do nothing.
3. mxwDirectDrop(VIName) - Drop “VIName” as a VI, not a template. Parameters can be set and
wires connected to the inputs and outputs of the VI.
4. mxwNoOp.vi - Do nothing in the command parser for one iteration. This is used to allow
deletion of templates by post-processors without disturbing the template indices of succeeding
code.
 5. mxwRunAddOn.vi - Run an add-on VI. Custom parameters for the VI are sent in the normal
parameters array for the template specification. otherXML must contain the following tags:
• Context - the context to run the VI in on LabVIEW 8+ systems. Valid values are "VI"
and "MyComputer" (default).
• Path - full path to the VI to run
6. mxwRemoveStructure.vi (not implemented yet) - Remove a structure, leaving the code
behind. If the structure is multi-framed, the currently showing code will be saved. The
otherXML gives the parameters for the remove. These are:
• StructureName - name of the structure to remove. This can be a "Terminal ID". It
contains two tags:
• Value - the name of the structure or its "Terminal ID"
• IsTerminalID - TRUE/FALSE indicating whether or not the Value is a "Terminal
ID".
• TemplateIndex - absolute index of the template the structure is in. This parameter is
not used if a "Terminal ID" is used for StructureName . Defaults to 0.
• FrameIndex - specifier of what frame to expose before removing the structure. Only
needed if the target is a stacked, multi-frame structure. Defaults to 0.

Connecting To the Connector Pane

Connecting to the connector pane is overloaded to handle several special cases. These are:

• Converting a constant to a control, then connecting to the connector pane

• Dynamically adding another item to a cluster connected to the connector pane
• Specifying a connector pane terminal
• Converting a control/constant to a local
• Simple deuniquification without connecting to the pane

Here are their formats with all valid options. Options are enclosed in curly brackets. As usual with
XML, whitespace between tags is irrelevant.

Template Control Name Encoding

Template control names may use the path information mentioned above. If no path information is
present, a Traverse operation is used to find the object. The codegen engine is responsible for
determining the input object type and taking appropriate action.

Deuniquify Only

If used, this option disables connection to the connector pane and renames the object. If the
connectorPaneName is an empty string, this commmand simply deuniquifies the object. If not, the
object is renamed to connectorPaneName. The option is specified as follows in the otherXML:

<DeuniquifyOnly>
<Value>T/F</Value>
</DeuniquifyOnly>

Value — specifies whether the control will be simply deuniquified (TRUE) or connected/converted to
something else. If this option is present with value TRUE, it overrides all other options.
Parameter Name Encoding

Connecting to the Connector Pane

The name of the new connector pane control is taken from the normalTextString. The terminal
number is specified as follows in the otherXML:

<ConnectToPane>
<TermNumber>terminal number on connector pane</TermNumber>
<ThisConnectionIs>required/recommended/optional/dynamic dispatch</ThisConnectionIs>
</ConnectToPane>

• TermNumber — Specifies the terminal number on the connector pane to connect the
output/input to. Value is an integer between 0 and the maximum for the connector pane
chosen.
• ThisConnectionIs — Specifies the wiring rule. Valid values are "required", "recommended",
"optional", and "dynamic dispatch". Capitalization does not matter. This parameter is optional
and defaults to "recommended".

Connect to an Array Connected to the Connector Pane

Use this option to dynamically create arrays for input and output from the VI. This functionality
creates an array and links it to the connector pane, if necessary, then puts the control into the array,
again if necessary, and links the wire to a new array build input on the block diagram. The terminal
number of the array and the array name are specified as follows in the otherXML:

<ConnectToArray>
<ArrayName>name of the array</ArrayName>
<TermNumber>terminal number on connector pane</TermNumber>
<ThisConnectionIs>required/recommended/optional/dynamic dispatch</ThisConnectionIs>
</ConnectToArray>

• ArrayName — Specifies the name of the array, which will be connected to the connector pane
at TermNumber and connected to the control specified by normalTextString. If the array
already exists, this input is ignored.
• TermNumber — Specifies the terminal number on the connector pane to check for a cluster. If
the cluster exists, the control is added to it and the new connection on the block diagram
wired. If the cluster does not exist, it is created, then the control added and wiring done.
• ThisConnectionIs — Specifies the connection status. Valid values are "required",
"recommended", "optional", and "dynamic dispatch". Capitalization does not matter. This
parameter is optional and defaults to "recommended".

Connect to a Cluster Connected to the Connector Pane

Use this option to dynamically create clusters for input and output from the VI. This functionality
creates a cluster and links it to the connector pane, if necessary, then puts the control into the
cluster, and links the wire to the new cluster input on the block diagram. The name of the new
control in the cluster is taken from the normalTextString. The terminal number of the cluster and
the cluster name are specified as follows in the otherXML:
<ConnectToCluster>
<ClusterName>name of the cluster</ClusterName>
<TermNumber>terminal number on connector pane</TermNumber>
<ThisConnectionIs>required/recommended/optional/dynamic dispatch</ThisConnectionIs>
</ConnectToCluster>

• ClusterName — Specifies the name of the cluster, which will be connected to the connector
pane at TermNumber and connected to the control specified by normalTextString. If the
cluster already exists, this input is ignored.
• TermNumber — Specifies the terminal number on the connector pane to check for a cluster. If
the cluster exists, the control is added to it and the new connection on the block diagram
wired. If the cluster does not exist, it is created, then the control added and wiring done.
• ThisConnectionIs — Specifies the connection status. Valid values are "required",
"recommended", "optional", and "dynamic dispatch". Capitalization does not matter. This
parameter is optional and defaults to "recommended".

Convert to Local Variable

The name of the control to link to is taken from the normalTextString. The template number is
specified as follows in the otherXML:

<ConvertToLocal>
<ReadWrite>Auto/Read/Write</ReadWrite>
</ConvertToLocal>

• ReadWrite (optional) — specifies whether the created local is a read or write local. Valid values
are "Auto", "Read", and "Write". Capitalization is unimportant. If set to "Auto", the read/write
value is taken from the Indicator property of the control it links to. Invalid values are treated
as "Auto". If the parameter does not exist, its value will be set to "Auto".

Do not use the shorthand for setting an empty XML tag, <ConvertToLocal/>, as the XML parser used
does not support this.

Wire Between Objects

Chain Connections
Frequently, you will need to chain together similar terminals on a block diagram. Common examples
are error wires and reference wires. Error wires are automatically connected. References are not. It is
highly recommended that wire chaining be done at the beginning of your wiring sequence. The
normalText of connected to name contains a pattern to match using the LabVIEW Match Pattern
to find source terminals. Similarly, connector name contains the pattern for the sink terminals. The
otherXML is attached to connector name and is of the following syntax.

<ChainConnections>
<DiagramID>diagram ID</DiagramID>
<Internal>T/F</Internal>
<ConnectFirst>
<Connect>T/F</Connect>
 <FinalLabel>final terminal label</FinalLabel>
<UseIndex>T/F</UseIndex>
<ConnPaneIndex>positive integer connector pane index</ConnPaneIndex>
<Area>region to connect to connector pane</Area>
<ConnectionType>how connection is used</ConnectionType>
</ConnectFirst>
<ConnectLast>
<Connect>T/F</Connect>
<FinalLabel>final terminal label</FinalLabel>
<UseIndex>T/F</UseIndex>
<ConnPaneIndex>positive integer connector pane index</ConnPaneIndex>
<Area>region to connect to connector pane</Area>
<ConnectionType>how connection is used</ConnectionType>
</ConnectLast>
</ChainConnections>

• DiagramID — a text string specifying the diagram to search in. This is optional. The default
value is "mxwRoot", indicating the root diagram will be searched.
• Internal — a boolean determining if the last template source is connected to the first template
sink (assumed to be the last chain in an internal subdiagram).
• ConnectFirst — an optional set of data determining if and how the first terminal of the series
is connected to the connector pane. If not included, the first terminal is not connected. All of
the fields are never used.
• Connect — a boolean determining whether any of the rest of the data is used. If
FALSE, the terminal is not connected to the connector pane, so the rest of the data is
not necessary.
• FinalLabel — optional label for the terminal connected to the connector pane. Defaults
to the current terminal name if not present.
• UseIndex — a boolean which determines how the position on the connector pane is
determined. If TRUE, ConnPaneIndex specified the index on the connector pane. If
FALSE, the general area on the connector pane desired is specified with Area.
• ConnPaneIndex — and integer specifying which index on the connector pane to
connect to. Only needed if both Connect and UseIndex are TRUE.
• Area — a string used to specify a region of the connector pane to connect to. The
codegen engine will determine the exact connector pane index based on this guidance.
Valid values are (not case sensitive):
• TopLeft
• Top
• TopRight
• Right
• BottomRight
• Bottom
• BottomLeft
• Left
• ConnectionType — determines how the connection will be used. These values
correspond to the pop-up on the connector pane terminal. Valid values are (not case
sensitive):
• Required
• Recommended
• Optional
• DynamicDispatch
 • ConnectLast — an optional set of values which determine if and how the last terminal of the
series is connected to the connector pane. If not present, the connection is not made. Values
are the same as ConnectFirst

Connect to Dynamic Build/Index Array

This option allows the user to dynamically build a build array or index array primitive as wires are
connected to it. The connection is specified to the terminal the build/index array is connected to. The
terminal is specified as normal (including any of the encodings in this section). The build/index array
is specified in the otherXML.

<ConnectToTerminalArray>
<Direction>Source/Sink</Direction>
<MakeSpace>T/F</MakeSpace>
<MakeWireSpace>
<SpacePerWire>XPixels/Wire(7)</SpacePerWire>
</MakeWireSpace>
<ConnectToLocation>Top/Terminal0</ConnectToLocation>
</ConnectToTerminalArray>

• Direction — Whether the connection is a sink (build array) or source (index array). Valid
values are "Sink" and "Source". Capitalization is unimportant.
• MakeSpace — An optional boolean indicating whether or not to create space when creating the
original build/index array primitive. Valid values are "T", true, and "F", false. Default is T.
• MakeWireSpace — An optional set of parameters to set how much, if any, space is created on
the wiring side of the dynamic array item. Valid tags, and their meanings, are as follows:
• SpacePerWire — The amount of space in the X direction to create for every input wire
of the object. Units are pixels. Default value is 7 pixels. Since this is specified on a per
wire basis, the values in the first wire specified will be used.
• ConnectToLocation — Optional value to set the reference position on the new object. This
determines where, in the Y axis, the terminal will be wired. Valid options are "Top" and
"Terminal0". "Top" will grow the object down from the first growable terminal. "Terminal0" will
center the input terminal on the wire the object is connected to.

Connect to Dynamic Interleave/Decimate Array

This option allows the user to dynamically build an interleave or decimate array node as wires are
connected to it. The connection is specified to the terminal the node is connected to. The terminal is
specified as normal (including any of the encodings in this section). The node is specified in the
otherXML.

<ConnectToDecimateArray>
<Direction>Source/Sink</Direction>
<MakeSpace>T/F</MakeSpace>
<MakeWireSpace>
<SpacePerWire>XPixels/Wire(7)</SpacePerWire>
</MakeWireSpace>
<ConnectToLocation>Top/Terminal0</ConnectToLocation>
</ConnectToDecimateArray>

• Direction — Whether the connection is an interleave or decimate array node. Valid values are
 • Sink — interleave array node
• Source — decimate array node
Capitalization is unimportant.
• MakeSpace — An optional boolean indicating whether or not to create space when creating
the original build/index array primitive. Valid values are "T", true, and "F", false. Default is T.
• MakeWireSpace — An optional set of parameters to set how much, if any, space is created on
the wiring side of the dynamic array item. Valid tags, and their meanings, are as follows:
• SpacePerWire — The amount of space in the X direction to create for every input wire of the
object. Units are pixels. Default value is 7 pixels. Since this is specified on a per wire basis,
the values in the first wire specified will be used.
• ConnectToLocation — Optional value to set the reference position on the new object. This
determines where, in the Y axis, the terminal will be wired. Valid options are "Top" and
"Terminal0". "Top" will grow the object down from the first growable terminal. "Terminal0" will
center the input terminal on the wire the object is connected to.

Wire Routing
The normal wire routing algorithm used by the codegen engine is an AI based, depth-first algorithm.
It can be globally changed using one of the options. However, the global setting can be overridden on
an individual wire/chaining session by using this option. In the future, the parameters for the AI
trace will be placed here, as well.

<WireRouting>
<Algorithm>None/LV/AI</Algorithm>
</WireRouting>

• Algorithm — The algorithm used to trace a wire path.

• None — Wire is directly connected with no tracing. This will produce a straight line or
"L" shaped wire which may or may not go under objects and structures. It should not
be used unless the designer knows that no objects will be crossed by the wire.
• LV — The LabVIEW auto wire routing routine is used. Note that on more complex
diagrams, this frequently times out, resulting in the "None" option.
• AI — This is the default option. Wires are traced using a depth-first Djikstra's
algorithm.

Wire to a Terminal on a Node

Normally, wires are connected between control terminals on the block diagram. To connect to a
terminal on a node, specify the node as the object name and use the following syntax for the
otherXML:

Connect by Index

<ConnectToNode>
<TerminalIndex>index</TerminalIndex>
</ConnectToNode>

index is the index of the terminal on the node to connect to.

Connect by Name

<ConnectToNode>
<TerminalName>name</TerminalName>
</ConnectToNode>

name is the name of the terminal on the node to connect to. If there are several terminals with the
same name (e.g. a property node with the same property used in both read and write modes), the first
terminal with the specified name will be returned.

Future versions of this command may support creating a terminal on a node, such as a loop or case
selector.

Connect to Terminal by Terminal ID

This option is used to connect to a terminal that has been tagged by a unique ID string. ID strings
are assigned to terminals when the template is dropped using the TerminalID option. The
normalTextString is ignored when this option is used.

<ConnectID>
<ID>unique ID of the terminal to connect to</ID>
</ConnectID>

Wire to Terminal by Template ID

This option is used to connect to a terminal on a template that has been tagged by a unique ID
string. ID strings are assigned to templates when the template is dropped using the ID option. The
terminal on the template is specified in the normalTextString.

<ConnectTemplateID>
<ID>unique ID of the template to connect to</ID>
</ConnectTemplateID>

Set Value of Object and Its Overloading

Set value is used to set the value of objects and to select case statements in templates. However,
there are several special object names which trigger different behavior. XML encoding on the object
name is also used to signal special behaviors on the object.

Name Overloading
mxwCodeGenRecipe

This parameter name signals that there is a single subVI on the block diagram of the template being
used that should have code generation to create it. The value is of type
mxwCodeGenCompleteRecipe.ctl. The template containing the subVI will be dropped, then the subVI
generated from the recipe. Code generation proceeds then from that point. This is most often used
when generating Express VIs, but can be used in any circumstance. If there is more than one subVI
on the block diagram of the template, an error is generated and nothing is done. Use
mxwCodeGenRecipeN to specify a specific VI if multiple VIs are present.

mxwCodeGenRecipeN

This parameter name signals that there is a subVI on the block diagram of the template being used
that should have code generation to create it. The value is of type
mxwScript_SetParm_CodeGenRecipeN.ctl. The template containing the subVI will be dropped, then
the subVI generated from the recipe. Code generation proceeds then from that point. This is most
often used when generating Express VIs, but can be used in any circumstance. Note that this
command changes the connector pane of the subVI and relinks it. This causes the subVI ordering to
change, so care must be used if index mode is used to specify the subVIs.

mxwIsInstance

This parameter name is used to strip the IsInstance? value of an Express VI and make it a normal
subVI. The value is of type Boolean. The value must be FALSE for the strip to occur. A TRUE value
results in a no-op. If multiple subVIs exist, the first found is modified. Use mxwIsInstanceN to
specify a specific subVI if multiple subVIs are present.

mxwIsInstanceN

This parameter name is used to strip the IsInstance? value of an Express VI and make it a normal
subVI when multiple subVIs exist on the template. The value is of type
mxwScript_SetParm_IsInstanceN.ctl. The isInstance? value in the input data must be FALSE for the
strip to occur. A TRUE value results in a no-op. The subVI specified in the control is used for this
operation. This must be used after mxwCodeGenRecipeN if the subVI is specified by name, since
this command changes the name. If using index mode and mxwCodeGenRecipeN, be aware that the
ordering will change due to the connector pane change and subsequent relink of the subVI.

mxwSetLoneXNodeState

This parameter name sets the internal state of an XNode. It assumes there is a single XNode object
on the template. If there is more than one, the first one found is set. The data type is the state
information for the XNode [[U16 major,U16 minor,U16 fix,U16 build] version,variant
state].mxwSetNamedXNodeStateThis parameter name is used likemxwSetLoneXNodeState, but finds
a named XNode and sets its value. The input data type is a cluster with a string and and the XNode
state information, representing the label of the XNode and its state data [string label, [[U16
major,U16 minor,U16 fix,U16 build] version,variant state]].

Object Name XML Encoding

Run a VI on an Object

It is sometimes necessary to run a VI on an object during code generation to do something

nonstandard. An example would be formatting a graph. The name of the object is given in the legacy
text. The value of the object is a list of name/value pairs (array of clusters — string and variant)
which are used to set the front panel controls of the VI (Set Control Value [Variant])before running it
(Run VI). The otherXML is as follows:
<RunVIOnObject>
<VIPath>path</VIPath>
<Synch>T/F</Synch>
<Context>context to run in</Context>
<ModifyStack>T/F</ModifyStack>
</RunVIOnObject>

• VIPath — specifies the full path to the VI to run on the object. This VI must have a front panel
control called object ref of type GObj reference in addition to the controls in the parameter
list. If the user wishes to query for errors, there must also be a standard error cluster output
called error out. To query for errors is done automatically if Synch is TRUE.
• Synch — a boolean. If TRUE, the VI is called synchronously (Wait until done is set to TRUE).
This is an optional input. It defaults to TRUE.
• Context — an optional parameter, valid only for LabVIEW 8.0+, indicating what LabVIEW
context to run the VI in. Valid values are "VI" and "MyComputer". "VI" is the default, indicating
the VI will will run in the same context as the VI being generated. If "MyComputer" is selected,
the VI will run under the My Computer context.
• ModifyStack — a boolean. If TRUE, the ability to modify the command stack is added to the
called VI. The called VI must have an input named commandStackIn and an output named
commandStackOut, both arrays with element type mxwScript_Command.ctl. At the very least,
commandStackIn and commandStackOut must be connected to avoid corrupting the
command stack. Care must be exercised when using this option to avoid corrupting
succeeding elements of the command stack, which contain many hard-coded indices.

Appendix III - Wiring Algorithms

Routing

Algorithm
The wire routing algorithm is a depth-first Dijkstra implementation. See below for weighting factors
and line construction.

1. Initialize sorted facet and wire tables. All objects on the block diagram are broken down into
facets and placed into top, bottom, left, and right facing bins. These bins are sorted in
placement order to allow binary searching for possible issues. Wires are created as a segment,
which can be crossed but not overlapped with a wire control point, and end caps, whose width
is determined by the wire width. The end caps are added to the facet cache. Structures are
treated like rectangular wires so their boundaries can be crossed.
2. Create line paths composed of a single straight wire or two "L" shaped wires from the source to
the sink.
3. Score these paths (see below)
4. Initialize priority queue and add paths to it.
5. Initialize done list.
6. Loop on the following:
1. Extract maximum from priority queue.
2. Add item to the done list.
3. Update best line cache.
 4. If item meets end criterion, exit with success.
5. Construct new wires.
6. Add new wires to priority queue if not in done list.
7. Exit with failure if over time limit or priority queue is empty.
7. Output wire from best line cache.

Weighting Factors
This heuristic algorithm weights a path based on several items. The sum of these weights gives a
score for that particular path. Scoring is as follows. Note that items are negative so that larger
numbers give a worse score.

• Cross an object boundary: -2,000/item

• Overlap/parallel a wire/diagram boundary: -2,000
• Wire kink: -5/kink
• Cross a wire/diagram boundary: -5/crossing
• Wire length: -5/pixel

The wire is good if there are no object boundary crossings or wire/diagram boundary overlays.

Construction of New Wires

New wire paths are constructed from failed attempts by routing wires around the blocking objects.
Four new paths are generated for every old one. A failed wire is traversed to find the first wire
segment which violates a routing rule. Routing rule violations generate a facet which must be routed
around. This is done so as to minimize bends in the wire. Consider the following graphic.

P0 is the start point of the line segment. P1 is the end point. Points Q0 -- Q6 are calculated from the
locations of P0 and P1. New wire segments are created by using Qn. If P0 or P1 is an endpoint, it is
reused. If not, the new wires are routed to the next wire join (e.g. on the top blue line, P1 is replaced
by Q2)

Graphic Example
In this example, for simplicity, only the two bottom generated lines are shown. The top ones would
also be generated, but not used, because they are longer and would cross more objects.
First Lines - Draw two "L" lines. Pick the one which intersects the fewest objects.

Second Lines - Add bend in wire to miss first object. Check local bend and bend back to source. Use
line which intersects the fewest objects, then the one with the fewest bends.
Third Lines - Add bend in wire to miss second object. Check both local bend and modifying existing
bend and pick the one which intersects the fewest objects, then the one with the fewest bends.

Control Point Diagram Placement

After a wire is routed, it still must be actually created. Current LabVIEW technology (February 2007)
does not allow programmatically creating a wire with bends which passes through multiple diagrams.
To work around this issue, a bundle object is placed at each bend location and a simple, straight wire
is connected to each bundle, then the bundles are deleted, leaving the completed wire behind.
However, the diagram which contains the bundle must be determined before creating the bundle.
This algorithm accomplishes this task, ensuring that data flow is maintained and wires are not
routed through structures they should not be routed through.

1. Construct a diagram path. This is a list of what diagrams the wire will traverse from the
source to the sink terminal. These diagrams will be used to find what diagrams to drop control
points into. It is constructed as follows:
1. Find the diagram path from the source to the root diagram.
2. Find the diagram path from the sink to the root diagram.
3. Find the location where both paths become the same. The first shared location on the
source path is the inflection index (the diagram path stops going toward the root
diagram and starts back up again toward the sink diagram).
4. Discard the elements in the sink path after the inflection element.
5. Reverse the sink path.
6. Resize the source path to the current sink path length plus the source path length up
to, but not including, the inflection element.
7. Overwrite the source path values with the sink path values starting at the inflection
point.
 2. Initialize the maximum diagram index found to 0. The maximum diagram index (MDI) is the
highest location in the diagram path of a diagram which contains the last control point
dropped.
3. For each control point, do the following to determine which diagram to place it in
1. If the inflection point is the last element of the diagram path, skip the next two steps.
2. Search from the end to the element just before the inflection point for a diagram which
contains the point or the MDI, whichever comes first.
3. If found, update the MDI and continue with the next point. If not found, continue.
4. Search from the MDI to the inflection point for a diagram which contains the point.
5. If found, update the MDI and continue with the next point. If not found, continue.
6. Return the MDI diagram.

The following image will be used for an example for the steps of the algorithm. A wire is routed from
Numeric in diagram A to Numeric 2 in diagram G. Control points are dropped in diagrams C and E.

1. The maximum index is initialized to 0.

2. The diagram path from the source to the root is ABCE.
3. The diagram path from the sink to the root is GFE.
4. The source-to-sink diagram path is ABCEFG with inflection point at index 3 (E).
5. The search for the diagram containing the first control point is GFABC. It is found in C. The
MDI is set to 2.
6. The search for the diagram containing the second control point is GFCE (second search starts
at index 2). It is found at index 3 (E).
Appendix IV - Debugging Codegen Problems

Basic Debugging Techniques

The codegen engine has an internal error stack which keeps track of all errors which occur during
generation. When generation finishes, if the error dialog is enabled, it will display all these errors. By
clicking the Export button on the error dialog, you will get a file containing the information needed to
correct most errors. The file is a tab-separated text file with the following format:

Column 1 Column 2 Column 3 Column 4

LabVIEW Error LabVIEW Error Text Codegen Engine Engine Command
Code String Command Data

• LabVIEW Error Code - standard LabVIEW error code

• LabVIEW Error Text String - text from the source field of the LabVIEW error
• Codegen Engine Command - internal command which produced the error.
• Engine Command Data - XML flattened string of the data to the command which produced the
error.

Common Errors

Error 7 in openTemplate
This is usually caused by a misspelled template name or incorrect path in the LVW file.

Error 1055 in connectWire

This is usually caused by one of two issues:

1. One of the terminals being wired has a misspelled name.

2. There is more than one item with the same name on the diagram, and the first one found
cannot be coerced to a terminal.

Correct the misspelled name or rename one of the items. Alternately, a more complete "path" to the
item can be used.