# Subsystem Enabled This function block provides an enclosed subsystem that can be run conditionally. Use it to group a collection of blocks (a small scenario) and control when that collection executes. It is ideal for building optional processing branches, feature toggles, or guarded workflows that should run only when explicitly enabled. ## đŸ“Ĩ Inputs `Enable`\ A boolean input that controls whether the enclosed subsystem runs. * If this input is connected and set to False, the enclosed subsystem will be skipped. * If this input is not connected or set to True, the enclosed subsystem will run. (The block accepts further inputs indirectly by exposing inputs of the enclosed blocks.) ## 📤 Outputs `Dynamic Outputs`\ This block does not declare fixed outputs. Instead, when the enclosed subsystem runs it exposes the outputs produced by the blocks inside it. Think of this block as a container: its outputs mirror whatever outputs the inner blocks provide. ## 🕹ī¸ Controls `Subsystem Canvas`\ A visual area where you can open or edit the enclosed subsystem. Drop blocks inside this canvas to build the internal flow. `Enable`\ The input socket described above acts as the primary control for turning the subsystem on or off. (There are no extra sliders or buttons on the block itself; all controls are the blocks you place inside the subsystem and the `Enable` input you provide.) ## 🎨 Features * Encapsulation — group related processing steps into a single reusable unit that can be enabled or disabled. * Conditional execution — run the internal workflow only when desired, simplifying top-level graphs. * Dynamic outputs — the block forwards outputs from its internal blocks so the top-level flow can consume them when the subsystem is active. * Visual separation — keeps the main flow tidy by hiding detailed processing inside the subsystem canvas. ## ⚙ī¸ Running mechanism * If the `Enable` input is connected and False, the subsystem is not executed and the block will provide its default outputs. * If the `Enable` input is not connected or is True, the subsystem is executed and the outputs from internal blocks are collected and exposed. * The block monitors internal blocks for invalid states; if any internal block reports an error the block will indicate an invalid state so you can inspect and fix the subsystem. ## 📝 How to use 1. Add the block to your canvas. 2. Double-click or open its canvas to place and connect blocks that implement the desired functionality. 3. Provide an `Enable` input (for example, a `Logic Input` or a boolean signal) to control whether the subsystem runs. If you leave `Enable` disconnected the subsystem will run by default. 4. Connect outputs from internal blocks to the subsystem outputs (they will appear on the parent canvas when available). 5. Use the parent graph to route data into and out of the subsystem as needed. ## 💡 Tips and Tricks * Use `Logic Input` to toggle the subsystem on/off manually during testing. * Use `Rising Edge` if you want the subsystem to run only on the first activation rather than continuously. * Place image acquisition blocks such as `Camera USB`, `Camera IP (ONVIF)`, or `Stream Reader` inside the subsystem when you want to enable/disable camera processing as a single feature. * Combine with `Show Image`, `Image Logger`, or `Record Video` inside the subsystem to control visualization and saving only when the subsystem is enabled. * Use `Data Read Local` / `Data Write Local` (or global equivalents) to exchange data between the parent graph and the enclosed subsystem when you need persistent state or cross-subsystem communication. * For triggered or timed behavior, combine with blocks like `Delay Step` or `ON Delay` inside the subsystem to shape execution timing. * Use the subsystem to encapsulate experimental pipelines (for example: preprocessing -> detector -> postprocessing). This lets you switch the entire pipeline on/off without re-wiring the main graph. ## 🛠ī¸ Troubleshooting * Subsystem does not run: check the `Enable` input. If it is connected and False, the subsystem will be skipped. * Expected outputs not visible: ensure the internal blocks are connected to produce outputs and the subsystem has been executed while enabled. * Internal error state: open the subsystem canvas and inspect blocks for red/invalid indicators; fix configuration or missing inputs inside the canvas. * Need to always reset outputs: place state-reset or initialization blocks inside the subsystem to ensure consistent default outputs when the subsystem is not running. --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://docs.augelab.com/function-blocks/data-logic/flow-control/subsystem-enabled.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.