Build, deployment, and runtime delivery

Build prepares Page Methods, Graphs, custom code, and PLC control logic as runnable artifacts for the target machine. Build does not start the app. Start and Debug build what is needed, deploy it, and then start.

When to use this page

• You are unsure whether saving a change is enough.
• Build is unavailable or has an error state.
• The app works locally but cannot start on a remote Runtime target.
• You need a minimum delivery checklist.

Where to go

• Build: editor toolbar, immediately to the right of the Runtime target selector.
• Start / Debug / Stop: the same toolbar control group.
• Problems: bottom editor panel for Page, Graph, Script, and PLC diagnostics.
• Runtime target: selector to the left of Build; it determines the destination machine.

What requires Build

Change	Manual Build guidance	How it enters the runtime
Page layout, widget properties, or fixed text	Usually no separate Build	Save; accept through Start/Debug before delivery
Page Method	Build or use Start/Debug	Generates and validates Page Method artifacts
Graph	Required	Build, then Start/Debug again
Custom Script Object	Required	New types and methods become usable after Build
PLC POU, Tag, Task, or IO mapping	Required	Use the unified toolbar Build, then Start/Debug
Variables, Queries, Recipes, or Object properties	Not compilation inputs	Save, then stop and restart any app that needs the new configuration
Motion, Vision, or Safety configuration	Usually no separate compilation	Save, then Start, Debug, or reconnect the module

When uncertain, run Build while Stopped. It checks the current app's runnable artifacts together.

Standard workflow

Build without starting

1. Save every open Page, Graph, Script, and PLC resource.
2. Confirm that the toolbar Runtime target is the delivery target.
3. If the app is Running, Debugging, Paused, or Starting, Stop it first.
4. Select Build.
5. Wait for the success message and confirm that Problems has no errors.

A remote target uses artifacts built for the platform reported by that target. Do not assume that artifacts for the editor computer can run unchanged on another platform.

Build and run

1. While Stopped, select Start or Debug.
2. Theseus prepares the app, deploys it to the selected Runtime target, and submits the start task.
3. Wait for Running, Debugging, or Paused when Debug hits a breakpoint.
4. Verify the runtime page, Console, Problems, and device feedback.

Change a running app

Saving project files does not replace the running instance. Use this loop:

1. Stop.
2. Save and Build.
3. Start or Debug.
4. Retest normal, boundary, failure, and recovery scenarios.

Build states

Appearance	Meaning	Next step
Build is enabled	Runtime artifacts may be changed	You can build
Building	Artifact generation is in progress	Wait; do not click repeatedly
Success message	Current artifacts were generated	Review Problems, then run
Red Build or an error tooltip	Custom-code or PLC build failed	Open Problems
Build is unavailable	App is running, debugging, paused, starting, or stopping	Stop and wait for Stopped

Diagnostic order

1. Open Problems. Fix Errors first, then evaluate Warnings.
2. Open the affected Page, Graph, Script, or PLC resource from the diagnostic.
3. Fix and save, then confirm that its live diagnostics clear.
4. Build again.
5. Start or Debug only after Build succeeds. Compilation success does not prove correct site behavior.

Typical categories:

Symptom	Check first
Page Method syntax or reference error	Current Page, method parameters, and QX references
Graph node or port error	Node types, connections, control branches, and Object methods
Custom Object compile error	Script syntax, types, and references
PLC build error	POU logic, Tag addresses, Task binding, and topology
Remote start failure	Current target, target RID, deploy permission, and target license
Build succeeds but behavior is wrong	Business sequence, device state, configuration version, and test conditions

What success looks like

• Build completes with no Problems error that blocks running.
• The selected Runtime target, target platform, and license match the delivery plan.
• Start or Debug uses the new Page, Graph, Object, and PLC behavior.
• Stop, failure, and recovery paths have been tested.
• Final changes are preserved in Git or a ZIP backup.

Common issues

Why is Build unavailable?

A runtime instance is still Running, Debugging, Paused, Starting, Stopping, or an Error still owns a loaded instance. Stop and wait for Stopped.

Why does Start show a build phase after a Page-only change?

Start and Debug prepare a deployable package and validate runtime content such as Page Methods even when you did not select Build manually.

Build succeeded, but the runtime page still has old behavior

Confirm that you started again and are viewing the app on the current Runtime target rather than another target or an old browser page.

The remote build fails even though local build succeeds

The remote machine may use a different operating system or architecture. Follow remote diagnostics and check PLC, custom dependencies, and target capabilities.

How AI can help

Reference Problems diagnostics and the affected files, then limit the scope:

Analyze the current Build failure. Group it as Page Method, Graph, Script, or PLC. Fix only errors that block the build and preserve the business sequence. Report changed files, Build results, and assumptions that still require site testing.

AI can propose repairs and organize diagnostics, but it cannot prove that equipment actions, safety circuits, or production cycle time are correct.

What a person must confirm

• Build targets the correct Runtime target and does not deploy to the wrong machine.
• Diagnostic fixes did not alter process semantics, device addresses, or Safety.
• Start/Debug, failure, and recovery tests meet delivery criteria.
• Production cutover, downtime, and rollback are approved.