What a script is

A script is a piece of Python that acts: it runs on a trigger, computes, and writes what it decided. The difference from a tag is why it has a page of its own — a tag computes a value when somebody reads it. A script that appends a record or sets a setpoint has no reader, and so would never run at all.

A path, not a name

A script is filed under a path, dotted, the way a tag is: Plant1.Press.Counter. Everything before the last segment becomes a folder in the tree on the left. The path is a name, not the identity: a rename leaves the script the same object, and a folder can be moved with everything under it in one go.

What is on the page

The tree on the left lists every script. The leaf says whether one is enabled, disabled, or a library — and, if triggers have been lost, how many.

The middle is the code.

The properties column on the right carries the trigger, the inputs and the limits. It scrolls for itself: switching from Manual to Cyclic unfolds four fields, and the code must not move because of it.

The dock along the bottom carries what the script has done — see Runs and problems.

What a script reads

Inputs are the tracked way. You give each input a name and bind it to a tag; in the code the value is then inputs["name"]. Because the binding is to the tag, renaming that tag changes nothing.

Beside that there is system.tag.read("Press1.PartCount"). It is convenient and the weaker of the two: outside the code, nothing knows about that dependency. Rename the tag and the script breaks with no warning beforehand. The editor says so as soon as system.tag.read() appears in the code.

Everything TrakState offers stands under system. — type system. and the editor shows the rest. inputs, params and the hooks stay bare: they are the script’s contract, not a library. The full list is under The script interface.

What a script writes

system.tag.write("Line1.Scripts.Threshold", 42) asks for a write. The script itself reaches neither a database nor a broker; it collects its requested writes, and the instance carries them out afterwards — with its rights, not with the code’s.

That is exactly what makes the dry run possible: the same path, with nothing carried out at the end.

print() goes to the run’s output. It appears in the log and in the dry run, because that is how anybody hunts a mistake in a twenty-line script.

Dry run and real run

Two buttons, and they must never be confused:

• Dry run executes the script with the current values and writes nothing. What it would have written is shown as Would write (nothing was written).
• Run now runs it for real. The writes happen.

The run log shows facts only — what was actually written and whether it reached the machine. Intentions belong to the dry run and nowhere else.

The limits of a run

• Time. A run is stopped after 5 seconds unless something else is set for it. Everything the script started is stopped with it - nothing it starts outlives the run.
• Output. Printing in a loop fills no memory here: the output is capped.
• Memory, processes, files. On Linux a run as a whole - the script and everything it starts - is held to its memory limit, a number of processes and a maximum file size. Windows has no equivalent for these.
• At most 32 at once. On an installation that gives each run its own user, up to 32 scripts run at the same time; a 33rd is asked to try again in a moment.
• No secrets — where the installation gives each run its own user. On a hosted pool, and on a Linux server set up for it, a script runs as a user of its own: it sees none of the installation’s passwords or keys, the server’s files and process are out of reach, and whatever it leaves in temporary directories is removed after the run. On a developer machine (no own user), a script instead runs as the server’s own user and can read the server’s files and environment — the network setting still applies, but this protection does not. The scripts page says so when it is the case.
• Network. A script may connect where the setting behind the button Scripts: … at the top of this page allows - by default anywhere except to the installation itself. Its database, its other services and the server it runs on are never reachable, whatever is set. See Network for scripts.

What a script can still do is everything its tenant may do through the instance: system.tag.write writes with the instance’s rights. Creating, changing, enabling, disabling and deleting a script therefore appear in the audit trail, and so does every change to the network setting.

Objects from a template

A template from the store (Settings › Templates) creates scripts under a namespace of its own, for example OEE.Kpi.Compute. Such scripts carry a badge “from