명확한 상태로 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 기능이 아닙니다.

관련 자료

장비 선정 전에 연결된 선정 및 적용 가이드를 읽으십시오. 기술 검토에는 시료 이미지, 필요한 판정, 운전 조건과 시험 기록을 준비하십시오.