On the Envision page, the Asset Manager opens as a dialog: with the Asset Manager icon in the design menu, below the Color Library icon, or with the Asset Manager entry under Configuration in the same menu. Both keep the page that is open behind the dialog. The Asset Manager also opens as a full page from the side menu of the configuration area. It is the entry point for asset and type management: the UDT Definitions button in its toolbar opens the UDT Manager.
The Asset Manager configuration page defines the plant hierarchy as a tree of nodes, for example Site, Line A, and Pumps. The full path of a node, written as Site/Line A/Pumps, is stored in the Asset field of the variables, alarms, and events attached to it. Every viewer and configuration table keeps filtering on the Asset field as before; the tree adds structure on top of it without changing how the field works.
UDT instances are attached to a node through their Asset field, and the tree shows the number of attached instances per node. Manually created variables, alarms, and events can carry a node path in their Asset field as well, or keep using free text.
A node that has UDT instances attached shows an expander. The instances are listed under it and can be selected to show their resolved detail, dragged onto another node to reattach them, and dragged onto a page to place a symbol for them. The UDT Definitions button in the toolbar opens the UDT Manager in the same window. When the AI Assistant is enabled, the AI button docks the assistant to the right so both stay visible side by side; press it again or close the assistant to leave this view. The button is available in the toolbar of the Asset Manager page and in the header of the Asset Manager dialog on the Envision page, where it also switches the dialog to full size.
Working with the Tree
The left side of the page shows the tree. Select a node to see its details on the right: the full path, description, the number of child nodes, and the attached UDT instances with their definitions and devices.
The Search box in the toolbar filters the tree. Enter a part of a node name or description, or of the name, definition, or device of an attached UDT instance. The tree keeps the matching rows together with their parent nodes, so every result stays visible in its full path. A node with matching UDT instances is expanded and lists only those instances. When nothing matches, the tree reports No results. Emptying the box shows the complete tree again.
Create a node with the Add node button, edit the selected node with the Edit node button, and remove it with the Delete node button. A node that still has child nodes or attached UDT instances is kept until they are moved, deleted, or detached.
Several items are selected at once to remove them in one action. Hold Ctrl, or Command, and click a row to add it to or remove it from the selection. Hold Shift and click a row to select the range between the previously clicked row and the clicked row. Nodes and UDT instances are selected together in the same selection. With more than one item selected, the button reads Delete selected and shows the number of items, and the panel on the right reports how many nodes and instances are selected. The Edit node button stays available only while a single node is selected.
When the selection is deleted, attached UDT instances are removed before their nodes, and child nodes are removed before their parents, so a selected branch is cleared in the correct order. A node that still holds a child node or a UDT instance that is not part of the selection is kept, and the reason is reported for each item that is not removed. Each deletion is replicated to the standby server and recorded in the Audit Trail.
| Setting | Description | Example |
|---|---|---|
| Name | Node name, one path segment. | Line A |
| Parent | The node this node is placed under. Root places it at the top level. | Site |
| Description | Free text description. | Packaging line |
| Page | The page this node opens when it is clicked in a Navigator object, chosen from the existing pages. No page means the node only expands in the Navigator, and a leaf node opens the faceplate of its first attached UDT instance instead. A page rename follows the link and a page delete clears it. A copied node does not carry the link of its source. | Line A Overview |
No rows match the filter.
Copying a Node
The Copy node button copies the selected node, its child nodes, and every UDT instance attached to them onto another set of devices. It is available while a single node is selected. Use it to repeat a plant section that already exists, for example a second identical skid on its own PLC.
The dialog shows the result as a tree: the nodes that will be created, with the instances that will be attached to each of them. It is redrawn on every change, so what is on screen is what the copy will create. Anything that would block the copy is reported on the row that causes it, and the Copy button stays unavailable until the tree is clear.
The copied instances are created again from their UDT type on the target devices. Parameter values, display order, and the tree structure are carried over, with the Device parameters set to the target devices of the copy. Field overrides made on the source instances stay with the source, and symbols already placed on a page are not copied, so the copied instances start from the type and are placed on a page separately. The copied branch is staged: the new instances show the Not materialized status, and their variables, alarms, and events are created when they are pushed from the UDT Manager.
The devices of a UDT instance are parameter values, so the copy sets them like any other parameter. Every instance row in the result tree lists the parameters that instance will be created with, one per line, filled in from the source instance. The rows are expanded by default; Collapse All above the result folds them, and the expander in front of a row opens or closes that row on its own.
Edit only the parameters that must change. Each row is edited on its own, so instances can be sent to different devices within one copy. Leaving a parameter untouched copies the value from the source, which means a copy lands on the same devices as the original until you say otherwise.
A device name is typed rather than selected from a list, because it can be composed from other parameters, for example PLC{Line}. Any device can be used, whatever protocol it uses, because a copied instance is created again from the protocol group that matches its new device. A name that does not resolve to an existing device is reported on the row, and the Copy button stays unavailable until it is corrected.
| Setting | Description | Example |
|---|---|---|
| Parent | The node the copy is placed under. Root places it at the top level. The branch being copied cannot be selected. | Site |
| Export plan | Writes the result to a JSON file: one entry per node and instance, with its name, and the parameter values for an instance. Available once the result tree is shown. | |
| Import plan | Reads names and parameter values from an exported plan file and fills them into the result. Rows the file does not mention keep their current values. | |
| Expand All / Collapse All | Opens or folds the parameter rows of every instance in the result. The rows are expanded when the dialog opens. | |
| Result | The tree the copy will create. Each node and instance row takes a name, and each instance row lists its own parameters, devices included. | Line2 / Pumps / Pump1 |
No rows match the filter.
Each instance row in the result tree takes the name the instance has within its asset node, filled in from the source instance. The full name is composed from the path of the copied branch and that name, so copying Line1 to Line2 produces instances that are still called Pump1 and Pump2, with the full names WTP.Line2.Pump1 and WTP.Line2.Pump2. Nothing has to be renamed for the names to be unique.
Edit a name to change it. Two instances on the same node need different names.
A copy keeps the parameter values of the source, including its devices, and the variables of a UDT instance take their names from the name within the node. Copying a branch onto the same devices therefore produces the variable names that are already in use, and the affected rows report this. Set the Device parameter of the copied instances to the devices the copy belongs on, which is the normal case for a second line or skid.
Export plan and Import plan rename a whole branch in one step. Select Export plan to write the result to a JSON file, with one entry per node and instance. Open the file in a text editor, set the names and the parameter values the copy should use, and select Import plan to read them back into the result tree. The tree is validated again after the import.
A row the file does not mention keeps the value it already has, so a plan can carry only the rows that change. Entries that do not match a row of the branch being copied are reported above the tree and skipped, which is what happens when a plan exported from one node is imported into another.
Select Copy to create the branch. The copy is applied as a whole: when one instance cannot be created, everything already created in that run is removed again, so a partly copied branch is never left behind. The result is selected in the tree when the copy is finished. Each created node and instance is replicated to the standby server and recorded in the Audit Trail.
Arranging the Tree
Nodes and the UDT instances attached to them are arranged by dragging them in the tree. The position of the pointer on the row decides what happens. Dropping on the middle of a row places the dragged item inside that row, and the row is outlined. Dropping on the top or bottom edge of a row places the dragged item before or after that row, and an insertion line shows where it will be placed.
Placing an item before or after another updates the Sort order of every node or instance at that level, so the order is kept the next time the tree is opened. Reordering does not change the Synced or Outdated state of a UDT instance and does not rewrite asset paths. The warning about affected rows is shown only when a node is moved to a different parent, because only then do the node paths change.
- Drop a node on another node to place it under that node.
- Drop a node on the empty area below the tree to place it at the top level.
- Drop a node on the top or bottom edge of another node to place it before or after that node. When that node has a different parent, the dragged node is moved and positioned in one action.
- Drop a UDT instance on a node to attach it to that node.
- Drop a UDT instance on the top or bottom half of another instance to place it before or after that instance. When the instance is dragged from another node, it is attached and positioned in one action.
The order of nodes and of the instances under them is set by dragging alone. There is no Sort order field in the node dialog: the position a row is dropped in is the position that is stored, and the whole group of siblings is renumbered on each drop. The order is display only. It never changes an asset path and never changes whether an instance is Synced or Outdated.
Renaming and Moving Nodes
Renaming a node or moving it to another parent changes the path of the node and of every node below it. The Asset field of every variable, alarm, event, schedule, and Python script carrying an affected path is updated in the same operation, so filters and attached rows stay consistent. The Assets setting of every page naming an affected path is updated as well, so a Navigator keeps counting the right alarms for that page. The Page link of the node itself is a page name, not a path, and is unaffected by the rename. The edit dialog shows how many rows carry an affected path before the change is saved.
The update is replicated to the standby server and recorded in the Audit Trail.
Renaming or moving a node also updates the full name of every UDT instance attached at or below it, because that name is composed from the asset path. The affected instances show the Outdated status, and the symbols placed for them follow on their next push. Variables, alarms and events keep their names.
Assets in the Viewers
Because node paths live in the existing Asset field, asset filtering works in the Alarm Viewer, the Event Viewer, and every configuration table without additional configuration. Filtering on Site/Line A matches that node, and searching on a path prefix finds the rows of an entire subtree.
Alarm messages of UDT instances can include the {Asset} token, so an alarm raised by a pump on Line A reads its full location, for example Site/Line A/Pumps: pump speed high.