Software & Integration

EAN-13: Abnahme an der Linie

Barcodeereignis bis zur richtigen physischen Route verfolgen, samt No-read, Verspätung und fehlender Quittierung.

Muster zur technischen Bewertung senden
EAN-13: Abnahme an der Linie — Schematische technische Darstellung; kein Foto und kein Messergebnis.
Schematische technische Darstellung; kein Foto und kein Messergebnis.

Ziel und Einsatzgrenzen

Barcodeereignis bis zur richtigen physischen Route verfolgen, samt No-read, Verspätung und fehlender Quittierung.

Diese Anleitung beschreibt eine technische Bewertung, keine Zertifizierung eines sofort einsatzbereiten Produkts. Das öffentliche PC-Beispiel von Deyi Vision umfasst derzeit einen EAN-13-Ablauf mit bestätigten Musterbildern. Native OCR- und Detektionsfunktionen im Entwicklungscode sind vor Verwendung anhand der installierten Laufzeit, gebundenen Modelle und Prüfaufgabe zu kontrollieren. Eine Browser-Vorlage belegt keine Ausführung im Browser; das geplante OpenCV.js-Backend benötigt eine eigene Prüfung. Cloud-Erkennung erfordert die ausdrückliche Freigabe von Bildumfang, Anbieter, Modell und Kosten. Ein Prüfarchiv ist kein ausführbares Release-Paket. Kamera-, Firmware- und Treiberkompatibilität sind separat zu prüfen. Alle Werte im Arbeitsblatt sind hypothetisch, keine Messungen oder Kundenergebnisse von Deyi Vision.

Nachweise vorbereiten

Leserumfang, Encoderkonvention, Ereignis-ID und Stammdaten einfrieren; gesperrte Ausgänge vor überwachten Fördertests prüfen. Definieren Sie Startzeit und bestätigende Quittierung. Warteschlange und Kommunikationsverzug neben Verarbeitung sichern; ein schneller Algorithmus kann ein spätes Linienergebnis verdecken. Intervalle monoton messen und Geräteuhren separat zuordnen. Lange Verzögerungen, fehlende Ergebnisse und Wiederverbindung statt nur Mittelwert erfassen. Neues Rezept darf laufende Ergebnisse nicht umdeuten: unter gespeicherter Revision beenden oder vereinbart sperren. Ausgangsfolge, Produktposition und Bestätigung zusammenhalten. Klassifikation, Kommunikation und bestätigte physische Route getrennt abnehmen. Dekodierung, Identitätsprüfung, Druckverifikation und Einzelteilverfolgung getrennt protokollieren. Der EAN-13-Wert kennzeichnet einen Handelsartikel und ist gewöhnlich bei mehreren Einheiten gleich; er ist weder Bildfolgenummer noch eindeutige Seriennummer. Erfolgreiches Lesen beweist keine Druckqualität, richtige Stammdaten oder ausgeführte Ausschleusung. Diese Reihe verwendet EAN-13 als begrenztes Beispiel entsprechend dem bestätigten öffentlichen PC-Bewertungsumfang. Andere Symboliken, QR, Direktmarkierungen und Lesegeräte benötigen eine separat bestätigte Integration. Das Quellbild muss Balken, Lücken und Hellzonen enthalten; ein Ausschnitt oder bereinigtes Binärbild allein reicht nicht als Fehlernachweis. Fehlendes Bild und unlesbarer Code sind im Rückverfolgungsdatensatz unterschiedlich zu behandeln. Den Linienvertrag vor der Verbindung von Entscheidung und Aktor festlegen: Aufnahmeidentität, Rezeptrevision, Ergebniszustand, Frist, Quittierung und Umgang mit fehlenden oder verspäteten Daten. Zuerst die Kommunikation bei gesperrten Ausgängen prüfen, dann einen überwachten Linienversuch gemäß betrieblichem Abnahmeverfahren durchführen. Jeden Lauf vom gleichen definierten Ereignis messen; reine Rechenzeit lässt Warteschlange, Übertragung und Ausgangsverzögerung aus. Eine wiederkehrende Produktkennung ist keine eindeutige Bildkennung. Stopp, Neustart, Wiederverbindung und Rezeptwechsel mit offenen Vorgängen prüfen. Die gesamte Folge sichern, damit die ausgeschleuste Einheit zu ihren Entscheidungsbelegen zurückverfolgbar bleibt.

Vorgehen

  1. Aufnahmeposition zur Frist abbilden, mechanischen Schutzabstand ausdrücklich halten.
  2. Ereignis, Wert/No-read-Grund und Revision senden; gleiches Ereignis vor Abschluss quittieren.
  3. Bildverlust, Wiederholung, Verspätung und Restart mit Teilen prüfen, vereinbarte Fehlerroute bestätigen.
  4. Entscheidung mit Encoder und beobachteter Route abgleichen; App-Empfang ist keine Ausschleusbestätigung.

Versuch auswerten

Hypothetisch 0.6 m bei 1.2 m/s ergeben 500 ms. Entscheidung 80 ms und Schutz 40 ms lassen 380 ms. Budget, keine gemessene Leserleistung oder Aktorbereitschaft. Schlupf, Transport und Queue real messen.

Versuchsprotokoll

Hypothetisches Arbeitsblatt; Entwurfsbeispiele, keine gemessene Leistung.
EintragWert / BeobachtungAuswertung
Strecke / Geschwindigkeit0.6 m / 1.2 m/sFahrt = 500 ms
Entscheidung / Schutz80 ms / 40 msReserve = 380 ms; hypothetisch
travel = 0.6 / 1.2 = 0.5 s = 500 ms
margin = 500 - 80 - 40 = 380 ms

Zwei technische Ansichten

Zwei technische Ansichten · 1

Die Grafik zeigt die Prüfreihenfolge. Jeder Pfeil benötigt protokollierte Nachweise und bedeutet keine implementierte automatische Verbindung. Aufnahme → Entscheidung → Quittierung → Physische Route.

  1. Aufnahme
  2. Entscheidung
  3. Quittierung
  4. Physische Route
Schematische technische Darstellung; kein Foto und kein Messergebnis.
Diagramm in voller Größe anzeigen

Zwei technische Ansichten · 2

Die Grafik zeigt die Prüfreihenfolge. Jeder Pfeil benötigt protokollierte Nachweise und bedeutet keine implementierte automatische Verbindung. Normal → Fehlend → Verspätet → Gesperrt.

  1. Normal
  2. Fehlend
  3. Verspätet
  4. Gesperrt
Schematische technische Darstellung; kein Foto und kein Messergebnis.
Diagramm in voller Größe anzeigen

Fehler eingrenzen

  • Richtiger Wert am nächsten Teil bleibt Rückverfolgungsfehler.
  • Zeitgesteuertes Ausschleusen ohne Position kann bei Verlangsamung scheitern; Transportmodell validieren.

Abnahme und Übergabe

Vollständigkeit, Zuordnung, Frist und physische Route getrennt abnehmen. Offene No-read/Fehler zeigen und beobachtetes Linienprotokoll vor Produktionsfreigabe behalten.

Quellbilder, erwartete Entscheidung, genaue Revision und vollständigen Ergebnisdatensatz gemeinsam aufbewahren. Den Bewertungssatz vor der endgültigen Parameterwahl einfrieren. Werden seine Antworten später zum Einstellen verwendet, diesen Satz als Entwicklungsdaten kennzeichnen und einen neuen unabhängigen Abnahmesatz beschaffen. Review, NoResult, Ausführungsfehler und fehlende Aufnahme bleiben im Nenner sichtbar; durch Zeilenfilterung werden sie nicht zu bestandenen Prüfungen. Einen reproduzierbaren Fehler zusammen mit dem erfolgreichen Muster sichern. Die Übergabe benennt Änderungsberechtigte, die Wiederherstellung einer früher freigegebenen Revision und den bis zur Abnahme gesperrten Geräteausgang. Ein Softwareergebnis beweist nicht, dass ein bewegtes Werkstück sein richtiges Ziel erreicht hat.

Quellen und technische Referenzen

Die Quellen erläutern Methoden und Grenzen dieser Anleitung. Beispielprüfungen dienen der Orientierung; die Produktionsabnahme benötigt Belege aus Ihren eigenen Mustern.

  1. Deyi Vision machine vision software: evaluation scopeDeyi VisionGeprüft
  2. Build a PLC–vision handshake with explicit statesDeyi VisionGeprüft
  3. Load-test latency from trigger to PLC decisionDeyi VisionGeprüft
  4. Track barcode results to the correct conveyor rejectDeyi VisionGeprüft
  5. Decoding versus barcode verification: design the right testDeyi VisionGeprüft

Technische Bewertung

Prüfproblem und Bildbelege gemeinsam besprechen.

Senden Sie Musterbilder, den aktuellen Aufbau und den fehlgeschlagenen Prüfschritt. Sichtfeld, Arbeitsabstand, Liniengeschwindigkeit und Abnahmekriterien erleichtern die technische Bewertung.

Muster zur technischen Bewertung senden
Kontakt

Direkter RFQ-Kontakt

Mit einem Techniker über die Prüfaufgabe sprechen.

Teilen Sie Bauteil, Referenzmodell, Sichtfeld, Abstand und Taktzeit.

Ziel: Auswahlbrief innerhalb von 24h
Musterbilder prüfen lassen