Skip to main content

Building a Subflow

A Subflow is edited exactly like a Flow — the same canvas, the same Node Selector, the same concepts. What differs is how it starts, how it ends, and that it always runs on behalf of a caller.

Create a Subflow​

Subflows are created from the calling Flow, not from a library of their own:

  1. In the main Flow, add a Subflow Node.
  2. On that Node, create a new Subflow or select an existing one.
  3. Press the pencil button to open it here in the Subflow Editor.

Entry point​

A Subflow begins at its Subflow Start Node, which replaces the Start Node a Flow uses. There is one entry point, and it fires when the calling Subflow Node is reached.

Outputs​

Every Subflow declares how many outputs it has, set in the upper section of the Subflow Editor. That number decides how many output connectors appear on the Subflow Node in the calling Flow.

Inside the Subflow, a Subflow Output Node decides which of those outputs the caller continues from. This is how a Subflow reports what happened, not just that it finished:

  • A "pick part" Subflow might have output 1 for a successful pick and output 2 for an empty bin, letting the calling Flow branch without inspecting any Variable.
  • A Subflow with a single output is the common case, and needs no Subflow Output Node at all.
note

If a Subflow ends without reaching a Subflow Output Node, Output 1 is triggered by default.

The caller waits​

The Subflow Node does not trigger its output until the Subflow has finished. From the calling Flow's point of view, a Subflow is one blocking step — which is exactly what makes it readable as a single block.

No concurrency inside​

A Flow can execute branches in parallel. A Subflow cannot: there is no concurrency inside a Subflow, and branches do not run at the same time.

If you need parallel execution, it has to live in the main Flow. Keep the parallel structure outside and call Subflows from each branch, rather than trying to fan out inside one.

Passing data in and out​

A Subflow has no parameter list. Data crosses the boundary through Variables, which are global to the Robot and therefore visible to both the caller and the Subflow.

The consequence is worth being deliberate about: a Subflow used from several places writes to the same Variables every time. Two patterns keep that manageable:

  • Agree on named slots. Give the Subflow dedicated input and output Variables — pickSubflow_targetPose, pickSubflow_result — and have the caller set the inputs immediately before the Subflow Node.
  • Tag them. Put the Subflow's Variables under a shared tag so it is obvious which Variables belong to which Subflow.
warning

Because Variables are global, a Subflow called from two branches of a parallel structure in the main Flow will have both callers writing the same Variables. Either serialize the calls, or give each branch its own set of Variables.