FANUC FOCAS Trigger Node
Overview
The FANUC FOCAS Trigger Node automatically starts a MaestroHub pipeline when subscribed FOCAS address values change on a FANUC CNC. The FOCAS adapter polls the control on the plant network and pushes only changes; MaestroHub aggregates rapid changes within a 100 ms window into a single pipeline execution carrying the latest value for every affected address.
Use this trigger for event-driven flows — react to a run-state change, a part-count increment, or a spindle-speed move — instead of polling the machine from a schedule.
Core Functionality
1. Event-driven pipeline execution Start pipelines automatically when CNC values change, without polling from within MaestroHub. The adapter does the polling on the plant network and pushes only changes.
2. Intelligent debouncing Multiple address changes within a 100 ms window are aggregated into a single event, preventing excessive executions while ensuring you receive the latest value for every changed address.
3. Automatic subscription management Subscriptions are created and torn down automatically — no manual management. The system handles the connection lifecycle and re-establishes subscriptions after a reconnect.
4. Aggregated address data
All addresses that changed during the debounce window arrive in a single values array, so related changes are processed together.
Debounce Behavior
The FANUC trigger uses a 100 ms fixed debounce window to aggregate rapid changes:
- First change — when the first address value changes, a 100 ms timer starts.
- Subsequent changes — any additional changes within the window update the buffer with the latest value (keyed by address).
- Timer expires — after 100 ms the trigger fires once with an array of the latest values for all addresses that changed.
- Next window — the process repeats for the next set of changes.
Each subscribe function has its own independent debounce buffer.
| Scenario | Without debouncing | With debouncing |
|---|---|---|
| 10 rapid changes | 10 separate executions | 1 execution with all 10 values |
| Burst updates | Execution overload, queueing | Smooth processing with aggregated data |
| Related changes | Processed individually, context lost | Processed together |
The 100 ms debounce window is fixed and cannot be configured. Control the underlying poll cadence with the subscribe function's Poll Interval (see below).
Poll Interval and Deadband
Two settings on the Subscribe function (configured in the connection, not on the node) shape how the adapter detects changes:
- Poll Interval (ms) — how often the adapter polls the CNC for the subscribed addresses. Default
1000, clamped to a 100 ms floor (the adapter echoes the effective value). Lower it for faster reaction, raise it to reduce load on the control. - Deadband — an absolute numeric delta that suppresses sub-threshold changes on numeric addresses, measured against the last value actually pushed (so slow drift still eventually trips). Default
0(every change is reported). Ignored for non-numeric values.
The first poll cycle after subscribing sends every subscribed address (an initial snapshot); after that only changed addresses are pushed.
Reconnection Handling
MaestroHub recovers connection disruptions automatically. Reconnection is driven by the supervisor's ReconnectWorker (not inside the protocol client); on reconnect, the client re-establishes every active subscription.
| Scenario | Behavior |
|---|---|
| Brief network interruption | The adapter's own reconnect resumes polling on the same subscription; no MaestroHub action needed. |
| Adapter or WebSocket restart | MaestroHub detects the drop, reconnects, rebinds the CNC, and re-establishes subscriptions automatically. |
| CNC power-cycle / reboot | The adapter reconnects to the CNC with backoff and resumes polling on the existing subscription once it is reachable again. |
| MaestroHub restart | All triggers for enabled pipelines are restored on startup. |
Changes that occur during a disconnection may be missed — the subscription reports the current value once polling resumes, not the intermediate values. For critical counters, prefer reading an absolute value (e.g. a running part-count macro) over reacting to each increment.
Configuration Options
Basic Information
| Field | Type | Description |
|---|---|---|
| Node Label | String (Required) | Display name for the node on the canvas. Must be non-empty (trimmed). |
| Description | String (Optional) | Explains what this trigger monitors and initiates. |
Configuration
The configuration is organized across three tabs: Configuration, Test Data, and Basic.
| Parameter | Type | Default | Required | Description |
|---|---|---|---|---|
| Connection | Connection ID | "" | Yes | FANUC FOCAS connection profile. Filtered to FANUC connections. |
| Function | Function ID | "" | Yes | Subscribe function within the connection. Filtered to subscribe function types. |
| Enabled | boolean | true | No | Enable/disable the trigger. |
The selected function must be a FANUC Subscribe function type. Read, write, and status functions cannot be used with a FANUC Trigger node.
Subscribe Function Configuration
The Subscribe function (configured in the Connectors module) controls the subscription:
| Setting | Description | Default |
|---|---|---|
| Addresses | FOCAS addresses to subscribe to (e.g. status.run, spindle.1.speed, macro.500) | — |
| Poll Interval (ms) | Adapter-side poll cadence (100 ms floor) | 1000 |
| Deadband | Absolute numeric delta suppressing tiny changes (numeric addresses only) | 0 |
Test Data
The Test Data tab holds a Sample Payload editor and a Sample Quality picker. When you run the node with Test Node in Sandbox mode, the trigger emits the sample payload as result instead of waiting for a real change, so you can validate downstream nodes before a CNC is wired up. When the editor is empty, a built-in sample is used. Sample Quality sets the quality the sample reports in $trigger._metadata.quality (good, uncertain or bad). The live subscription and the node's Fire Trigger action do not use the sample.
Settings
The Basic tab holds the execution settings below, followed by the node's label and description.
Execution Settings
| Setting | Options | Default | Description |
|---|---|---|---|
| Timeout (seconds) | number | Pipeline default | Maximum execution time for this node (1–600). Leave empty for pipeline default. |
| Retry on Timeout | Pipeline Default / Enabled / Disabled | Pipeline Default | Whether to retry the node if it times out. |
| Retry on Fail | Pipeline Default / Enabled / Disabled | Pipeline Default | Whether to retry on failure. When Enabled, shows Advanced Retry Configuration. |
| On Error | Pipeline Default / Stop Pipeline / Continue Execution | Pipeline Default | Behavior when the node fails after all retries. |
Advanced Retry Configuration (visible when Retry on Fail = Enabled)
| Field | Type | Default | Range | Description |
|---|---|---|---|---|
| Max Attempts | number | 3 | 1–10 | Maximum retry attempts. |
| Initial Delay (ms) | number | 1000 | 100–30,000 | Wait before first retry. |
| Max Delay (ms) | number | 120000 | 1,000–300,000 | Upper bound for backoff delay. |
| Multiplier | number | 2.0 | 1.0–5.0 | Exponential backoff multiplier. |
| Jitter Factor | number | 0.1 | 0–0.5 | Random jitter (± percentage). |
Output Data Structure
When subscribed addresses change and trigger pipeline execution, the trigger produces a structured output with two top-level keys: _metadata and result. The result.values array holds every address value that changed during the 100 ms debounce window.
Output Format
{
"_metadata": {
"type": "fanuc_trigger",
"connectionId": "bf29be94-fc0a-4dc4-8e5c-092f1b74eb4b",
"functionId": "aef374c3-aa2b-454e-aabc-5657faac5950",
"protocol": "fanuc",
"eventType": "DATA_CHANGE",
"itemCount": "2",
"timestamp": "2026-07-09T10:00:01Z"
},
"result": {
"values": [
{ "address": "status.run", "value": "EXECUTING", "ts": "2026-07-09T10:00:01Z" },
{ "address": "spindle.1.speed", "value": 2050, "ts": "2026-07-09T10:00:01Z" }
]
}
}
_metadata Fields
| Field | Type | Description |
|---|---|---|
type | string | Always "fanuc_trigger". |
connectionId | string | The FANUC FOCAS connection profile ID. |
functionId | string | The Subscribe function ID. |
protocol | string | Always "fanuc". |
eventType | string | Always "DATA_CHANGE". |
itemCount | number | Number of addresses in the values array. |
timestamp | string | When the event was produced. |
quality | string | The frame's verdict, worst-of across values: bad when any address carries a FOCAS error in place of a value, good otherwise. Per-address detail stays in result.values[].error. A UNS Publish node downstream inherits the verdict. |
result.values[] Fields
Each entry represents one address that changed:
| Field | Type | Description |
|---|---|---|
address | string | FOCAS address (e.g. "status.run", "spindle.1.speed"). |
value | any | Current value — type depends on the address (number, string enum, or boolean). |
ts | string | Adapter timestamp for the value. |
Referencing in Downstream Nodes
Use expressions to access the data in later nodes:
$trigger.result.values— array of all changed address values$trigger.result.values[0].address— address of the first changed item$trigger.result.values[0].value— value of the first changed item$trigger.result.values[0].ts— timestamp of the first change$trigger._metadata.connectionId— connection profile used$trigger._metadata.functionId— subscribe function used$trigger._metadata.itemCount— number of addresses that changed$trigger._metadata.protocol— always"fanuc"
Validation Rules
Node Label
- Must not be empty or whitespace-only. Error: "Node name is required".
Connection ID
- Must be provided and reference a valid FANUC FOCAS connection profile. Error: "Connection is required".
Function ID
- Must be provided, reference a valid FANUC Subscribe function, and belong to the specified connection. Error: "Subscribe Function is required".
Enabled Flag
- Must be a boolean if provided.
Usage Examples
Run-State Change → Notify
Key configuration
- Label: Machine Run-State Monitor
- Connection: Line 1 FANUC 30i
- Function: Subscribe to
status.run - Settings: on error
continue
Downstream usage: branch on $trigger.result.values[0].value (EXECUTING / STOPPED / HOLD) and send an alert or update a dashboard when the state changes.
Part-Count Increment → Log
Key configuration
- Label: Part Counter
- Connection: Cell 3 FANUC 0i
- Function: Subscribe to
macro.500(a running part-count macro), Deadband0 - Settings: retry disabled, on error
stop
Downstream usage: read $trigger.result.values[0].value as the new count and append a row to a database or publish it to the UNS.
Spindle Speed Above a Deadband → Trend
Key configuration
- Label: Spindle Trend
- Connection: Line 1 FANUC 30i
- Function: Subscribe to
spindle.1.speed, Poll Interval500, Deadband50 - Settings: on error
continue
Downstream usage: forward $trigger.result.values[0].value to a time-series sink; the deadband suppresses jitter below 50 RPM so only meaningful moves are recorded.
Multi-Address Batch
Key configuration
- Label: Machine Snapshot on Change
- Connection: Line 1 FANUC 30i
- Function: Subscribe to
status.run,status.mode,spindle.1.speed,feed.actual
Downstream usage: the 100 ms debounce window ensures related changes arrive together in a single $trigger.result.values array — iterate it to build one combined state record per change burst.