PLCと視覚装置のハンドシェイクを状態機械で定義する

課題と前提条件

短いトリガーパルスや未確認の結果は、部品の見落としや旧判定の再利用を招きます。実信号や産業プロトコルに対応させる前に状態動作を合意します。付録は概念的な疑似コードです。

試験の準備

準備、処理中、結果、異常に部品識別子と一致確認を加えます。処理期限200ms、確認待ち500msは仮定で、本番値は設備時間予算から定めます。

デジタルI/Oや通信へ割り当てる前にアプリ契約を書きます。要求識別の生成側、状態責任、完了応答、異常中の実部品処置を定めます。Ready、Busy、Result、Faultは概念状態で、レジスター名や通信命令の約束ではありません。選ぶ装置のトリガー・結果仕様を確認し、電気・ネットワーク時間と検査時間を分けます。実インターフェースに取引識別がなければ対応方法を設計・検討し、次結果が次部品だと仮定しません。記録や適切な信号測定で実交換を観測します。

作業手順

1. 準備状態でだけ要求を受け、処理中にする前に識別子を保持します。
2. 取得と判定後、識別子と結果を同時に公開し固定します。
3. 同じ結果への確認後だけ準備に戻し、異なる識別子の確認を拒否します。
4. 処理期限や取得異常では異常を出し、古いOKを最新と表示しません。
5. 処理中要求、重複、確認消失、再始動を試し、明示復旧を要求します。

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

Readyは有効な一要求の識別を取得前に確立します。Busyは識別を維持し、後続を合意設計で拒否または待機させ、黙って置き換えません。完了時は判定と識別を一緒に出し、対応応答まで保持します。他識別の応答で結果を消しません。期限、取得失敗、不正データは定義したFaultへ移り、旧合格を無効にします。実部品処置を解決する許可復旧後だけReadyへ戻ります。工程連携であり独立した機械・ロボット安全制御の代用ではありません。

仮定に基づく試験記録

以下は説明用の仮定であり、Deyiの実測結果ではありません。実際に承認した試験記録に置き換えてください。

T300の結果と識別子を、対応する確認応答か定義した異常遷移まで保持します。Busy中の二つ目の要求、T299への確認応答、期限後の完了、制御機器再起動を試し、それぞれの状態と実部品の処置を記録します。旧タイマーを解除するか世代を確認し、T300の期限切れで後続要求が異常にならないようにします。付録は動作概念であり、実信号と電文は選んだ制御プロトコルで設計します。

各タイマーに責任、開始境界、要求世代を付けます。仮の処理・応答期限は違う待機を試すもので推奨設定ではありません。状態を離れる時に解除するか、満了時に識別と世代を確認します。失敗・置換後の遅い完了は診断として残し、結果にしません。応答喪失と検査失敗を分けます。判定が有効でも取引は未解決の場合があります。安定結果の再送、部品保留、作業者照合のどれかを定めます。通信復旧だけでは前部品を解決しません。

工程を示す二つの図

トラブルの切り分け

• 受信側が観測できない短いパルスは信号設計を見直します。
• 異なる確認識別子は順序・待ち行列を調査します。
• 異常の自動解除で未検査品が隠れないよう処置を定義します。

受入確認と引き継ぎ

全要求が上書きなしの最終状態に至ることを追跡し、両側の期限、リセット、停電を試します。200/500msは機器互換性の保証ではありません。

試験前に受入基準を定め、元の証拠を保存してください。本例は供給対象モデルの機能を保証するものではありません。

先に作る予定状態表で正常、Busy中の次要求、誤応答、二重応答、欠落画像、遅延完了、通信断、再起動を試します。状態、識別、結果、実処置を仕様と比較します。再起動で旧合格が新判定にならないことを確認します。境界付近の異常で旧タイマーと競合を試し、正常交換も再確認します。定義、期限、記録、承認復旧、実信号割当を渡します。中立付録は選ぶ装置との実装検討が必要で、実行PLC命令やDeyi通信機能を示しません。

関連資料

機器を選定する前に、関連する選定・用途別ガイドを参照してください。技術検討には、サンプル画像、必要な判定、運転条件、試験記録を用意してください。