QG flow, Object calls, and Debug

This lesson turns the Page-only simulation from the first two lessons into an App flow. QG owns the Packaging Workstation state, while the Page starts a cycle and reads results through Object methods. The example remains software-only and does not connect an external controller, axis, I/O, camera, or Safety capability.

What you will accomplish

• Use QG for sequencing, waiting, timeout, and recovery.
• Keep the Page responsible for presentation and operator input instead of embedding process logic in click handlers.
• Observe real execution with Debug Build, breakpoints, and Continue.
• Verify both success and fault paths yourself.
• Restore a safe simulation baseline for the delivery lesson.

Before you start

• Complete Page state, buttons, and events.
• Stop the current App and save the Page and every other change.
• Bind the title bar to the local runtime target.
• Confirm that this lesson runs only a software simulation. Real equipment is outside its scope.

Three boundaries to understand

Resource	Responsibility in this lesson
Page	Shows status, count, and fault text; accepts operator input; calls typed Object methods
QG Object	Owns simulated state and executes wait, success, timeout, and reset logic in order
Runtime target	Runs the version deployed by Build; saving source or switching to Flow does not replace it

QG Flow and Source are two views of the same .qg program, not two files that must be synchronized.

Step 1: Ask AI for the smallest flow

Open AI Command Center, add qxqg and qxqp through @, and send:

Goal: Move the current Packaging Workstation Page simulation into one QG Object and make the Page use it through Object methods.

Confirmed simulation behavior:
- Software-only; do not connect an external controller, Pulsar, axis, I/O, camera, or Safety capability
- A normal cycle waits for about 1500 ms, increments the package count, and returns to Ready
- A timed-out cycle enters Fault and keeps a readable error message
- ResetFault returns to Ready without clearing the accumulated count

Implementation scope:
- Create the Packaging Workstation QG and bind its Object to it
- Expose methods that read status, count, and the last error, plus StartCycle and ResetFault
- StartCycle receives an explicit timeoutMs; every wait must be cancellable and bounded
- If the count should persist, use QG.saved and do not select a custom storage path
- Update the current Packaging Workstation Page so its buttons call Object methods and refresh the display after each result
- Do not add a C# Provider, Query, device configuration, users, permissions, or Safety

Validation:
- Inspect current Objects, the Page, and available interfaces before editing; do not guess signatures
- Validate the changed QG document, Page document, and whole workspace
- Do not Build, Run, or control a runtime target; report changed files, Object ID, exported methods, and assumptions that still need human verification

AI should modify only the project files explicitly listed for this lesson. If it proposes another file change, ask it to stop and return to this scope.

Step 2: Inspect the result

1. Open packaging-station.qg under Resources → Scripts.
2. In Flow, confirm that success, timeout, and reset are separate readable paths. Switch back to Source and confirm that both views still represent the same program.
3. Select the Packaging Workstation Object under Resources → Objects, record its Object ID, and confirm that its Provider points to the .qg file.
4. Open the Page and confirm that its button calls this Object instead of incrementing a timer-owned Page count directly.
5. Open Problems. Live document errors should be resolved; the next step generates the full Build diagnostics.

If the Page still maintains another process status and count, ask AI to remove duplicate domain state. Keep only temporary interface state such as a disabled button or a “running” label while a request is pending.

Step 3: Verify the success path with Debug

1. Add a breakpoint to the QG Source statement that completes a normal cycle, such as the count increment or return to Ready.
2. Select Build Debug from the Build menu. Build uses saved files and deploys the result to the current target.
3. Select Debug and wait for Debugging.
4. Open the Page's Preview. Preview reuses the current Debug instance; it does not Build again or start a second App.
5. Start one cycle with the default 3000 ms timeout.
6. When execution pauses, confirm that QG Source/Flow locates the intended statement, then select Continue.

Expected result: after about 1.5 seconds, the cycle succeeds, the count increases by 1, status returns to Ready, and the fault text is empty.

warning

Object calls from Preview affect the currently bound runtime target. This lesson uses a software simulator. Once real equipment is connected, Preview is not a side-effect-free design canvas.

Step 4: Deliberately verify timeout

1. Add a breakpoint in the QG Timeout branch.
2. Keep Debugging, set the Page's timeout for this call to 500 ms, and start a cycle.
3. Inspect status and the error message when the breakpoint is hit, then select Continue.
4. Use ResetFault on the Page. Status should return to Ready while the accumulated count remains unchanged.
5. Restore the Page's default timeout to 3000 ms and save it.

This step validates fault handling; it does not try to produce a demo that never fails. If 500 ms still follows success, confirm that the Page passes the argument to QG and that both sides use the same unit.

Step 5: Establish the delivery baseline

1. Select Stop and wait for Stopped.
2. Confirm that every file is saved and the default timeout is back to 3000 ms.
3. Run Build Debug once more.
4. Start Debug again and repeat at least one normal cycle and one ResetFault.
5. Review this lesson's changes in Versions. There should be no device, Safety, user, or unrelated files.

Acceptance checklist

• The Page no longer owns a second truth for process count or timeout behavior.
• The QG Object ID, exported methods, and state meaning are clear.
• The default 3000 ms path succeeds and increments the count.
• The 500 ms path enters Timeout, reports a readable fault, and does not increment the count.
• ResetFault restores Ready and preserves the accumulated count.
• QG Source and Flow represent one program.
• Build Debug succeeds, and breakpoint/Continue work.
• The final default timeout is restored to 3000 ms.

Troubleshooting

Symptom	Check first
The Page cannot find an Object method	Confirm that QG is saved, the Object binding is correct, and Problems has no upstream Object/QG error
Preview says Build is required	Stop the App, save, and run Build Debug; Preview never Builds or Deploys by itself
Debug does not pause	Confirm a Debug Build, place the breakpoint inside the executed exported method, and verify that the current deployment belongs to this App
Timeout cannot be reset	Confirm that ResetFault restores only fault state and that no runtime fault remains active
A runtime fault returns to Stopped	Open fault details and Console, record the phase and message, then ask AI for read-only root-cause analysis first

Safety boundary

danger

A software simulator cannot replace a field-device capability. Before connecting real equipment, engineers must confirm equipment identity, addresses, units, polarity, limits, permissives, safe states, and recovery behavior. A QG timeout is a software process boundary, not an emergency stop or certified safety function.

Next

You now have an App baseline that can succeed, fault, and recover. The next lesson delivers it to a remote runtime target and binds Player: Build, remote runtime target, and Player.