Integrazione della visione industriale per progetti di macchinari in Germania: acquisizione immagini, decisione difetti e collegamento PLC

L’integrazione della visione industriale dovrebbe separare tre responsabilità. Il livello di acquisizione crea immagini tracciabili con una configurazione ottica, una sorgente di trigger e una versione della fotocamera definite. Il livello decisionale utilizza una ricetta fissa e una versione dell'algoritmo per restituire PASS, FAIL o SCONOSCIUTO con un codice motivo. Il PLC, o un sistema di controllo di sicurezza revisionato, gestisce il flusso del pezzo, gli interblocchi e l'azione dell'attrezzatura finale. I tre livelli dovrebbero correlare trigger, frame_id, ricetta_versione, risultato e riconoscimento con lo stesso part_id o cycle_id invece di passare un bit buono/cattivo senza ambito.

Beijing Winge Technology Co., Ltd. fornisce servizi di visione artificiale, integrazione di telecamere industriali, algoritmi di rilevamento dei difetti e sviluppo di interfacce per apparecchiature con i nomi Winge Technology e Winge. Il seguente materiale supporta la definizione dell'ambito remoto per aziende tedesche o progetti di apparecchiature. Essa non sostiene che Winge abbia un ufficio tedesco, clienti tedeschi o progetti completati in Germania.

Effettuare la definizione di base del pezzo in lavorazione, dell'imaging, del trigger e del confine di controllo prima dello sviluppo

Fornire almeno il prodotto ispezionato e la revisione, le classi di difetti e i campioni di confine, il campo visivo e i dettagli minimi visibili, il tempo di ciclo della stazione, le condizioni di fotocamera/obiettivo/luce e di montaggio, l'SDK della fotocamera o la versione del livello di trasporto, la sorgente e i tempi di attivazione, la piattaforma di calcolo, il modello e il protocollo del PLC, la tabella dei segnali/indirizzi/tipo di dati, la proprietà di ripristino e interblocco, le regole di conservazione dei risultati e la definizione delle statistiche di accettazione. Se il progetto utilizza GenICam o GigE Vision, registrare i componenti e le versioni effettivi anziché considerare il nome di un protocollo come prova di compatibilità. OPC UA per Machine Vision può informare il modello per stati, ricette e risultati; l'adozione dipende ancora dal PLC di destinazione, dalla rete e dall'interfaccia di base del progetto.

Tabella di acquisizione, decisione e interfaccia PLC-handshake

Si tratta di un modello di responsabilità e record di accettazione neutrale rispetto alla piattaforma, non di dati misurati da un progetto tedesco e non di un requisito per un particolare marchio, algoritmo o protocollo di PLC. Sostituisci i nomi dei segnali e i criteri di superamento con l'attrezzatura target e la linea di base concordata.

Area di responsabilità	Campi che devono essere definiti come base	Campioni di accettazione e fallimento
Imaging e acquisizione di immagini	Versioni della fotocamera e dell'SDK/livello di trasporto, obiettivo e luce, campo visivo, distanza di lavoro, formato pixel, esposizione e guadagno, trigger hardware/software, frame_id, timestamp di acquisizione e stato della qualità dell'immagine [Identificatori esatti dell’interfaccia: frame_id]	Utilizzare campioni normali, sovraesposti, sottoesposti, sfocati, occlusi, con fotogramma vuoto, con fotogramma interrotto, con attivazione duplicata e con disconnessione della fotocamera; verificare l'acquisizione, i flag di qualità, i timeout e i record di ripristino
Prodotto, ricetta e base di riferimento dei difetti	ID_prodotto, versione_ricetta, regioni di ispezione, classi di difetti, dimensioni fisiche e condizioni di visibilità, campioni limite, regole PASSATO/FAIL/SCONOSCIUTO, proprietario della qualità e revisione delle regole approvate [Identificatori esatti dell’interfaccia: product_id, recipe_version, PASS, FAIL, UNKNOWN]	Campioni separati di sviluppo, messa a punto e accettazione indipendente; coprire variazioni accettabili, difetti definiti, confini contestati, nuovi lotti e selezione di ricette errate
Motore di decisione dei difetti	Versione e hash dell'algoritmo/modello, dimensione dell'input e preelaborazione, ROI, soglie, gate di qualità, codice risultato, codice motivo, punteggio opzionale e punto di ingresso di revisione umana [Identificatori esatti dell’interfaccia: result_code, reason_code]	In una versione fissa e in un set di test indipendente, rilevamento di record, falsa accettazione/rifiuto, mancati risultati, risultati SCONOSCIUTI e confusione per classe; non forzare immagini di bassa qualità o difetti invisibili in PASS
Handshake della stazione PLC	part_id/cycle_id, sequenza di richiesta o trigger, READY, BUSY, result_valid, result_code, ACK, RESET, timeout, nuovo tentativo, semantica bordo/livello, stato iniziale post-riavvio e base temporale [Identificatori esatti dell’interfaccia: part_id/cycle_id, READY, BUSY, result_valid, result_code, ACK, RESET]	Cicli normali di esercizio, trigger duplicati e mancanti, risultati tardivi, ACK perso, riavvio PLC/visione, modifica ricetta e ripristino timeout; dimostrare che ciascun risultato appartiene a una sola parte fisica
Disposizione, interblocchi e confine di sicurezza	Consumatore del risultato della visione, azione di rifiuto, ricattura/revisione SCONOSCIUTA, feedback dell'attuatore, bypass manuale, interblocchi di sicurezza, autorizzazioni e condizioni per entrare in uno stato sicuro	Scollegare la telecamera, la luce, la rete o il servizio dell'algoritmo e inserire un risultato non valido o un attuatore che non risponde; verificare che il PLC/controller di sicurezza segua la logica esaminata e che un singolo bit di visione non sia trattato come una funzione di sicurezza del personale o delle apparecchiature
Tracciabilità, distribuzione e versioni	part_id/cycle_id, frame_id, configurazione telecamera/luce, ricetta_versione, hash algoritmo, codici risultato e motivo, sequenza PLC, timestamp/fuso orario, conservazione immagine grezza/prova, versioni software e configurazione [Identificatori esatti dell’interfaccia: part_id/cycle_id, frame_id, recipe_version, result_code]	Ripercorrere una parte fisica attraverso trigger, frame, decisione, azione e revisione del PLC; verificare la coerenza dei record di tolleranza dell'orologio, spazio di archiviazione insufficiente, avvio a freddo, aggiornamento e rollback

Pacchetti di lavoro, risultati finali e accettazione

L'ambito ingegneristico può essere suddiviso in esperimenti di imaging e adattamento dell'acquisizione, campioni e regole di difetto, algoritmo e servizio decisionale, interfaccia PLC/stazione, tracciabilità dei risultati e operazioni di distribuzione. Una prima fase può fornire un registro di input-gap, un record di esperimenti di imaging, definizioni di difetti e campioni di confine, un dizionario segnali/dati, un diagramma dello stato di handshake, una matrice di test di fallimento e un prototipo end-to-end. I risultati finali dell'implementazione possono quindi includere l'applicazione concordata o il codice sorgente, modelli e ricette, tabelle di interfaccia, istruzioni di distribuzione e rollback, record di test e limitazioni note. Telecamere, obiettivi, luci, PLC, controlli di sicurezza, licenze di terze parti, lavoro in loco, diritti sul codice sorgente e periodi di manutenzione vengono trattati separatamente.

L'accettazione dovrebbe utilizzare campioni separati dai dati di sviluppo e messa a punto insieme ai tempi effettivi della stazione. Dovrebbe coprire cicli normali, limiti dei difetti, immagini di bassa qualità, trigger duplicati o mancanti, risultati tardivi, perdita di comunicazione, mancata corrispondenza delle ricette, spazio di archiviazione insufficiente, riavvio e rollback dei componenti. Il rilevamento, il falso rifiuto, gli errori, il tasso SCONOSCIUTO, il tempo di elaborazione, la latenza end-to-end, la durata della corsa e la tolleranza dell'orologio devono indicare il conteggio dei campioni, la revisione, le condizioni e il metodo statistico. Un passaggio dell'algoritmo offline non sostituisce un test a circuito chiuso con telecamera, PLC e pezzo fisico.

Condizioni linguistiche e di implementazione per un progetto tedesco

Per il passaggio a un progetto tedesco, confermare l'ambito del documento tedesco/inglese, la terminologia dell'interfaccia utente e dei difetti, i formati decimali/data/unità, il fuso orario del progetto, le versioni target di Windows/Linux e del software PLC/fotocamera e il confine tra integrazione remota, campioni spediti e lavoro in loco. La sicurezza delle macchine, la sicurezza informatica, la conservazione dei dati, la conformità del prodotto e i permessi del sito devono essere confermati dalle parti responsabili del progetto dalle attuali fonti primarie per l'effettiva attrezzatura, utilizzo e luogo di distribuzione. Questa pagina non fa alcuna ipotesi in merito alla normativa tedesca, alla certificazione, alle tasse, ai tempi di consegna della logistica o alle condizioni di supporto locale.

Domande frequenti

La telecamera dovrebbe essere attivata dal PLC, da un sensore o dall'applicazione di visione?

Non esiste una scelta universale. Selezionare un'autorità di attivazione dal metodo di arrivo parziale, dalla velocità di movimento, dai tempi di esposizione e dalla capacità della fotocamera, quindi definire la sequenza, il bordo, il rimbalzo, l'intervallo minimo, il timeout di acquisizione e la gestione dei duplicati. Chiunque lo inizi, usa cycle_id e frame_id per dimostrare che il telaio appartiene al pezzo corretto.

Il risultato di una visione può fermare direttamente la macchina o rifiutare un prodotto?

Per impostazione predefinita, un singolo bit visivo non dovrebbe fungere da funzione di sicurezza dell'apparecchiatura o del personale. Il sistema di visione dovrebbe fornire un risultato, una ragione e uno stato di validità a livello di ciclo. Il PLC o il sistema di controllo di sicurezza decide quindi se arrestare, rifiutare, riprendere o richiedere la revisione umana dai suoi interblocchi, feedback dell'attuatore, stato della macchina e logica di controllo rivista.

Quali campioni di guasto sono necessari oltre ai normali cicli PASS e FAIL?

Coprire almeno immagini vuote, sfocate, sovraesposte, sottoesposte e occluse; difetti invisibili e campioni limite; mancata corrispondenza della ricetta; trigger duplicati o mancanti; timeout dell'acquisizione e dell'algoritmo; risultati tardivi; ACK perso; perdita di comunicazione; riavvio di telecamere, PLC e servizi di visione; e spazio di archiviazione ridotto. Per ciascuno, specificare lo stato di visione previsto, l'azione del PLC, i campi registrati e la condizione di ripristino.

Servizi correlati, materiale del caso e fonti primarie

OPC UA per la visione artificiale, parte 1: rivedere l'ambito del modello di informazione per il controllo della visione artificiale, le ricette e i risultati scambiati con i PLC della stazione o altro software; questa pagina non lo considera un protocollo di progetto obbligatorio.

Download attuali di EMVA GenICam pubblici: verificare i componenti e le versioni pubbliche attuali; la telecamera di destinazione necessita ancora di test per il suo SDK, i nodi delle funzionalità, i formati dei pixel e la capacità di attivazione.

Sviluppo dell'integrazione del sistema di visione artificiale: revisione dell'acquisizione pubblicata da Winge, della decisione sui difetti, dell'interfaccia delle apparecchiature, della consegna e dell'ambito di accettazione (fonte cinese).

Caso di sviluppo di visione di assemblaggio basato su Atlas: utilizzare solo l'acquisizione USB/UVC pubblicata, l'immagine di riferimento, il ROI, la registrazione dei risultati e l'ambito di rollback; non deducono l'esperienza del progetto tedesco, la compatibilità arbitraria di telecamere/PLC o l'accettazione della linea di produzione completata (fonte cinese).

Utilizzare Contattare Winge per fornire campioni di prodotto e difetti, tempo di ciclo della stazione, configurazione di telecamera/luce/obiettivo, tempi di attivazione, tabella dei segnali PLC, ambiente di distribuzione, lingue di destinazione e condizioni di accettazione in modo che le lacune di input, la proprietà dell'interfaccia e il primo pacchetto di lavoro possano essere esaminati.