Definir el enlace PLC–visión mediante estados explícitos

Problema y condiciones previas

Un disparo breve y un resultado sin confirmar pueden perder piezas o reutilizar decisiones. Acuerde estados antes de asignar señales eléctricas o protocolos reales. El anexo es pseudocódigo conceptual.

Preparación de la prueba

Defina listo, ocupado, resultado y fallo con identificador y confirmación coincidente. Los plazos 200 ms de procesamiento y 500 ms de confirmación son supuestos; calcule límites reales.

Escriba contrato antes de asignar I/O o protocolo. Defina identidad, dueño de estados, confirmación y destino físico en fallo. Ready, Busy, Result y Fault son conceptos, no registros ni comandos prometidos. Revise interfaces y separe tiempos eléctricos o red de inspección. Sin identidad transaccional diseñe asociación revisada, sin suponer siguiente resultado para siguiente pieza. Observe trazas o señales.

Procedimiento

1. Admita solicitudes solo estando listo y guarde identidad antes de pasar a ocupado.
2. Publique identificador y resultado juntos y manténgalos estables.
3. Vuelva a listo solo con confirmación de ese resultado; rechace identificadores distintos.
4. Ante plazo vencido o fallo de captura, publique fallo sin presentar un OK antiguo como actual.
5. Pruebe solicitudes estando ocupado, duplicados, confirmación perdida y reinicio con recuperación deliberada.

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 acepta una petición y fija identidad antes de capturar. Busy la mantiene y rechaza o encola nuevas según diseño, sin sustituir. Publique resultado e identidad estables hasta confirmación correcta. Otra identidad no borra. Timeout, adquisición o datos inválidos pasan a Fault e invalidan un aprobado anterior. Ready vuelve tras recuperación autorizada con destino de pieza resuelto. La coordinación no sustituye control de seguridad independiente.

Registro de prueba ilustrativo

Supuestos ilustrativos, no resultados medidos por Deyi. Sustituya los valores por sus propios registros de prueba aprobados.

Mantenga resultado e identificador de T300 hasta la confirmación correspondiente o una transición de fallo definida. Pruebe una segunda petición durante Busy, una confirmación de T299, una finalización tras el plazo y un reinicio del controlador. Registre estado y destino físico de la pieza. Cancele o valide la generación de temporizadores antiguos para que T300 no afecte a otra petición. El apéndice describe conducta; las señales y tramas requieren el protocolo del controlador elegido.

Cada temporizador tiene dueño, inicio y generación. Los plazos ilustrativos prueban esperas distintas, no son recomendación. Cancele al salir o compruebe identidad/generación al vencer. Una finalización tardía tras fallo o sustitución queda diagnóstica. Separe pérdida de confirmación e inspección fallida: decisión válida puede quedar sin cerrar. Defina reenvío estable, contención o conciliación. Recuperar red no resuelve la transacción anterior.

Dos vistas del proceso

Diagnóstico de fallos

• Pulsos demasiado breves requieren rediseño de señales o protocolo.
• Una confirmación ajena indica fallo de cola o secuencia.
• Borrar automáticamente el fallo puede ocultar una pieza sin inspeccionar.

Aceptación y entrega

Trace cada solicitud hasta un resultado terminal sin sobrescritura. Pruebe plazos, restablecimiento y corte eléctrico en ambos extremos. 200/500 ms no acredita compatibilidad.

Defina los límites de aceptación antes del ensayo y conserve las evidencias originales. Los ejemplos no acreditan las prestaciones de un modelo suministrado.

Valide tabla esperada: normal, petición durante Busy, confirmación errónea, duplicada, sin imagen, tardía, desconexión y reinicio. Compare estado, identidad, resultado y destino. Reiniciar no convierte aprobado antiguo en nuevo. Pruebe fronteras para temporizadores y carreras y repita normal. Entregue estados, plazos, trazas, recuperación y mapeo real. Apéndice neutral requiere revisión por dispositivo; no es instrucción PLC ni función Deyi.

Lecturas relacionadas

Consulte las guías de selección y aplicación enlazadas antes de elegir equipos. Para una revisión técnica, prepare imágenes de muestra, el resultado requerido, las condiciones de operación y el registro de prueba.