Appearance
Input / Output Nodes
Last updated
I/O nodes read and write tags and data tables, call scripts and other workflows, and control ladder tasks.
Read Tag
| Field | Default |
|---|---|
| Device | — |
| Tag Path | — |
| Output variable | value |
Stores the tag's last known value — the same value dashboards show. It does not poll the device, so the value is as fresh as the tag's scan rate. If the tag has never had a value (device offline since start, wrong path) the variable is empty and {{value}} stays literal.
Set Tag
There is no separate "Write Tag" node; Set Tag writes.
| Field | Default | Notes |
|---|---|---|
| Device | — | |
| Tag Path | — | |
| Value Source | Manual value | Manual value or From another tag |
| Value (or {{var}}) | — | Manual value only. Sent as text; the driver converts it to the tag's type |
| Source Device / Source Tag | — | From another tag only. Copies that tag's last known value |
- A tag on the Local Tags device is written directly.
- Any other device must have Tag Write Access turned on in its settings, or the run fails with Write access not enabled for device 7. See Devices.
- From another tag with no value fails with Source tag …has no value to copy.
- The node waits for the driver's answer, and a write the driver reports as failed fails the run with the driver's message (or Write to
<tag>on device 7 failed). Some PLCs accept a write they then ignore, for example to a tag the program overwrites every scan, so if a write matters, read the tag back afterwards with Read Tag and compare it with Condition.
Tags on a paired appliance. Another Scada.Ink appliance paired on the Mesh page appears as a device named after it, so Read Tag and Set Tag work on its shared tags (pick that device, tag path such as Local Tags/Speed). A Set Tag write to it does wait for that appliance's verdict, and fails the run when it refuses. Workflows have no node for script messages between appliances. See Paired Appliances (Mesh).
Read DB
Reads rows from a data table (see Data Tables).
| Field | Default | Notes |
|---|---|---|
| Table name | — | The table's name exactly as on the Data Tables page |
| Max rows | 100 | Capped at 1000 |
| Where column (optional) | — | A column name |
| Where value variable | — | The name of a run variable (no braces) whose value the column must equal |
| Output variable | rows | A list of row objects, newest first |
The filter applies only when both Where fields are set and the variable exists; otherwise all rows (up to Max rows) come back. Trigger data such as value is not a run variable — copy it with Set Variable first. An unknown table fails with Table not found: ….
Write DB
| Field | Default |
|---|---|
| Table name | — |
| Operation | Insert |
| Row ID (update only) | — |
| Column values | none |
Under Column values, click Add once per column. Type the column's exact name, then either a Value — which accepts {{var}}, e.g. {{value}} — or choose Tag and pick a tag to write its current value. Columns you leave out get the table's default on insert and stay unchanged on update. Update changes the row whose id is in Row ID ({{rowId}} works).
A run fails with No column values to insert (or …update) when the list is empty, and with Unknown column in table "…": name when a name doesn't match the table — copy names from the Data Tables page. A {{var}} value is text, which the database converts to the column's type; a boolean tag is written as 1 or 0.
Run Script
| Field | Default |
|---|---|
| Script | — |
| Parameters | none |
Runs the script and waits for it to finish. If it completes, the run continues from Out; if it fails, from Error. The script's own return value isn't passed back — to hand back a value, have the script write a local tag and read it with Read Tag — but the Status and Log dots do carry the run's own outcome (completed/failed and its log lines) if you wire them downstream.
The script receives in context: trigger = workflow, workflowId, depth, every variable of the run, and each parameter, also collected in context.params. See Scripts and Workflows.
Run Workflow
| Field | Default |
|---|---|
| Workflow | — |
| Parameters | none |
Runs another workflow and waits for it. Continues from Out if the child completed, Error if it failed. The child receives every variable of this run plus the parameters, as variables. Nothing comes back except success or failure — the child's variables are not returned.
A disabled child doesn't run: the node continues from Error with Workflow "…" is disabled. The child needs a trigger node (use Called by Workflow), and every trigger branch in it runs. Calling the same workflow fails; nesting deeper than 5 levels fails.
Parameters
Run Script and Run Workflow (and the dashboard button) share the same parameter list. Click Add for each one:
| Part | Meaning |
|---|---|
| Name | The name the receiver uses: {{name}} in a workflow, context.params.name or context.name in a script |
| Value / Tag | Value — typed text, which may contain {{variables}}. Tag — pick a tag; its last known value is read when the node runs |
The × button removes a parameter. A parameter with the same name as a run variable replaces it for the callee.
Enable/Disable Script and Enable/Disable Workflow
| Field | Default |
|---|---|
| Script or Workflow | — |
| Enable | ticked |
Ticked enables, unticked disables. Disabling removes the triggers so nothing fires it again; a run in progress finishes. It does not stop the target being run by a button, a schedule or another Run node. Fails with Script not found: … / Workflow not found: … if the target was deleted.
Example — pause a "high scrap" alert workflow while a changeover is in progress: a Tag Change trigger on Line1/Changeover, a Condition {{value}} == true, True → Enable/Disable Workflow with Enable unticked, False → the same node with Enable ticked.
Start Ladder Task / Stop Ladder Task
| Field | Default |
|---|---|
| Ladder Task | — |
Starts or stops scanning a ladder task, exactly like the Start/Stop buttons on the Ladder Logic page. Starting a task that is already running, or stopping one that is stopped, does nothing. It does not change the task's Enabled setting, so it does not decide whether the task starts by itself after a restart. See Starting, Stopping and Faults.
Ladder Task Status
| Field | Default |
|---|---|
| Ladder Task | — |
Continues from Running or Stopped, with the Scan ms and Fault dots carrying the task's current scan time and fault message if you wire them downstream. A ladder fault does not stop a task — it keeps scanning and takes the Running path, with Fault set — and a task that doesn't exist takes Stopped.
Example — make sure the line's task is scanning after someone stopped it, and tell the supervisor: Schedule (Interval 60000) → Ladder Task Status → Stopped → Start Ladder Task → Send Email.