Simulated Object, Graph, and Debug

Now replace page-owned status with a structure closer to a real project: an Object exposes workstation capabilities, a Graph orchestrates the packaging cycle, and the Page only sends commands and displays status. The entire example remains a software simulation with no PLC, motion axis, or I/O connection.

What you will accomplish

• Understand the Object, Graph, and Page responsibility boundary
• Ask AI to inspect capabilities available in the current app before creating the simulator
• Use a bounded wait with an explicit Timeout path
• Set a breakpoint and inspect Graph execution with Debug
• Change a timeout parameter yourself and verify the fault path

Four concepts are enough for now

Concept	Purpose
Object	A runtime equipment or business-module instance with named state and methods.
Graph	A visible, debuggable orchestration of object methods, conditions, and waits.
Wait Until	Rechecks a condition, continues on success, and follows Timeout after a defined limit.
Debug	Runs Graphs with breakpoints so you can inspect nodes, variables, and object state while paused.

Use this dependency direction:

Page → Object method → Graph orchestration → small, stable simulation or device capability

The Page does not own the machine sequence, and the Graph does not guess physical equipment meaning.

Before you start

• Complete Page variables, buttons, and Page Methods.
• Stop the app.
• Treat the behavior as an explicit simulator: the simulated sealer completes after about 1.5 seconds and never accesses physical I/O.

Step 1: Ask AI to make the architecture decision first

In AI Command Center, use @ to select qxauto, qxgraph, qxscript, and qxpage. Mention the current home page and send:

Goal: Replace the current page-only Packaging Workstation simulation with a debuggable Simulated Object + Object-bound Graph + Page implementation.

Confirmed simulation semantics:
- This is software-only and must not connect PLC, Pulsar, axes, I/O, cameras, or Safety
- After a packaging cycle starts, the simulated sealer completes after about 1500 ms
- On success, increment the package count and return the status to Ready
- On timeout, enter Fault, keep a readable error message, and expose ResetFault

Architecture requirements:
- Inspect the current Objects, available methods, Graph nodes, and Page controls first
- Reuse existing capability when available; create the smallest app-local ObjectBase simulator only if this app lacks the capability
- Create one clearly described Packaging Workstation object and bind a graph under graphs/
- Keep Init, Update, and Dispose lifecycle methods, and expose the page-facing StartCycle and ResetFault methods
- Use the standard Wait Until node available in the current app for the graph-level wait
- Give WaitUntil an explicit positive Timeout ms and a deliberate Poll interval ms; connect both Success and Timeout
- Add an inspector-editable graph variable named cycleTimeoutMs with a default of 3000
- Do not create an infinite loop, move the wait into a Page Method, or swallow timeout errors
- Update the page to call Object or Graph methods and read object runtime variables for status, count, and error; remove obsolete page-only simulation state

Validation requirements:
- Validate the final page and graph separately
- Run the app build after saved graph or C# changes and repair it until it succeeds
- Report changed files, the object ID, graph methods, success path, timeout path, and build result

Let the Object methods and Graph nodes available in the current app determine the smallest simulator implementation. Do not invent C# base-class members, graph port order, or runtime APIs in the prompt.

Expected AI impact

Reasonable changes may include:

• objects.json
• graphs/packaging-station.qxgraph
• One small simulator Object source under scripts/, only if existing capability is insufficient
• pages/packaging-station.qxpage
• i18n.json

AI also runs page and graph diagnostics plus the App Build. Generated build outputs are not source files you maintain by hand in this tutorial.

It should not change pulsar.json, PLC, Vision, queries, users, or Safety.

Step 2: Inspect the layered result

1. Find the Packaging Workstation object under Resources → Objects. Its ID and description should express its simulator role instead of using an ambiguous name such as Object1.
2. Open packaging-station under Resources → Graphs.
3. Confirm that the method list includes Init, Update, and Dispose, plus the cycle and reset methods the Page calls.
4. Find Wait Until and follow its control flow. Both Success and Timeout must lead to explicit handling.
5. Confirm that Condition is reread after each check and that Timeout ms and Poll interval ms have explicit values.
6. Open the home page. Its buttons should call Object or Graph methods, and its status should read object variables instead of QX.globals.lineRunning.
7. Confirm that Problems has no errors and that the title-bar Build state reports success.

If AI produces one large Page Method or a single C# method that hides the entire process, ask it to separate Object capability, Graph orchestration, and Page UI.

Step 3: Verify the success path first

1. Find the important node after normal completion in the Graph.
2. Select the breakpoint marker on the right side of the node title.
3. Select Debug in the title bar.
4. Open the runtime and start a packaging cycle.
5. After about 1.5 seconds, execution should pause at the success-path breakpoint and the app status should be Paused.
6. Inspect the object state and count in the debugger, then select Continue.

Expected result: the cycle completes, the count increases by 1, the state returns to Ready, and the error message is empty.

Your manual adjustment: Force one timeout

The graph exposes cycleTimeoutMs in the inspector so you can learn the boundary between human-confirmed parameters and AI-authored orchestration.

1. Select Stop and wait for the app to return to Stopped.
2. Select the Packaging Workstation object in Resources.
3. Set the object override for cycleTimeoutMs to 500 in Properties.
4. Add a breakpoint to the Graph's Timeout handling node.
5. Select Debug again and start a cycle from the runtime page.

The simulator needs about 1500 ms, while the timeout is only 500 ms. Execution should enter Timeout and pause at that breakpoint. After Continue, the page should show Fault and a readable error. ResetFault should return it to a testable state.

Object changes enter a new runtime on the next explicit load, Start, or Debug. Theseus does not replace a running object instance in place.

Debug acceptance checklist

• At the default 3000 ms, execution follows Success and increments the count
• With an object override of 500 ms, execution follows Timeout and never waits forever
• When paused, the editor opens and locates the active Graph node
• Continue leaves the breakpoint and Stop ends the debug session
• The Page shows Fault and ResetFault restores the simulator
• Problems has no errors and the App Build succeeds

Safety boundary

danger

This simulated Object cannot replace a field-device Object. Before connecting PLC, axes, I/O, or cameras, engineers must define real objects, addresses, units, actions, permissives, and fault semantics. AI may generate orchestration from those facts, but it must not invent them.

• A Stop button on a Page is not an emergency stop.
• A Graph timeout is a software recovery path, not a Safety interlock.
• Bounded waits for real equipment should be exposed through stable Object APIs and orchestrated by the Graph.
• Before commissioning, manually inspect Init, Dispose, every fault branch, and every physical output action.

Recovery guide

Symptom	Check and recovery
Build is unavailable	The app is still running, debugging, paused, or stopping. Select Continue or Stop and return to Stopped.
The Graph cannot find an object method	Check C# build diagnostics and the object type first, then ask AI to reread the Object methods available in the current app. Do not enter a guessed method name.
Wait Until always times out	Check that the Check branch refreshes state, Condition is reread, and the simulated completion time is shorter than the timeout.
The Page still changes QX.globals	Ask AI to remove the old page-simulation path and use read-only object variables plus Object or Graph method calls.
Debug does not stop	Make sure the breakpoint is inside the executed method and you started with Debug, not Start.
The runtime faults	Read the error details and Graph Trace, Stop, then mention the Graph or script and ask AI for read-only root-cause analysis before approving a repair and Build.

Next

Leave the 500 ms fault drill in place for now. The next tutorial restores the release value before building for a remote target and binding a Player terminal: Build, remote Runtime target, and Player.