Define the Failure Sequence
The intended cycle is: load one process node with three assembly pieces, rotate the table, and then load another node. The failure appeared after adding a second table: the robot loads incorrect parts at the first table, loads only one part at the second table, and continues loading one part in later cycles. This sequence points to configuration or state introduced with the second table, but the available evidence does not identify the specific statement or object causing it.
| Checkpoint | Expected result | Observed result |
|---|---|---|
| First table | Correct assembly pieces | Wrong parts loaded |
| Second table | Three pieces at one process node | Only one part loaded |
| Later cycles | Three-piece loading repeats | One-part behavior continues |
Why Priority and Resource Reservation Are Inconclusive
Changing flow priority and reserving the resource did not correct the sequence. That result does not prove those controls are ineffective; it shows that neither change, as configured, resolved the underlying selection or process-state problem. Flow priority may determine which eligible route runs first, while the reported symptom could originate in the statements that select parts, count assembly pieces, or release the table.
Resource reservation is a plausible part of the solution only if the assembly is transported and controlled as the reserved resource. The evidence does not confirm how the parts, assembly, robot, or tables are currently reserved, so treat this as a configuration hypothesis rather than a verified fix.
Audit the Second Table and Its Process Statements
- Determine whether the second table was created as a new object or copied from the first. A copied object is a primary inspection target because its process statements or references may still point to the first table's parts, nodes, or state.
- Compare the process statements associated with both tables. Trace the conditions that select a part, increment the assembly-piece count, authorize rotation, and reset the cycle for the next node.
- Trace the transported entity. If the model uses assemblies, verify whether the assembly itself moves under a reserved resource and remains reserved until all three pieces are loaded.
- Temporarily inspect each table independently, then restore both tables and observe the first cycle transition. This isolates whether the fault exists inside the second table's process or only when both table flows compete.
Verify the Correction
Start verification from a reset model state so the persistent one-part condition does not carry into the test. Confirm that the first table receives the correct parts, that exactly three pieces complete the assembly at one node before rotation, and that the second table repeats the same sequence. Continue through later rotations to prove that the piece count and node state reset after every completed assembly.
If the fault remains, capture the process statements and object references for both tables. The available evidence is insufficient to identify a definitive root cause without those details.
FAQ
Why does adding a second table change which parts the robot loads?
The second table may have introduced competing flow eligibility or incorrect process references. First determine whether it was copied, then compare every table, part, node, and state reference in the two process definitions.
Will setting flow priority force three parts to load before rotation?
Not by itself based on the reported test. Verify that the process statements count three assembly pieces and block rotation until that condition is complete.
How should I verify a reserved assembly resource?
Trace whether the assembly is the transported reserved entity and whether its reservation remains active until all three pieces are loaded. Then verify that the reservation and piece-count state reset before the next node begins.
