After the unused Project Update event was disabled, saved changes to TrkPanels_Dev.Update could reach the runtime without treating the symptom as a client-cache problem. The decisive fault was the gateway-side compilation error mismatched input '\n\n' expecting INDENT, reported from the project lifecycle context [Middleware] Update Script.
Where does a saved script change travel?
Follow the packet in two separate paths. The execution path starts with a client timer event every two seconds. That event calls TrkPanels_Dev.Update, which reads PLC tags and database data, builds a dataset for a canvas template, and writes results to gateway and client tags. The update-distribution path starts when the edited library resource is saved. The gateway must process the project change, compile the affected scripting resources, activate the resulting project state, and make that state available to the connected client session.
| Path stage | Sender | Next hop | Observed condition |
|---|---|---|---|
| Project change | Saved project resource | Gateway project lifecycle | Gateway attempts update processing |
| Lifecycle compilation | Gateway project lifecycle | Project Update event | Compilation stops with PySyntaxError
|
| Runtime publication | Gateway runtime | Connected client session | Client continues invoking the older callable |
| Application execution | Client timer | TrkPanels_Dev.Update |
Invocation repeats every two seconds |
The PLC and database paths do not distribute project code. Successful data reads therefore do not prove that a newly saved script revision reached the session. The check before proceeding is the gateway log immediately after one save: confirm whether project lifecycle processing completes or emits the reported syntax error.
Is the physical or network layer blocking the update?
Layer one first, but stop there when the symptoms clear it. The running session remains connected, the two-second client timer continues firing, and the script continues exchanging application data. That behavior rules against a total physical-link or session-connectivity failure. No gateway address or port was supplied, so there is no basis for changing an address, firewall rule, or listener configuration.
| Item | Installation value | Diagnostic use |
|---|---|---|
| Gateway address | Not specified | Read from the working client connection; do not substitute a guessed address |
| Gateway port | Not specified | Read from the active gateway configuration; the connected session already demonstrates reachability |
| Client timer period | Two seconds | Provides a bounded observation interval for the next invocation |
| Client update setting tested | Notify |
Did not make the changed method take effect while the lifecycle error remained |
| Platform | Windows 11 Pro in a Hyper-V VM | No VM or operating-system transport fault was identified |
Changing the client update setting cannot repair a gateway compilation failure. The network check passes when the existing client remains connected and continues its normal two-second calls while the gateway log is inspected during a save.
Where does project activation stop?
The stack trace stops in gateway project lifecycle processing while compiling an update-script function. The important entries are ProjectScriptLifecycle.runUpdateScript, ProjectScriptLifecycle.onAfterChanges, and ScriptManager.compileFunction. Together with [Middleware] Update Script, they identify the Project Update event configured under Gateway Events; they do not identify a user library named “Update Script.”
The parser reports SyntaxError: mismatched input '\n\n' expecting INDENT at line 4. Python emitted that error because a preceding statement opened an indented suite but no valid indented statement followed before the blank lines. Common examples include an if, for, try, function definition, or similar colon-terminated statement with an empty or misindented body.
| Symptom | Mechanism | Deciding check |
|---|---|---|
| Edited library method remains old | Project change encounters a lifecycle compilation fault before clean runtime activation | Save once and correlate the timestamp with the gateway error |
| Logout or client closure exposes changed behavior | A reconnect creates a new session and reloads project state, masking the live-update failure | Test a save without reconnecting after correcting the lifecycle event |
| No library named “Update Script” exists | The label belongs to the Project Update event context | Open Gateway Events and inspect the Project Update script |
The path is proven when the Project Update event reproduces the line-4 parser error independently of the contents of TrkPanels_Dev.Update.
How do you correct the Project Update event?
Fix the gateway lifecycle script before changing session behavior. If the event has no required function, disable it as was done in this installation. If it is required, correct its indentation and validate every branch before saving the library again.
- Open the project’s Gateway Events configuration and select the Project Update event associated with
[Middleware] Update Script. - Inspect line 4 and the colon-terminated statement immediately above it. Look for an empty body, indentation at the wrong level, mixed structural alignment, or code removed while leaving its parent statement behind.
- If the block must remain temporarily empty, add an indented
pass. If the block is obsolete, remove the parent statement and its empty body together. - If the complete Project Update event is unused, disable it instead of retaining code that executes during every project update.
- Save the project and watch the gateway log for a fresh lifecycle compilation result.
Deleting unrelated unused library scripts may appear to change the symptom because it causes another project save, but it does not address the named compilation context. The checkpoint is a save that produces no PySyntaxError from [Middleware] Update Script.
Can an active invocation retain the old function?
Correct lifecycle compilation does not replace instructions inside a call that is already executing. A running event normally finishes against the callable it started with; a later timer firing can resolve the updated callable. An unbounded loop or an event waiting indefinitely can therefore make old code appear persistent. Event scripts should return rather than wait forever for an external condition.
The reported method does not use a while loop and processes defined cycle ranges, so the direct infinite-loop failure mode was not identified here. Still, prove completion rather than inferring it from source structure. Add temporary entry and exit logging around the timer callback or observe an existing completion indicator. Include a revision marker in the changed method’s returned dataset or tag write so that old and new invocations can be distinguished.
| Observation | Interpretation | Action |
|---|---|---|
| Entry and exit occur for each timer firing | The callback completes between invocations | Continue to runtime-publication verification |
| Entry occurs without exit | The current invocation is blocked or unbounded | Trace PLC, database, and internal waits; make the event return |
| Calls overlap at the two-second period | Execution time exceeds the scheduling interval or dispatch permits concurrency | Measure duration and prevent overlapping work before judging code replacement |
This checkpoint passes when one invocation exits and the following two-second invocation can display the new revision marker.
How do you verify the update end to end?
- Keep the existing client session open.
- Confirm that the unused Project Update event is disabled, or that its indentation fault is corrected.
- Clear the diagnostic view or note the current gateway-log timestamp.
- Make a harmless, observable change inside
TrkPanels_Dev.Update, such as changing a temporary revision marker written with the normal result. - Save once and confirm that no new
PySyntaxErrorappears from[Middleware] Update Script. - Wait for the next timer invocation. The configured observation interval is two seconds, but use the callback’s measured completion time if one call can run longer than that.
- Verify the changed marker in the dataset, gateway tag, client tag, or temporary diagnostic output used by the method.
- Repeat with one second harmless change without logging out or closing the client. This distinguishes live activation from a one-time reload.
Do not use logout as the acceptance test; it changes the session under test. The end-to-end check passes only when a saved revision crosses gateway lifecycle processing and appears on a later timer call in the same client session.
FAQ
What happens if the Project Update script has a syntax error?
The gateway logs a lifecycle compilation failure such as mismatched input '\n\n' expecting INDENT. Correct or disable that Gateway Events script before diagnosing client caching.
What happens if I set the client update mode to Notify?
Notify can govern how a session responds to an available project revision, but it cannot make a failed gateway revision valid. In this installation, testing Notify did not update the running method while the lifecycle fault remained.
What happens if the timer script is still running during a save?
The active invocation can continue with the callable it already entered. Prove that it exits, then check whether the next two-second invocation uses the revised method.
How do I prove an Ignition script updated without restarting the client?
Save an observable revision marker, confirm the gateway produces no Project Update compilation error, and verify that marker on a later two-second timer call in the same connected session.