Actions

The named packages of labels, reports, Logic actions and database rows a run emits at Start or at Completion, their commands, the marker mappings of a label, the columns of a database row, and how a procedure selects them.

An action is a named package of paperwork a run emits: inside it, one command per emission, each saying what comes out (a label, a report, a run of a Logic action or a row in a factory database), when (at Start or at Completion), with which template of the station library, which Logic action or which database table and, at Completion, for which verdicts. A procedure selects whole actions, so a package written once serves every procedure that emits it, and correcting a command is one edit instead of one per procedure. Actions live under Process > Models > model > Setup > Actions. Creating them, removing them and editing an action's name, its commands and their mappings are all gated by the same Edit recipes & evaluations permission, and the pages say so ("Changing actions needs the “Edit recipes & evaluations” permission.").

The Actions folder

Selecting the Actions row opens a page unlike the other folders of Setup: a list of the model's actions beside the one picked in it, because an action is read against its siblings. The list's order is the order every procedure emits the actions in, so the row verbs move an action and never a command. The page loads the two station libraries (label templates and report layouts) to judge readiness; when one cannot be loaded, a banner says "Global label templates could not be loaded: …" or "Global reports could not be loaded: …".

The column beside the list is headed Action and shows the picked action's Name (editable here too), its Commands as read-only lines with a Ready / Review pill each ("The commands are edited on this action's own page in the column, in this order."), and a Needs review banner listing everything that is short. With no action, the list says "No actions. Add one when a procedure of this model should emit labels or reports, run Logic actions or write database rows."; with none picked, the column says "Select an action to read what it emits. Its commands are edited on its own page in the column."

The action's page

Selecting an action in the tree opens it: the header with the action's name and a pill counting its commands, the permission and library banners, an Action card with the Name field (committed on blur; blank refused), and the Commands list beside the command picked in it.

The Commands list

With no command the list says "No commands. Add one when this action should emit a label or a report."; with none picked the column says "Select a command to edit all of it in one place. Add one from the bar above when this action should emit a label or a report."

The command in full

The column opens the picked command, headed Command <n> · <Kind> at <Trigger>. It shows only the fields the chosen kind owns.

A Needs review banner under the fields lists everything the command is short of (see Readiness below).

The queue a printed document goes to is not a field of the command: it is resolved by the command's kind and trigger through the unit's four printer slots, so two commands of the same combination share the printer deliberately. See Printers. A Logic action command prints nothing and has no slot.

Logic action commands

A Logic action command is the hook a run leaves for whoever programs the station: at a boundary it runs one action of the Logic, which may send the run to another system through any driver, light a lamp or reset a counter. The action is picked by identity, so renaming it on the Logic page changes nothing here; its own editor lists this command in its Used by card.

Several Logic action commands of one moment run one after another, in the emission order below, and none is skipped because an earlier one is still running: every run gets its own. What a run does to the action is said on the action's page: its LAST RUN rail names the run as Process · <unit> · <action>, with the error and the refused writes when there were any, and the journal keeps them; nothing is written into the run file. An action deleted since the command was configured is skipped and a warning is journaled; a disabled one refuses to run and records why.

Database row commands

A Database row command adds one row to a table of a factory database, the traceability table an MES already keeps: the serial, the verdict and the measured values of the piece, under the column names that table already has. The row goes through a device of the Database driver on the Connector page, which holds the connection and the sign-in, so the command names no server and stores no password. The table already exists: the station never creates one or changes one, it adds rows to it.

While the tables are read the line under the picker says "Reading the tables of the database…"; when they cannot be read it says why ("The tables of <device> could not be read: <cause>"), and a database holding more than 500 says "The database holds more tables than the list shows: the first 500 are listed." A database row is born, like a report, answering to every terminal verdict.

Under the fields, Table columns lists one row per column of the table, in the table's order, each with its type as the database spells it and, where the table refuses a row without a value in it (the column takes no empty value, has no default and is not an identity, auto-increment or computed column), the pill Required by the table. Each column takes a Value; a column left to the database is left out of the row, so the database fills it with its own default.

The values at Completion are the ones the unit's LastRun serves the Logic, a criterion folded over every cycle it was judged in; a field the run did not ask for, and a criterion it did not judge, give no value (NULL). Read the columns again, on the head of the list, reads the table's columns from the database again: a column keeps the value it was given, a new one joins the list with none, and one the table no longer has leaves it.

The row is one INSERT naming the columns that have a value, every value a parameter of its own type and never text written into the statement, so a serial holding quotes or words of SQL is stored as the text it is. The database converts each value to its column's type as it converts any value. A database that refuses the row, does not answer within the driver's 10 seconds or cannot be reached only warns: the run is not affected, the journal records the refusal, and the run's record keeps the row with the refusal and its reason in the Database rows dossier of Histories. Nothing is kept to be sent later; Send again there sends the same values by hand. Several database rows of one moment go one after another, in the emission order below.

What a database row command is short of joins the list under Readiness below, in the order it is repaired: "Choose a Database device.", "The Database device it names no longer exists.", "The device it names, <device>, is not a Database device.", "Choose a table.", "Give at least one column a value: a row with no column is not written.", "<column> is required by the table and has no value.", "<column>: this value does not exist yet at Start; only a metadata field or a fixed text does.", "<column>: select a field of this model's metadata catalogue." and "<column>: select a criterion from one of this model's evaluations." What only the database can say is read while the command is open on this page, and joins the same list there: "The table <table> is no longer in the database.", "<column> is no longer a column of the table. Read the columns again.", "The table has columns this command has not read yet: <columns>. Read the columns again." and "The table could not be read from the database: <cause>". A procedure that selects the action says what it lacks for a column: "Column <column> reads a metadata field this Procedure does not prompt. Tick it in Metadata above.", "Column <column> reads a criterion result, and this Procedure judges by no evaluation." or "Column <column> reads a criterion this Procedure's evaluation does not declare."

Markers

Markers are the {{NAME}} fields a label template leaves for the run to fill in, so this section is drawn for a label command and for nothing else. Its state follows the template:

The sources, in the order the picker lists them:

Under the marker rows, Removed markers lists the mappings stored for markers the current template no longer declares ("<n> stale"; "These mappings no longer exist in the selected template and must be removed."), each with Remove stale marker mapping.

Readiness

The Ready / Review pills on both pages, and the rows the Validation page lists, come from one judgement. An action with no command is short of one: "Add a command: this action emits nothing yet." A command is short of, in the order it is repaired:

• "Select at least one completion verdict." (a Completion command with no verdict ticked)
• "Choose a report." / "The selected report no longer exists."
• "Choose a Logic action." / "The Logic action it names no longer exists." / "The Logic action it names is disabled, so it is refused each time it fires."
• "Choose a label template." / "The template was cleared or deleted; stored mappings are preserved." / "The selected global template no longer exists."
• "The selected template has no printer commands yet; write or import them before a run reaches this command."
• "Template markers cannot be read: <error>"
• "{{M}} needs a source." / "{{M}} is mapped more than once."
• "{{M}}: choose a source", "this source is not available at Start", "select a field of this model's metadata catalogue", "select a criterion from one of this model's evaluations", "set an explicit zero-based cycle from 0 to <n>", "remove decimal places from this date/time source", "use the default format for this numeric source", "decimal places must be between 0 and 9", "remove numeric/date formatting from this text source"
• "{{M}} was removed from the current template; remove its stored mapping."

A command under review still runs: nothing is dropped at emission, and a marker that cannot resolve fails that one label as it always did. The configuration screen is where this is learned, not the printed tag.

How a procedure selects actions

A procedure's page carries the card Actions this procedure emits with a "<n> selected" pill and one checkbox per action of the model, in list order. Each row shows the action's emission line ("Label at Start, Label and report at Completion", or "Emits nothing yet: this action has no commands.") and, once selected, a Ready or Review pill. Review lists what this procedure lacks for the action's markers, one remark per marker, because a marker resolved per run resolves only where the procedure has the thing it names:

• "{{M}} reads a metadata field this Procedure does not prompt. Tick it in Metadata above."
• "{{M}} reads a criterion result, and this Procedure judges by no evaluation."
• "{{M}} reads a criterion this Procedure's evaluation does not declare."
• "{{M}} reads cycle <c>, and this Procedure runs a single cycle." / "… runs <n>."
• "The Logic action it names no longer exists." (a Logic action command of the action, whose action was deleted: the procedure would run nothing in its place)

The action is neither hidden nor refused: the procedure says what it lacks, and the remedy is on the same page. With no action in the model the card says "No actions in this model yet. Add some under the model's Actions."

The emission order

At a run boundary the selected actions emit in the model list's order, and inside each action in its command order, filtered to that boundary's trigger: one answer for the whole model, never one per procedure. Start commands run once the run has materialized (after the sequential metadata has been reserved), and Completion commands once the terminal verdict has been sealed. Each command is isolated: a failure publishes nothing, changes nothing about the run and never stops the commands behind it. A report is named after the run and the action that emitted it; a later render of the same command replaces that command's document and nothing else. A Logic action command keeps that order among the Logic action commands of its moment; when it runs is said under Logic action commands. What each emission records in the run, and how it is reissued from Histories, is on Emitting labels and reports.

What an action does not do

• It emits nothing on its own. A procedure has to select it, and a run of that procedure has to reach the boundary.
• It does not check the procedure. Whether a procedure prompts the field or judges by the evaluation a marker names is stated on the procedure's page, beside the selection.
• It does not pick the printer. The queue is the unit's, by kind and trigger, on Printers.
• It does not edit templates. Label commands and report layouts are written under Templates; the action only names them.
• It does not confirm physical printing. Queue acceptance is what a label or a printed report records, never proof that paper came out.
• It does not wait for a Logic action, and does not record one in the run. The action's outcome is on its own page in Logic and in the journal.
• It does not create or change a table, and does not keep a refused row to send it later. A database row goes to a table the factory database already holds; a refusal is recorded in the run and sent again from Histories by hand.