A range report can pass every frame check and still be assigned to the wrong request. This matters when an inspection instrument records a distance beside a photograph, a fixture position or an operator action. The host needs evidence that the accepted result belongs to that event.
For a documented command-and-response mode, define that association before choosing a timeout or adding automatic retries. Streaming modes need a separate timing contract; receiving the next frame does not prove that a newly issued command caused it.
Write down what the host can actually observe
Start with the exact model, firmware and interface document. Establish which commands produce acknowledgments, measurement results or both. Confirm whether replies contain a transaction identifier, whether commands may overlap, and how the device behaves after interruption. Leave undocumented behavior open for review.
A host can assign a local request tag without changing the wire protocol. That tag helps organize logs, but it does not become a device-echoed identifier unless the documented protocol supports one. Likewise, a reception timestamp records host delivery, not the instant of optical measurement.
| Field | Purpose and limitation |
|---|---|
| Local request tag | Identifies the host operation; keep it distinct from any device identifier. |
| Connection or session identity | Separates operations before and after a restart or reconnection. |
| Command-created and transmit-event times | Show host scheduling. Document the actual boundary observed by the serial API or instrument. |
| Complete-response time | Records when the parser has a complete report; transport may already have added delay. |
| Matching evidence | Records the documented identifier or the controlled request sequence used for association. |
| Final disposition | Distinguishes accepted, unusable, malformed, expired and ambiguous results. |
Use a consistent monotonic clock for elapsed host intervals. If device timestamps exist, keep their time base and reset behavior explicit. Do not compare clocks as though they were synchronized simply because both report numbers in milliseconds.
Give one component ownership of the request
A single request manager should own the pending operation, its deadline and its final disposition. This prevents a display task and a logging task from independently sending commands and claiming the same response.
If the protocol has no unambiguous transaction identifier, limiting the host to one pending measurement can reduce association problems. It is not sufficient by itself: the link must also begin in a known state, and the firmware’s command and response behavior must be understood.
Keep the state transitions explicit. A ready host may issue a request and enter a pending state. A response must pass the documented frame and measurement checks, then satisfy the association rule, before that request is completed. An unusable response may still complete a transaction if the protocol defines it that way. A malformed fragment is not a completed measurement.
A timeout does not cancel an optical measurement
A host deadline means the application has stopped waiting. It does not establish that the sensor stopped working, discarded its result or emptied the communication path. An old response may still arrive after the host starts another operation.
This is the dangerous sequence: request A expires, request B begins, and an untagged reply arrives. Treating that reply as B merely because B is now pending can attach an old distance to a new event. A local request counter cannot resolve information that the response does not contain.
Define a recovery boundary using the delivered protocol. It may involve a documented cancellation, completion indication or reinitialization procedure. Do not invent a universal delay or assume that clearing the host buffer prevents a later device response. If the available documentation cannot establish a reliable boundary, preserve the ambiguity and obtain a written interface clarification before relying on the association.
Replay the failure paths before connecting the application
Use an isolated parser and request-manager harness with recorded or constructed events. The following are proposed software checks, not measurements of a module’s response time.
| Replay | Expected host behavior |
|---|---|
| Normal documented response | Complete the matching request once and retain the matching evidence. |
| Response after the request expired | Record it as late; do not silently attach it to a newer request. |
| Repeated delivery | Apply the documented identification rule. Equal distance values alone do not prove duplication. |
| Restart while pending | Invalidate the old host operation and follow the documented recovery procedure. |
| Partial or malformed response | Preserve parser state as appropriate; do not publish a distance from incomplete data. |
Then repeat the relevant cases with the actual host, adapter, cable and firmware. Record unexpected replies and unresolved behavior instead of tuning them away with a longer timeout.
The existing receive-gap alarm note separates byte activity, checked reports and usable values. Request association adds a different question: which operation owns the result?
Review the ERDILRF module catalog, or send the model, protocol revision, operating mode and a short annotated trace for an interface review. Hardware triggers, device timestamps and transaction identifiers require model-specific confirmation.