Etiquetas OCR: aceptación y contrato PLC

Objetivo y límites de uso

Entregue veredicto por campo con texto trazable y plazo, separando texto incorrecto, ilegible y fallo de comunicación.

Este tutorial describe una evaluación de ingeniería, no una certificación de producto listo para funcionar. El ejemplo público actual de PC de Deyi Vision cubre un flujo EAN-13 con imágenes de muestra confirmadas. Antes de utilizar OCR o detección nativos del código de ingeniería, compruebe el entorno instalado, los modelos vinculados y el trabajo. Una plantilla de navegador no demuestra ejecución en él: el backend OpenCV.js previsto requiere verificación independiente. El reconocimiento en la nube exige aprobar expresamente las imágenes, el proveedor, el modelo y el coste. Un archivo de revisión no es un paquete ejecutable de publicación. Verifique por separado la compatibilidad de cámara, firmware y controlador. Todos los valores de la hoja son hipotéticos; no son mediciones ni resultados de clientes de Deyi Vision.

Preparar las pruebas

Congele campos, fuente de lote, normalización y paquete; pruebe salida simulada antes de etiquetas supervisadas. Defina el instante inicial del plazo y el acuse que demuestra finalización. Guarde colas y comunicaciones junto al procesamiento para no ocultar resultados tardíos con un algoritmo rápido. Use reloj monotónico para intervalos y documente correspondencia entre relojes de equipos. Registre colas largas, ausencias y reconexión, no solo la media. Una nueva receta no debe reinterpretar resultados pendientes: termine con la revisión registrada o aplique bloqueo acordado. Relacione salida, posición y confirmación, separando clasificación, comunicación y encaminamiento físico. La verificación OCR de etiquetas protege la integridad de datos, no busca palabras plausibles. Defina cada campo, ubicación, alfabeto permitido, política exacta de comparación y fuente fiable del valor esperado. Lote, fecha y nombre pueden requerir reglas diferentes. Guarde polígono de detección y salida reconocida antes de normalizar espacios o mayúsculas. No sustituya silenciosamente I por 1 ni O por 0: podría aprobar una etiqueta equivocada. La evidencia técnica original incluye un caso OCR estrecho que devuelve NoResult o Review; ampliar el recorte no demuestra disponibilidad general. Un campo legible puede contener un lote incorrecto, y conocer el valor esperado no autoriza a rellenar un campo ilegible. Escriba el contrato de línea antes de conectar el veredicto al actuador. Defina identidad de adquisición, revisión de receta, estado, plazo, acuse y tratamiento de datos ausentes o tardíos. Pruebe el protocolo con salidas bloqueadas y después haga un ensayo supervisado según la aceptación de planta. Mida desde el mismo evento definido en cada ejecución; el tiempo de proceso omite colas, transferencia y retardo de salida. Un identificador de producto repetido no identifica de forma única un fotograma. Pruebe parada, reinicio, reconexión y cambio de receta con trabajos pendientes. Conserve la secuencia completa para relacionar la pieza rechazada con las pruebas que motivaron la acción.

Procedimiento

1. Defina coincidencia, discrepancia, Review, NoResult o error por campo antes de agregar.
2. Envíe captura, revisión y motivo; un acierto tardío no reemplaza timeout.
3. Inyecte campos ausentes, lote errado, runtime ausente y reinicio pendiente; confirme bloqueo.
4. Compare presupuesto con captura-a-acuse real y verifique disposición física.

Interpretar el ensayo

Presupuesto hipotético: OCR 55 ms, reglas 5 ms y comunicación 5 ms, total 65 ms ante 80 ms y reserva 15 ms. No mide velocidad OCR. Texto correcto fuera de plazo sigue tardío.

Hoja de registro

T = 55 + 5 + 5 = 65 ms
M = 80 - 65 = 15 ms

Dos vistas de ingeniería

Diagnóstico de fallos

• Bueno global sin campos puede ocultar fecha o lote ilegibles.
• Un acuse de otra captura no confirma esta etiqueta.

Aceptación y entrega

Acepte integridad de campos, datos, fallos y acuse por separado; registre hardware y modelos reales.

Conserve juntos imágenes originales, decisión esperada, revisión exacta y registro completo. Congele el conjunto de evaluación antes de elegir los parámetros finales. Si después utiliza sus respuestas para ajustar el flujo, márquelo como datos de desarrollo y obtenga otro conjunto independiente de aceptación. Mantenga Review, NoResult, error de ejecución y adquisición ausente en el denominador; no los convierta en aprobaciones filtrando filas. Guarde un fallo reproducible junto al caso satisfactorio. La entrega debe identificar quién puede cambiar la receta, cómo restaurar una revisión aprobada y qué salida del equipo seguirá bloqueada hasta la aceptación. Un resultado de software no demuestra que una pieza en movimiento haya llegado al destino correcto.