Application guide by addaScanCompare the inspection task, imaging conditions and validation steps with your own production line.
- Inspection task
- Cell DPM reading and MES binding
- Decision focus
- cell dpm reading and mes binding
- Station planning
- Make retries refer to one physical cell event
- Illustrative scenario
- the read succeeds but the MES refuses it
Locate the cell’s permanent code before identity binding
The application images show the physical product and imaging conditions. The engineering diagram below explains the inspection logic and recovery decisions.
The code image illustrates the cell-surface identity task.
Select an image to view it at full size.
A readable cell code is only the start of binding
Swipe across the table to compare all columns →
| Condition | Approach to evaluate | Selection check |
|---|---|---|
| Mark difficult to image | Evaluate optics and reader settings on real DPM variation. | Separate imaging failures from data rejection. |
| Readable but unexpected identity | Apply the production-system rule. | A decoder cannot decide every business constraint. |
| Communication retry | Use event-aware acknowledgements. | Avoid duplicate or stale binding. |
Make retries refer to one physical cell event
Create an event identifier when the fixture receives a cell. Associate the fixture position, decoded value, inspection recipe and request identifier with that event. The response must identify the request it answers; it should not merely return a general success flag. The receiving system needs an agreed duplicate-request policy so retrying after a lost response does not create a second production record.
A dedicated reader may cover the optical task while a PLC, gateway or application manages the transaction. A smart camera or PC does not remove the need for this interface contract. Choose the architecture according to who owns buffering, acknowledgement, recovery and audit records. Define those responsibilities before comparing HIKROBOT and alternative reader specifications, because optical read rate alone cannot test them.
On a small screen, scroll across the diagram to inspect the labels.
Worked example: the read succeeds but the MES refuses it
In an illustrative station, cell event A produces a clear code. Format validation passes, but the MES reports that the cell is already assigned elsewhere. Keep the fixture in hold and record a binding rejection with the returned reason. Repeatedly reading the same code does not repair the business conflict; an authorised reconciliation is required.
Now consider a timeout instead of a rejection. The request might already have been committed. Query its status or retry using the agreed idempotent request identifier while event A remains active. Release only after a response confirms the required binding. If A is removed and event B begins, a late success for A is stored against A and cannot change B's release output. An operator override should identify the person, reason, original event and final disposition; it must not replace the original failed response with an apparent normal pass.
Swipe across the table to compare all columns →
| Observed evidence | Inspection decision | Action and retained record |
|---|---|---|
| The MES rejects a clear valid-format code as already assigned elsewhere. | Binding rejected; optical success cannot release the cell. | Hold the fixture, retain request and response identifiers and require authorised reconciliation of the existing assignment before disposition. |
| The binding request times out after transmission and its commit status is unknown. | Transaction pending, not confirmed failed or successful. | Query status or retry with the agreed idempotent identifier, preserve the event and release only after the required acknowledgement. |
| Success for cell A arrives while cell B occupies the fixture. | A's response cannot change B's state. | Store the response against A, keep B unresolved and reconcile any removed or held cells without silently overwriting the original transaction history. |
Prove recovery as carefully as normal reading
Disconnect the network after sending a request, repeat a response, restart the interface with a pending event and introduce an already-bound code. For each challenge, verify the fixture action and the database record together. A retry test passes only when the same physical event reaches the intended final state without duplicate binding.
Agree whether uncertain cells remain clamped, enter an identified buffer or cause a line stop. Store the code image, event and request IDs, response status and release confirmation. This record distinguishes an optical problem from a transaction problem and makes manual recovery possible without guessing which cell was affected.
Swipe across the table to compare all columns →
| Challenge | What to verify |
|---|---|
| Weak and reflective marks | Record no-reads independently. |
| Valid code from the wrong product | Verify MES or local recipe rejection. |
| MES unavailable | Confirm a defined hold or controlled recovery. |
| Cell changed during retry | Prevent association with the previous cell event. |
Cell identifiers and MES transaction rules
Provide the data format, fixture events, binding rules, acknowledgements and representative DPM quality variation.
Use the barcode verification grading guide to develop the next step.
Define the wider inspection responsibility in dpm code reading.
Develop the related acceptance requirements with assembly verification.
Use the optical and recovery challenges above when applying the architecture choices in vision-system comparison guide.
Scope and budget
The vision system cost guide helps separate image-reading work from MES transaction and assembly interlock integration.
Testing and handover
Use the testing and handover process to test acknowledgements, repeated identifiers and recovery before an assembly event is released.
The envelope verification project shows identity matching and FAT checks across an integrated line. Its event-association lessons are useful when defining a cell-to-assembly handover.