Subsystem

This function block acts as a self-contained workflow container. Use it to group related processing steps into a separate, editable workspace so complex scenarios stay organized and easier to manage.

πŸ“₯ Inputs

No default inputs This block does not declare inputs by itself. Inputs can be created by adding input sockets inside the subsystem workspace and exposing them at the block boundary.

πŸ“€ Outputs

No default outputs This block does not declare outputs by itself. Outputs are defined by child blocks placed inside the subsystem and exposed as the subsystem outputs.

πŸ•ΉοΈ Controls

Open Subsystem Editor Open the subsystem workspace to add or edit the contained workflow. (Typically available by double‑clicking the block or via the block context menu.)

Expose Input Create an input socket inside the subsystem and expose it on the block boundary so the parent flow can feed data in.

Expose Output Create an output socket inside the subsystem and expose it on the block boundary to send results back to the main flow.

Run / Debug Inside Run and debug the contained workflow independently from the main scenario to validate its behavior.

🎯 Key Features

  • Encapsulation: Group preprocessing, detection, tracking, and export steps into a single reusable unit.

  • Local workspace: The subsystem has its own editable canvas so you can design complex behavior without cluttering the main flow.

  • Clear boundaries: Expose only the inputs and outputs you need, keeping the main graph simple.

  • Isolated testing: Open and run the subsystem workspace to debug or validate sub-flows independently.

  • Reusability: Build a tested subsystem once, then reuse it across multiple projects.

βš™οΈ How it runs

  • When the scenario executes, the subsystem runs its internal workflow.

  • Data flows into the subsystem through the input sockets you exposed inside it.

  • Child blocks inside the subsystem compute their results in sequence.

  • Outputs that you exposed inside the subsystem are collected and returned to the parent flow as the block outputs.

  • If a child block inside the subsystem reports an error or an invalid state, the subsystem will reflect that status so you can locate and fix the issue inside the workspace.

πŸ“ Usage Guidelines

  1. Add a Subsystem block to your main flow to hold a complex sequence (acquisition β†’ processing β†’ export).

  2. Open the subsystem workspace (Open Subsystem Editor) and add the needed blocks.

  3. Inside the subsystem, expose only those inputs and outputs required by the parent flow.

  4. Test the subsystem independently using the internal run/debug controls before integrating it into the main scenario.

  5. Reuse and duplicate subsystems for similar tasks to speed up development.

πŸ’‘ Tips and Tricks

  • Group a complete camera pipeline inside a subsystem: use Camera USB or Camera IP (ONVIF) β†’ preprocessing blocks like Image Resize / Blur β†’ detectors such as Object Detection or Find Object β†’ visualization with Draw Detections β†’ storage with Image Logger or Image Write.

  • For tracking flows, place Object Detection (or Object Detection - Custom) and Object_Detection_Tracker inside a single subsystem so tracking logic and post-processing stay together.

  • Encapsulate heavy AI steps like Super Resolution, Depth Estimation (DepthAny. V2), or Background Removal (RMBG-1.4) inside subsystems to make it easy to enable/disable or replace models without disturbing the main flow.

  • Use subsystems to implement multi-stage analysis: e.g., ROI selection with Image ROI Select β†’ shape analysis with Find Contour / Measure Position Distance β†’ result formatting with Data to JSON.

  • When building intersection or traffic analytics, keep detection and tracking in one subsystem and aggregation/export (for example the Traffic Intersection Analysis block or CSV Export) in another to separate concerns.

  • For data passing and local state, combine subsystems with Data Write Local and Data Read Local to maintain local memory without polluting global flow.

  • When troubleshooting, open the subsystem and run only its contents to quickly identify which internal block is causing invalid or unexpected outputs.

πŸ› οΈ Troubleshooting

  • No outputs appearing Confirm you have exposed outputs inside the subsystem. If nothing is exposed, the block will not return data to the parent flow.

  • Inputs not received Make sure you created and exposed input sockets inside the subsystem and that the parent flow is connected to those exposed inputs.

  • Child block reports invalid Open the subsystem workspace and inspect child blocks. Errors inside the subsystem will surface thereβ€”fix the child block configuration or replace the problematic block.

  • Performance issues If the subsystem contains heavy processing (AI models, super-resolution, large batch operations), consider profiling inside the subsystem and moving non-essential processing to separate, on-demand subsystems.

  • Need to reuse or version Duplicate the subsystem and keep one testable copy. This makes it safe to try different parameters or models without affecting the production flow.

Last updated

Was this helpful?