> For the complete documentation index, see [llms.txt](https://docs.tricloudnexus.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.tricloudnexus.io/management-portal/oee/equipment/tag-mapping/calculations.md).

# Calculations

Combine multiple tags into one signal using a variable-based expression. Same engine as the Equation data connector.

When no single tag carries the signal an OEE pillar needs, switch to the **Calculation** tab in the Select Tag Mapping dialog. You define one or more **variables** — each pointing at a tag — and an **expression** that evaluates to the value the OEE engine should use.

A Calculation can drive any input slot: Equipment Run State, Error Code, Product Id, Ordered Products, or any of the Quality counts.

<figure><img src="https://570593659-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FYMGRODsc2QD3N3wmfwTl%2Fuploads%2Fgit-blob-549e30d5264ccefec24dba021f592e64c299ef89%2Foee-calculation-editor.png?alt=media" alt=""><figcaption><p>Calculation tab — available tags on top, Variables grid in the middle, Expression with Validate / Evaluate at the bottom</p></figcaption></figure>

***

## When to use a Calculation

Reach for a Calculation when:

* The run state is implicit — e.g. the PLC emits cycle start/end timestamps, and the equipment is running when `start > end`.
* A pillar input must be combined from multiple tags — e.g. line-level rejected count is the sum of per-station rejects.
* The signal must be coerced — e.g. a numeric state code needs to be compared against a threshold.
* A unit conversion is needed — e.g. produced units come in pallets but Ideal Cycle Time is per piece.

If the source tag carries structured data (a JSON object), prefer the [JSONata Value Parser](/management-portal/oee/equipment/tag-mapping.md#single-tag-jsonata-for-string-tags) on the Single Tag tab — it’s simpler than a Calculation.

***

## The procedure

1. Open the Select Tag Mapping dialog from the input slot you want to drive (Configure button).
2. Switch to the **Calculation** tab.
3. In the tag grid at the top, click a tag, then choose **Add** in the Variables section. The first added tag becomes variable `a`, the second `b`, and so on (a–z; if you exceed 26 variables, names continue as `var27`, `var28`, …). Double-clicking a tag also adds it.
4. To rename a variable to something more meaningful, double-click its **Symbol** cell in the grid and type a new name.
5. To remove a variable, click the trash icon at the end of its row.
6. Type the **Expression** in the field at the bottom — e.g. `a+b/c` or `a>b`.
7. Click **Validate** to check syntax. The result line shows either `Expression is valid` or one or more validation errors.
8. Click **Evaluate** to test the expression with sample values. The Evaluate dialog asks for a value per variable and returns the computed result.

<figure><img src="https://570593659-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FYMGRODsc2QD3N3wmfwTl%2Fuploads%2Fgit-blob-d8f0519921dfb90fba05c4bf4409362c9d3fb503%2Foee-evaluate-expression-dialog.png?alt=media" alt=""><figcaption><p>Evaluate Expression — supply a value per variable, click Evaluate, and the dialog returns the result. The dialog shows `True` / `False` for boolean expressions for readability, but downstream the engine treats them as the numeric <code>1</code> / <code>0</code> — so [States Mapping](../states-mapping.md) rows for a boolean run-state Calculation should be `1` and `0`.</p></figcaption></figure>

When the expression is valid and you’ve confirmed the result, choose **Select** at the bottom of the dialog to save the Calculation onto the input slot.

***

## Expression syntax

Calculations use the same engine as the [Equation data connector](/management-portal/designer/assets/data-connectors/equation.md). The full syntax — operators (`+ − × ÷ % ^ < > == != && ||`), built-in functions, and constants — is documented under Designer:

* [Operators](/management-portal/designer/assets/tags/collect/configuration/equation/operators.md)
* [Functions](/management-portal/designer/assets/tags/collect/configuration/equation/functions.md)

A few patterns that come up often in OEE:

| Goal                                           | Expression                                                                                                                                                         | Variables                            |
| ---------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ------------------------------------ |
| Boolean run state from cycle start/end         | `a>b`                                                                                                                                                              | `a` = StartCycle, `b` = EndCycle     |
| Boolean run state from "is running" thresholds | `a>0 && b<100`                                                                                                                                                     | `a` = current, `b` = idle counter    |
| Total produced when only per-station emitted   | `a+b+c`                                                                                                                                                            | `a`, `b`, `c` = per-station counters |
| Coerce a state code to a string label          | (use Equipment Run State as a Calculation that returns a numeric code, then map each code on [States Mapping](/management-portal/oee/equipment/states-mapping.md)) | one variable per state-code source   |

***

## Validating and evaluating

* **Validate** — runs static checks: every variable in the expression has a definition, the expression parses, no operator is misused. Errors are surfaced under the field; correct them before saving.
* **Evaluate** — runs the expression against sample values you provide. Useful for sanity-checking — *especially* boolean run-state expressions where you want to confirm `a>b` returns `True` for the inputs you expect at runtime.

The dialog won’t let you save until the expression validates cleanly. The **Select** button still saves a syntactically-valid expression even if you haven’t evaluated it; evaluation is purely a preview.

***

## Saving and resolving

When you save a Calculation onto an input slot, the slot’s display row shows a label like `Calculation: a>b`. Reopening the dialog restores the variables and expression for editing.

The OEE engine resolves the Calculation continuously: every time any of the underlying source tags emits a new value, the expression is re-evaluated and the slot’s effective value is updated. There is no separate "publish" step.

{% hint style="info" %}
The Calculation’s **CloudId** is generated when the calculation is created and remains stable across edits. That means downstream consumers (queries, dashboards) referencing the calculation by id keep working when you tweak the expression or rename a variable.
{% endhint %}