Follow the packet. A test UDT sends a query from the Ignition gateway to its assigned database. The database returns data in its native format, the UDT maps that data into Name, product tested, date, and overall pass, and a gateway-level coordinator decides when the complete unit result can move to the PLC. The race appears at that final decision point when several asynchronous completions can invoke overlapping evaluations.
Where does the result path stop?
Layer one first. Before changing scripts, trace each database connection from the gateway host through its network path to the configured database listener. A failed link, route, name resolution, listener, or database session can look like an aggregation defect because one test never publishes completion.
| Hop | Sender | Receiver | Configuration to inspect | Proof before proceeding |
|---|---|---|---|---|
| 1 | Ignition gateway | Database endpoint | Configured host address and route | The gateway host reaches the intended endpoint |
| 2 | Database client connection | Database listener | Configured listener port and connection state | The connection opens without transport or authentication failure |
| 3 | Test UDT query | Database operation | Query assignment and execution state | The database returns one terminal outcome for the request |
| 4 | Test UDT | Gateway coordinator | Standard result fields and completion state | The result data becomes readable before completion is published |
| 5 | Gateway coordinator | PLC | Unit result and valid indication | The PLC receives one complete result, not a partial set |
Keep transport diagnostics separate from completion logic. A coordinator cannot distinguish a slow query from a broken connection unless each test exposes running, completed, and failed terminal states or an equivalent status model. A Boolean completion value alone represents only unfinished versus finished; it cannot explain why a result is absent.
Check: Run one test by itself and trace its request, database response, normalized fields, completion publication, and PLC-facing output in that order.
Which tests belong to the current unit?
Define the expected participants before launching the queries. Do not repeatedly browse the live UDT directory and treat every object found at that instant as part of an already-running unit. Adding or removing a test while queries are active can otherwise move the finish line: a newly added test can prevent completion, while a removed test can make an incomplete unit appear complete.
Use one of two membership models. A fixed-capacity presence array records which positions are active in an “I am here” state, while an equally sized completion array records which active positions are done. A named dataset records the process name, completion timestamp, and optional returned result fields. The dataset costs more structure but makes diagnostics and changing membership easier to interpret.
| Model | Membership | Completion | Best fit | Main constraint |
|---|---|---|---|---|
| Boolean arrays | Presence bit at each assigned position | Done bit at the same position | Stable position assignments and simple PLC-style state | Both arrays must use identical position meanings and capacity |
| Named dataset | One row per selected process | Timestamp or None
|
Dynamic tests, completion ordering, and richer result data | Each active run needs a stable membership snapshot |
| Live UDT browse | Objects currently found under the directory | Status read from each object | Discovery before a run or after project changes | Do not let a changing browse result redefine an active run |
For Boolean arrays, completion means every position marked present is also marked done. Unused positions do not participate. For a dataset, completion means every row in the frozen expected set contains a terminal status. A timestamp carries more diagnostic value than True: it shows completion order and distinguishes an unfinished or reset entry represented by None.
Check: Start a unit and record its expected test names or occupied positions; confirm that the expected set remains unchanged until that unit finishes or aborts.
How should each asynchronous query publish completion?
Give each test one owned completion location. A test may write only its assigned array element or dataset row. It must publish normalized result data first and completion last. That ordering prevents the coordinator from seeing a completed test whose Name, product tested, date, or overall pass fields still belong to the previous run.
Pseudocode for one test:
execute assigned database query
map returned fields into the standard result
write the standard result
write the terminal status or completion timestampDirect element writes avoid the classic shared-array race. If two scripts instead read the entire array, modify different positions locally, and write the entire array back, the later write can overwrite the earlier completion. Confirm how the selected tag and scripting operation handles indexed writes. If the operation only supports whole-array replacement, route all array updates through one serialized writer or protect the read-change-write sequence with a lock.
Also define the failure path. A query error must not leave an indistinguishable permanent “not done” state. Publish the failure as a terminal state with diagnostic detail, then let the coordinator apply the installation’s policy: reject the unit, request operator action, or permit a controlled retry. Do not publish a valid PLC result while any required test remains running or failed.
Check: Complete two tests nearly together and verify that both owned completion locations remain set and that each location points to the matching normalized result.
What should trigger the aggregate decision?
Use one gateway-level coordinator for the line or dynamically discovered group. The UDT queries produce state; the coordinator consumes that state. Avoid letting every completing query independently finalize and reset the unit because two near-simultaneous completions can both observe “all done” and both send the result.
| Trigger | Timing behavior | Dynamic configuration | Failure mode to control |
|---|---|---|---|
| Gateway timer | Evaluates persistent state on each configured interval | Can use a programmatically generated test list | It may evaluate an all-complete state more than once |
| Gateway tag change | Evaluates when a monitored value changes | Static monitored tags require maintenance as tests change | An event alone is not a durable record of unfinished work |
| Message-triggered evaluation | Runs when a producer sends a message | Producers and routing must remain aligned with membership | Multiple messages can produce overlapping evaluations |
| Change on one aggregate array or dataset | Evaluates after shared state changes | Membership stays inside the shared structure | Reset writes also create changes and must not retrigger finalization |
A timer trades repeated reads for a simple recovery property: persistent completion state remains visible on the next evaluation even if an earlier execution fails. A change event reduces idle evaluations but still needs durable state, duplicate suppression, and a restart strategy. Dynamic discovery can run at gateway startup and when the project configuration changes, while the active unit continues to use its frozen membership snapshot.
The coordinator’s decision is a set comparison, not a completion-order test:
take the frozen expected set
read one coherent snapshot of membership, status, and results
stop if any expected test is running or failed
stop if this unit was already finalized
otherwise publish the unit result exactly onceCheck: Invoke the coordinator repeatedly while only part of the set is complete; confirm that it produces no PLC-valid result until every expected test reaches the accepted terminal state.
How do you prevent duplicate finalization?
Serialize the transition from “all tests complete” to “unit finalized.” A lock prevents two coordinator executions from entering the decision block together, but a lock alone does not remember that an earlier execution already finalized the unit. Pair serialization with a persistent finalized state tied to the active unit.
- Enter the coordinator’s exclusive section.
- Read the expected membership, every terminal status, and the finalized state again inside that section.
- Exit without action if any expected test is incomplete, any required result is invalid, or the unit is already finalized.
- Assemble the standardized unit result from the same accepted snapshot.
- Write the result to the PLC-facing location.
- Set the valid indication and record that this unit was finalized.
- Leave the exclusive section.
- Reset membership and completion state only after the consuming sequence no longer needs the result.
The re-read inside the exclusive section matters. A preliminary check can decide that finalization looks possible, then wait behind another execution that completes and resets the unit. Acting on the preliminary snapshot after acquiring the lock can publish stale or duplicate data.
Reset order also carries data-path meaning. Clearing completion before the PLC has consumed the valid result can make diagnostics lose the contributing test states. Clearing the finalized state too early allows a still-true all-complete set to fire again. Treat finalization and reset as separate state transitions.
Check: Hold every completion state true while running the coordinator multiple times; verify that the PLC-facing valid transition and unit result publication occur once.
What happens when tests are added or removed?
Apply membership edits between unit executions. For the two-array design, the system that adds or removes a device changes its assigned position in the presence array, and that same position carries its done state in the completion array. Clear the completion position when removing or reassigning a participant so stale state cannot satisfy a future run.
Size both arrays equally and keep a single mapping from position to process. A capacity larger than the current device count permits later additions without restructuring the tags, but unused positions must remain absent. If the installation can exceed that capacity, reject the edit or move to a structure that can expand before the next unit begins; never truncate an active expected set silently.
For a named dataset, stage configuration changes separately and build a new row set for the next unit. Names remove the ambiguity of reused positions and allow extra columns for timestamps and result objects. They do not remove concurrency concerns: one writer must still control structural edits, and test completions must target the correct active row.
| Change | Active unit behavior | Next unit behavior | Required check |
|---|---|---|---|
| Add a test | Keep the frozen expected set | Include the new test after configuration validation | The new test cannot block the active unit unexpectedly |
| Remove a test | Keep or deliberately abort the active unit | Exclude it and clear stale completion state | No old done value satisfies a reused position |
| Reassign a position | Do not alter the active mapping | Apply the new process-to-position mapping | Presence and completion arrays still refer to the same process |
Check: Stage one addition and one removal during an active run; confirm that neither changes the active expected set and that both appear correctly in the following run.
How do you verify the complete commissioning sequence?
Test state transitions, not only the normal completion order. Observe the query request, database return, normalized result, owned terminal state, aggregate decision, and PLC-facing valid result for every case.
- Run all tests with different natural completion orders. Confirm that order does not affect the final content.
- Complete two tests as close together as the installation permits. Confirm that neither completion update is lost.
- Delay one database response. Confirm that completed peers remain recorded and the unit valid indication stays false.
- Produce a database or query failure. Confirm that the coordinator reports a terminal failure path and does not publish a passing unit.
- Run the coordinator repeatedly after all tests complete. Confirm one finalization.
- Restart or reload the coordinating execution while work is pending. Confirm that persistent membership and completion state allow an unambiguous recovery decision.
- Add and remove tests between runs. Confirm that discovery updates the next membership snapshot without changing the current one.
- After PLC consumption, perform the reset sequence. Confirm that membership, completion timestamps or bits, finalized state, result data, and valid indication are ready for the next unit without retaining stale completion.
Check: Capture one end-to-end run and match every PLC result field to the normalized result from each expected test in the frozen membership set.
FAQ
What happens if two Ignition database queries finish at the same time?
Each query must write only its owned completion element or row. If scripts replace an entire shared array, serialize that read-change-write operation; then let one coordinator finalize the unit under a lock and persistent finalized state.
What happens if a test is added while a unit is running?
Keep the active unit’s expected set frozen. Validate the added test and include it when building the next unit’s presence array or named dataset.
What happens if the gateway coordinator sees all tests complete twice?
The second execution reads the finalized state inside the exclusive section and exits without republishing. Clear that state only as part of the controlled reset after the result no longer needs to remain valid.
What happens if one database never returns a test result?
The required test remains running until the query layer publishes a terminal failure or an authorized recovery action changes the state. Force one query to remain pending and verify that the PLC valid indication stays false; then complete or fail that query and verify exactly one corresponding final decision.