When working with complex hierarchical models in FlexSim, referencing objects deep inside a structure can quickly become difficult to manage. When not using multiple centre port connections (which gets messy) users often rely on manually created labels and pointers, but that in turn can introduce extra work and inconsistency—especially when deciding whether a label should reference a single object or an array.
This post describes a small set of user commands, packaged as an auto-installing user library, that automatically builds and maintains hierarchical object references based on each object’s role.
The goal is simple: allow users to reference objects using intuitive chains like:
current.printerCell.rewinder.turret
without manually creating or maintaining those labels.
What this does
This system automatically:
creates label pointers based on object roles (functionname)
builds those references up the hierarchy
optionally propagates system-level references downward
handles single vs multiple objects automatically
rebuilds everything on reset so it stays consistent
How it is set up
The functionality is delivered as:
an auto-installing user library containing the commands
a template container that includes:
a reset trigger that calls:
containerReset(current)
predefined labels:
functionname
systemContainer
Users can drop this container into their model and begin assigning functionname labels to objects. The rest is handled automatically at reset.
Core concept
Each object declares its role using a label such as:
functionname = "rewinder"
From this, the system builds references dynamically using only the tree hierarchy.
A key point is that this is not limited to containers. Any object, including standard FlexSim fixed resources such as processors, sources, queues, and sinks, can and should also be given a functionname when you want it to participate in the reference structure.
That means this system maps not just structure, but function.
How it works
1. Reset seeds the reference map
On reset, each relevant container calls:
containerReset(current)
This starts the process of rebuilding all references from the current tree structure.
2. Objects register themselves upward
If an object has a non-empty functionname, it adds a reference to itself on the next relevant level above it.
So if a rewinder contains a turret, the rewinder can gain:
rewinder.turret
3. Non-functional levels are skipped
If an intermediate object has no functionname, the logic recurses through it rather than making it part of the reference chain.
That means purely structural levels can exist in the tree without cluttering the reference path.
So a structure like:
printerCell └─ layoutContainer └─ rewinder └─ turret
can still produce:
printerCell.rewinder.turret
even though layoutContainer exists physically in the tree.
4. System containers propagate references downward
If an object has:
systemContainer = true
then its own functionname is pushed down to all contained objects.
So if printerCell is marked as a system container, nested objects can directly reference:
current.printerCell
This makes it easy for deeply nested components to find the root system they belong to.
5. Repeated roles become arrays automatically
If a label already points to one object and a second different object needs to be stored under the same role name, the value is automatically converted into an array.
So if one rewinder contains multiple turrets, then:
rewinder.turret
becomes an array of turret pointers instead of a single pointer.
Users do not need to decide this in advance.
Works for both machines and factories
A useful feature of this approach is that a “system” does not have to mean a single tightly integrated machine.
A system can be:
one complex interconnected machine acting as a whole
one cell within a larger process
a factory made up of linked but physically distinct cells
As long as those objects live under a meaningful tree structure, the same logic works. A printer cell can be used as a standalone system, then placed inside a larger factory container and reset again to gain one more level of functional context.
That makes the approach scalable from machine-level modeling to line-level or factory-level organization.
Example model
I’m also including an example printer cell model where the labels are not pre-populated.
You can:
open the model
press Reset
inspect the created labels on the objects
Then you can place that same printer cell inside a factory container, reset again, and inspect the results after the hierarchy changes.
That gives a simple way to see the library working in both a standalone and larger-system context.
Implementation details
Below are the three user commands that make this work.
1. containerReset(<container>)
Purpose
This is the reset entry point.
It does three things:
registers the current object upward on its parent if it has a functionname
if the current object is a systemContainer, propagates a reference to itself downward through everything beneath it
calls the recursive function that builds the rest of the pointer map below it
So this command seeds both the upward and downward context, then delegates the deeper hierarchy building.
2. assertReference(<objectToAddReference>, <referenceName>, <referenceObject>)
Purpose
This utility adds a reference safely and automatically handles whether the label should be:
a single pointer
or an array of pointers
If the label is empty, it stores a single object pointer.
If it already points to a different object, it converts the value into an array.
If it is already an array, it adds the new object only if it is not already present.
This is what removes the need for users to decide ahead of time whether a role is unique or repeated.
3. assertallobjectpointers(<involved>, <container>)
Purpose
This is the recursive traversal function.
It walks downward through the tree under container and looks for objects with a non-empty functionname.
When it finds one, it adds a reference on current using that object’s function name.
When it encounters an object with no functionname, it does not stop. Instead, it recurses further downward through that object’s children.
This is the key to skipping non-functional levels in the tree.
In effect, this command says:
Starting from the current functional object, keep searching downward until you find the next lower functional objects, then create references to them.
That is what allows the reference chain to reflect logical structure rather than every structural level.
Why this is useful
This approach gives you:
cleaner, more readable code
no manual label maintenance
automatic support for one-or-many references
a functional map of the model rather than just a physical tree
better reuse of machines, cells, and factory-level groupings
Instead of writing search logic, you can work with meaningful chains such as:
current.printerCell.rewinder.turret
Best practices
Use role-based names
Set functionname based on what the object does, not its instance name.
Good examples:
printerCell rewinder turret infeedQueue
Less useful examples:
object1 machineA testNode
Be consistent across models
If you reuse systems or templates, keep the same functionname values so code remains portable.
Add functionname only where it adds value
Not every object needs one. Use it on objects you want to reference directly in logic.
Include fixed resources too
Do not treat this as a container-only feature. Fixed resources such as processors, sources, queues, and sinks can also participate and often should as these will be the objects your want to setup, load or listen to.
Use systemContainer deliberately
Mark the objects that represent meaningful system roots. That may be a machine, a cell, a line, or a factory-level grouping.
Expect arrays when a role repeats
If multiple objects with the same function appear under the same functional parent, that reference will become an array.
Keep the hierarchy meaningful
Since this works purely from tree structure, the physical organization of the tree should support the logical organization of the model.
Use it to remove search logic
If you find yourself repeatedly searching for the same kind of object, that is often a sign that it should have a functionname.
Summary
This approach turns the model hierarchy into a self-maintaining functional reference map.
By assigning functionname labels to meaningful objects and rebuilding relationships during reset with containerReset(current), the model can automatically expose useful object references without manual wiring.
That works whether the model represents a single complex machine or a larger factory made up of linked but physically distinct cells.
The result is cleaner code, easier maintenance, and a more consistent way to navigate hierarchical models.
View full article
