Build a PLC–vision handshake with explicit states

Problem and prerequisites

A short trigger pulse and an unacknowledged result can lose parts or reuse old decisions. Agree state behavior before mapping it to the actual electrical signals or industrial protocol. The appendix is conceptual pseudocode, not wire commands.

Prepare the test

Define Ready, Busy, Result and Fault plus a part identifier and matching acknowledgement. Assume a 200 ms processing deadline and 500 ms acknowledgement timeout for this example; obtain real limits from the station budget.

Write the handshake as an application contract before mapping it to digital I/O or a network protocol. Define which controller creates the request identity, which side owns each state, how completion is acknowledged and how physical part disposition is retained during a fault. Ready, Busy, Result and Fault are conceptual states here, not promised register names or protocol commands. Confirm the selected devices’ supported trigger and result interfaces in their manuals. Record electrical or network timing separately from inspection timing. If the physical interface has no transaction identifier, design and review an association method rather than assuming that the next result always belongs to the next part. Use controller traces or suitable signal measurement to observe the actual exchange.

Procedure

1. Permit a new request only while Ready and bind its identifier before setting Busy.
2. Complete acquisition and inspection; publish the identifier and result together, keeping them stable.
3. Return to Ready only after acknowledgement of that same result; reject mismatched acknowledgements.
4. On processing timeout or acquisition fault, publish Fault and prevent an old OK from appearing current.
5. Test a request while Busy, duplicate requests, lost acknowledgement and restart; require deliberate recovery.

VENDOR-NEUTRAL PSEUDOCODE — state semantics, not protocol commands
# Serialize these application events; names below are conceptual.
state = READY
generation = new_generation()
active_token = none
on_request(id):
    if state != READY: record_rejected_request(id); return
    active_token = (generation, id)
    state = BUSY
    arm_processing_deadline(active_token)
    start_bounded_inspection(active_token)
on_completed(token, value):
    if state != BUSY or token != active_token:
        record_stale_result(token); return
    cancel_processing_deadline(token)
    if not application_payload_valid(value):
        enter_fault(token, INVALID_PAYLOAD); return
    publish_stable_result(token, value)
    state = RESULT
    arm_acknowledgement_deadline(token)
on_acknowledge(token):
    if state != RESULT or token != active_token:
        record_unmatched_acknowledgement(token); return
    cancel_acknowledgement_deadline(token)
    clear_published_result()
    active_token = none
    state = READY
on_timeout(token, expected_state):
    if token != active_token or state != expected_state:
        record_stale_timer(token); return
    enter_fault(token, TIMEOUT)
on_acquisition_failure(token):
    if state == BUSY and token == active_token:
        enter_fault(token, ACQUISITION_FAILURE)
enter_fault(token, reason):
    cancel_all_deadlines(token)
    invalidate_pass_result()
    record_fault_and_pending_part(token, reason)
    state = FAULT
on_authorized_recovery:
    if state != FAULT: return
    resolve_part_disposition()
    stop_pending_work_and_clear_events()
    generation = new_generation()
    active_token = none
    state = READY

In Ready, accept one valid request and bind the active identity before starting acquisition. In Busy, keep that identity stable and explicitly reject or queue further requests according to the agreed design; do not silently replace it. At completion, publish the decision and identity together and retain them until matching acknowledgement. Ignore an acknowledgement for another identity without clearing the current result. A timeout, acquisition failure or invalid payload follows the defined Fault transition and invalidates any previously published pass. Require an authorized recovery action that resolves the affected physical part before returning to Ready. This is functional process coordination; it is not a substitute for the robot or machine’s independent safety control.

Illustrative test record

Illustrative assumptions, not measured Deyi performance. Replace these values with your own signed test records.

For T300, hold the result and its identifier stable until the matching acknowledgement or a defined fault transition. Send a second request while Busy, an acknowledgement for T299, a delayed completion after timeout and a controller restart. Record the resulting state and physical part disposition for each case. Cancel or generation-check old timers so that an expired T300 timer cannot fault a later request. The appendix describes behavior; actual signals and framing require the selected controller protocol.

Give every timeout an owner, start boundary and associated request generation. The illustrative processing and acknowledgement deadlines test different waits; they are not interchangeable and are not recommended device settings. Cancel timers when their state is left, or verify identity and generation before handling expiration. Record a late completion as diagnostic evidence but do not let it publish after the request has faulted or been replaced. Keep acknowledgement loss separate from inspection failure: the part may already have a valid decision while the transaction remains unresolved. Define whether recovery resends a stable result, contains the part or requires operator reconciliation. Use the documented transport’s reconnect behavior; a network connection becoming healthy does not automatically reconcile the previous part transaction.

Two views of the workflow

Troubleshooting

• A pulse shorter than the receiver can observe requires a protocol or signal redesign.
• Acknowledging a different identifier indicates queue or sequencing failure.
• Automatic clearing of Fault can hide an uninspected part; define recovery and disposition explicitly.

Acceptance and handover

Trace every requested part through one terminal outcome without silent overwrite. Verify timeout and reset behavior on both ends, including loss of power. The 200/500 ms values are assumptions, not compatible-device guarantees.

Set acceptance limits before testing and retain the original evidence. The examples here do not establish a supplied model’s capabilities.

Validate transitions using an expected state table prepared before the test. Include normal completion, another request during Busy, wrong acknowledgement, duplicate acknowledgement, missing image, late completion, lost connection and controller restart. For every case, compare observed state, active identity, stable result and physical disposition with the specification. Verify that a restart does not restore an old pass as a new decision. Test faults near a boundary to expose stale timers and result races, then repeat the accepted normal exchange. Handover includes state definitions, timer rules, trace records, approved recovery and the actual signal or protocol mapping. The neutral appendix requires implementation review against the chosen devices; its logical operation names are not executable PLC instructions or a claim of a Deyi communication feature.

Related reading

Read the related selection and application guides before choosing equipment. For an engineering review, provide sample images, the required result, operating conditions and the completed test record.