EAN-13: duplicados y lecturas ausentes

Objetivo y límites de uso

Distinga recaptura o reenvío del mismo objeto de productos idénticos y conserve cada no-read.

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

Prepare unidades consecutivas con igual código y replay; defina evento físico independiente del payload. Escriba un registro reproducible con fuente, región, salida real, decisión esperada y primera divergencia. Indique si ocurre en reproducción, captura real o ambas. Tras corregir, repita el fallo y condiciones vecinas antes satisfactorias. Excluir la región o aceptar un resultado ausente cambia el requisito, no resuelve la causa. Si persiste, mantenga Review o bloqueo con motivo, sin presentar una alternativa no probada como validada. Separe los registros de decodificación, validación de identidad, verificación de impresión y seguimiento unitario. EAN-13 identifica un artículo comercial y normalmente se comparte entre unidades físicas; no es un número de fotograma ni un serial único. Decodificar no demuestra conformidad de impresión, datos maestros correctos ni rechazo posterior realizado. La serie limita el ejemplo a EAN-13, alcance confirmado de la evaluación pública de PC. Otras simbologías, QR, marcado directo y lectores físicos necesitan integración confirmada por separado. El original debe conservar barras, espacios y zonas silenciosas; un recorte o binario limpio no basta como prueba de fallo. Distinga fotograma ausente y código ilegible en la base de trazabilidad. Diagnostique desde la primera divergencia observable. Reproduzca la misma fuente guardada con referencia y candidato sin cambios; compare imágenes intermedias, regiones, valores y estados. Si cambia la fuente, ya no se aísla el algoritmo. Modifique una sola causa sospechosa, anote antes el efecto esperado y conserve el resultado negativo cuando falle la hipótesis. Separe evidencia ilegible, desacuerdo de regla, dependencias ausentes y fallo de ejecución: requieren remedios distintos. La reproducción puede demostrar un fallo de software, pero no validar disparo real, sincronización de luz ni rechazo físico. Mantenga esas pruebas de adquisición y línea como experimentos posteriores independientes.

Procedimiento

1. Compare ID y evento antes de eliminar textos repetidos.
2. Separe no-read, imagen ausente y dato inválido, inspeccionando cada original.
3. Reenvíe una captura para probar recepción idempotente; después envíe capturas distintas con mismo código.
4. Pruebe reinicio y orden por evento; no elimine unidades solo por EAN-13 idéntico.

Interpretar el ensayo

Ejemplo: 4 eventos distintos con igual EAN-13 requieren 4 registros. Reenviar 1 captura requiere 1 registro de unidad más historial de recepción. EAN-13 identifica un artículo comercial, no necesariamente serial individual.

Hoja de registro

Dos vistas de ingeniería

Diagnóstico de fallos

• Contar cadenas únicas oculta productos iguales legítimos.
• Usar lectura anterior para imagen ausente inventa trazabilidad.

Aceptación y entrega

Acepte un registro terminal por unidad esperada y ningún objeto extra por replay. Reconcilie triggers, imágenes, no-reads y resultados sin quitar fallos.

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.