Applicazione per la lettura della temperatura

4.6 Temperatura

4.6.1 Applicazione per la lettura della temperatura

L’applicazione che segue fa inevitabilmente uso delle librerie fornite dal co- struttore per l’accesso ai registri delle telecamere e per l’instaurazione della connessione tramite l’interfaccia seriale delle stesse. Andiamo a descrivere velocemente come sono strutturati i driver delle telecamere. Per una tratta- zione esaustiva dell’argomento si rimanda al manuale CPADriverHelp fornito insieme alle librerie.

Figura 4.16: Estratto del manuale delle telecamere Basler L101k Il CPA driver package delle Basler camera link

I driver Camera Port Access (CPA) standardizzano l’accesso alle porte delle telecamere (registri interni). Il driver CPA non fa altro che selezionare una delle porte disponibili e leggere o scrivere dei parametri al loro interno.

I driver CPA permettono dunque, di settare la telecamera via software in modo automatico e integrato nelle proprie applicazioni. I modelli Ca- mera Link, in particolare, utilizzano un protocollo di comando binario già implementato all’interno dei driver. I driver CPA sono progettati per essere eseguiti su macchine che utilizzano un sistema operativo Microsoft della fa- miglia Win32 (Windows NT, WindowsXP, Windows Vista etc.). I linguaggi di programmazione supportati per la creazione del client sono essenzialmente C, C++ e Visual Basic. Per l’applicazione di cui è oggetto questo paragra- fo è stato utilizzato il C++. La CpaBase.dll è la parte più importante del

driver: contiene tutte le librerie di base per costruire le applicazioni uti- lizzanti le telecamere, in particolare le interfacce IPao, IPaoRegisterAccess, IPaoVBAccess and IIOFrame. Inoltre contiene anche l’implementazione di un PAO per l’accesso seriale secondo lo standard di comunicazione COMx. Il Component Object Model (noto con l’acronimo COM) è un’interfaccia per componenti software introdotta da Microsoft nel 1993. COM permette la comunicazione tra processi e la creazione dinamica di oggetti con qualsiasi linguaggio di programmazione che supporta questa tecnologia. Lo scopo del Component Object Model è quello di permettere la creazione di componenti software binari: sebbene sia stato creato avendo in mente il linguaggio C++, COM è neutrale rispetto al linguaggio di programmazione, cioè si può usare qualunque linguaggio di programmazione per usare componenti COM a runtime.

Concettualmente quindi, è un passo in avanti ulteriore rispetto alle librerie a collegamento dinamiche (DLL). Ogni oggetto COM deve essere unico all’interno del sistema, e viene usato attraverso interfacce software anche loro globalmente uniche. Per assicurare l’unicità, il programmatore che crea un nuovo oggetto COM crea un GUID per esso (un numero identificativo di 128 bit, generato casualmente e che è, quasi sicuramente, diverso da ogni altro GUID nel sistema) e un GUID per ciascuna delle interfacce che l’oggetto implementa; questi GUID vengono detti CLSID (class ID) se si riferiscono a un oggetto COM e IID (interface ID) se si riferiscono a un’interfaccia. Affinché sia possibile usare un oggetto COM, questo deve essere registrato in Windo- ws nel registro di sistema, vale a dire viene creata una voce nel registro che associa il CLSID del componente al file su disco che lo implementa fisica- mente, e a eventuali informazioni di configurazione. Quando un programma richiede un dato componente COM, fa riferimento al CLSID corrispondente:

Windows si occuper`a di trovare il file su disco (DLL o EXE) e caricare il codice necessario. Fatto questo, il programma chieder`a al componente appena creato l’accesso a una delle sue interfacce, usando l’IID di quella che gli serve.

Telecamere e PC possono comunicare in due modi:

• Tramite le porte standard di comunicazione seriale del PC. In tal caso anche se la telecamera `e collegata a un framegrabber che riceve i dati re- lativi alle immagini, i registri interni della telecamera vengono acceduti tramite l’interfaccia RS232 del PC, bypassando il framegrabber. • Tramite il framegrabber, alternando la lettura delle immagini a quella

dei registri.

Per ognuno dei due metodi di comunicazione si devono utilizzare interfacce differenti. Per tale motivo da qui in avanti faremo riferimento solo al primo metodo, che `e quello che abbiamo utilizzato. Riportiamo in figura4.17

lo schema per l’accesso alle telecamere tramite le porte COM standard del PC.

Il client, accede alla telecamera tramite un Port Access Object (PAO) che incapsula i dettagli della connessione alla telecamera in base al suo modello. Esistono due interfacce che consentono l’utilizzo del PAO:

IPao consente al client di inviare e ricevere blocchi di dati binari. Questa interfaccia `e sempre necessaria.

IPaoRegisterAccess abilita direttamente l’accesso ai registri delle telecamere utilizzando il protocollo binario della Basler. Questo protocollo `e utilizzato dalle Camera Link ed `e quindi necessario utilizzare questa interfaccia.

Figura 4.17: Schema dei driver utilizzati per la comunicazione seriale con le telecamere

Infine, prima di poter leggere e scrivere i registri, il PAO deve:

• enumerare tutte le Camera Port Names (CPN) di tutte le porte che possono essere accedute con il corrispondente PAO

• fare un binding tra il PAO e una di queste CPN • settare i parametri della porta

Poich´e conosciamo in anticipo il PAO da utilizzare (il modello delle telecamere `e noto) e le porte seriali (CPN) a cui sono collegate le telecamere (le porte COMx del PC) possiamo saltare la parte di enumerazione di tutte le CPN disponibili e passare direttamente al binding.

Alla fine, dopo aver effettuato tutte queste operazioni, l’ultima cosa da fare `e leggere effettivamente il registro che ci interessa:

1 // u s o l a I P a o R e g i s t e r A c c e s s I n t e r f a c e

2 I P a o R e g i s t e r A c c e s s P t r p t r P a o R e g i s t e r = p t r P a o ; 3 i f( p t r P a o R e g i s t e r != NULL) {

4 long tempReg = 1 1 2 ;

5 long tempLength = 1 ;

6 unsigned char ∗ pTemperature = new unsigned char[ tempLength ] ; 7

Ovviamente queste operazioni andranno ripetute per tutte le telecamere presenti e per tutte le volte che ci `e utile conoscere la temperatura.

I dettagli del protocollo binario per l’accesso ai registri sono presenti nel manuale. Riportiamo di seguito la pagina relativa al registro contenente il valore della temperatura, in figura 4.18

La lettura della temperatura

Per rendere pi`u snella l’operazione di lettura `e stato previsto un file di configurazione sul modello dei file di properties di Java che contiene coppie chiave/valore contenenti le seguenti informazioni:

• NUMTELECAMERE = 3 • T1 = COM3 • T2 = COM4 • T3 = COM7 • T4 = NULL • T5 = NULL • T6 = NULL

Nell’ordine si ha: il numero di telecamere attualmente presenti, e la porta seriale a cui sono collegate le telecamere. Conoscere queste informazioni (che sono note a priori) consente di non doverle ricavare automaticamente ogni volta provando ad accedere a tutte le porte seriali del calcolatore per trovare quelle realmente collegate alle telecamere.

Innanzitutto riportiamo il file di header con le librerie necessarie per la compilazione dell’applicazione. Oltre alle classiche librerie per le stringhe,

per la gestione degli stream di I/O, si notino le librerie windows.h per l’u- tilizzo del timer di windows. Le altre librerie, fanno parte del CPA Driver Package fornito dalla casa produttrice delle telecamere per il loro utilizzo. Tale package verrà analizzato in seguito. Un’altra osservazione, è riferita alla direttiva import: questa è usata per incorporare informazioni da una libreria dll. Il contenuto della libreria dinamica viene convertito in classi C++. In questo caso tali classi descriveranno le interfacce COM. Con la direttiva import, si creano dunque delle funzioni wrapper per i metodi dell’interfaccia contenuta nella libreria.

1 #pragma o n c e 2 3 #i n c l u d e <a s s e r t . h> 4 #i n c l u d e <s t d d e f . h> 5 #i n c l u d e <s t d i o . h> 6 #i n c l u d e <c o n i o . h> 7 #i n c l u d e <windows . h> 8 #i n c l u d e <t c h a r . h> 9 #i n c l u d e <s t d l i b . h> 10#i n c l u d e <s t r i n g . h> 11 12 // d e f i n i z i o n i d e l Component O b j e c t Model 13#i n c l u d e <o b j b a s e . h> 14 15 // i n t e r f a c c i a p e r l ’ u t i l i z z o d e l l e COM 16#i n c l u d e <a t l b a s e . h> 17 18 // i m p o r t o l a CpaBase . d l l 19#pragma warning( d i s a b l e : 4 1 9 2 ) 20#i m p o r t " C p a B a s e . d l l " n o n a m e s p a c e 21#pragma warning(d e f a u l t: 4 1 9 2 ) 22 23#d e f i n e UNICODE 1 24#d e f i n e UNICODE 1 25 26#d e f i n e SECOND 1 0 0 0 0 0 0 27 28#d e f i n e MAX TELECAMERE 6 29#d e f i n e CONFIG FILE " C : / / P r o g e t t o G I R C / / d a t a / / i n p u t . t x t " 30 31 s t r u c t q u a l i t a I m m a g i n e { 32 // v i e n e u s a t a d a l p r o c e s s o d i v i s i o n e 33 i n t l u c e ; 34 // v i e n e u s a t a d a l p r o c e s s o d i v i s i o n e 35 i n t a l l i n e a m e n t o ; 36 //−1 s e l a t e l e c a m e r a non r i s p o n d e , a l t r i m e n t i c o n t i e n e l a t e m p e r a t u r a i n C e l s i u s d e l l a t e l e c a m e r a 37 i n t t e m p e r a t u r a ;

38 } ; 39 40 41 typedef s t r u c t{ 42 // numero r e a l e d i t e l e c a m e r e p r e s e n t i 43 i n t NUM TELECAMERE; 44 // p o r t e s e r i a l i d e l l e t e l e c a m e r e

45 char T [MAX TELECAMERE ] [ 5 ] ; 46 } c o n f i g ;

48 // p a r a m e t r i d i c o n f i g u r a z i o n e ( i n i z i a l i z z a t i n e l main )

49 c o n f i g c ;

Per i parametri di configurazione presenti nel file si `e implementato un parser del file, che estrae i valori dei parametri e li fornisce all’applicazione nel formato corretto. Il codice completo verr`a riportato in appendice. Ri- portiamo quindi il codice della funzione per la lettura delle temperature delle tre telecamere presenti. Tale funzione si occupa di fare il bind del Pao alla porta, connettere la porta, usare l’interfaccia IPaoRegisterAccess del Pao per leggere il registro della temperatura delle Basler Camera Link, lo legge periodicamente e salva i valori della temperatura nella memoria condivisa.

1 2 i n t r e a d T e m p e r a t u r e (s t r u c t q u a l i t a I m m a g i n e ∗ pMemCondivisaQualitaImmagine ) { 3 4 // I n i t i a l i z z a l e COM 5 C o I n i t i a l i z e (NULL) ; 6 i n t n T e l e c a m e r a = 0 ; 7 8 // q u e s t e p a r e n t e s i a s s i c u r a n o c h e t u t t i i p u n t a t o r i s i a n o c a n c e l l a t i prima c h e l a c o U n i n i t i a l i z e venga c h i a m a t a 9 { 10 HRESULT h r ; 11 // i m p o s t o i p a r a m e t r i p e r l a c o n n e s s i o n e s e r i a l e RS232 12 C o m m S e t t i n g s t CommSettings ;

13 CommSettings . BaudRate = CPA BAUD 9600 ; 14 CommSettings . D a t a B i t s = CPA DATABITS 8 ; 15 CommSettings . P a r i t y = CPA PARITY NONE ; 16 CommSettings . S t o p B i t s = CPA STOPBITS 10 ; 17 CommSettings . Handshake = CPA HANDSHAKE NONE ; 18 CommSettings . TxQueueSize = 8 ;

19 CommSettings . RxQueueSize = 8 ; 20

21 //GESTIONE DEI PAO

22 t r y {

23 // Creo i l Pao

24 I P a o P t r p t r P a o ;

26 i f ( h r != S OK ) 27 { 28 p r i n t f (" F a i l e d t o c r e a t e P a o \ n ") ; 29 goto F i n n i s h ; 30 } 31 e l s e{ 32 p r i n t f (" P a o = % l s \ n ", (BSTR) ptrPao−>C a p t i o n ) ; 33 f o r(i n t i =0; i < c .NUM TELECAMERE; i ++){ 34 p r i n t f (" \ n C P N = % s ", c . T [ i ] ) ; 35 // f a c c i o i l b i n d t r a i l pao e l a p o r t a COM da l e g g e r e 36 ptrPao−>CameraPortName = c . T [ i ] ; 37 38 // p r o v o a c o n n e t t e r m i , f a l l i s c e s e l a p o r t a `e a p e r t a da a l t r e a p p l i c a z i o n i 39 t r y { 40 ptrPao−>Connected = t r u e ; 41 } 42 c a t c h ( c o m e r r o r e ) { 43 p r i n t f (" C o n n e c t i o n f a i l e d \ n ") ; 44 continue; 45 } 46 t r y { 47 // c o n f i g u r o l e p o r t e 48 ptrPao−>ReadTimeout = 1 0 0 0 ; 49 ptrPao−>WriteTimeout = 1 0 0 0 ; 50 ptrPao−>CommSettings = CommSettings ; 51 } 52 c a t c h ( c o m e r r o r e ) { 53 p r i n t f (" C o n f i g u r i n g t h e p o r t f a i l e d \ n ") ; 54 ptrPao−>Connected = f a l s e ; 55 continue; 56 }

Nella parte di codice precedente, la funzione imposta i parametri per la connessione tramite l’interfaccia seriale RS232, e inizializza la connessione tramite l’interfaccia imposta dal produttore. Dopo aver creato la connessione con la telecamera, si tratta di leggere il registro contenente il valore della temperatura, in questo caso `e il registro 112. Una volta impostato l’indirizzo del registro da leggere (112), la sua lunghezza in byte (1 byte), e la locazione di memoria in cui salvare il risultato della lettura unsignedchar∗pT emperature si passa alla lettura vera e propria con la funzione Read().

58 // p r o v o a l e g g e r e i l r e g i s t r o 112 d e l l a t e l e c a m e r a

59 t r y {

60 // u s o l a I P a o R e g i s t e r A c c e s s I n t e r f a c e

61 I P a o R e g i s t e r A c c e s s P t r p t r P a o R e g i s t e r = p t r P a o ; 62 i f( p t r P a o R e g i s t e r != NULL) {

63 // I l r e g i s t r o dove l a B a s l e r Camera s a l v a l a t e m p e r a t u r a l e t t a d a l s e n s o r e 64 long tempReg = 1 1 2 ; 65 // l a l u n g h e z z a i n b y t e d e l r e g i s t r o 66 long tempLength = 1 ; 67 // i l p u n t a t o r e dove s a l v o l a t e m p e r a t u r a l e t t a

68 unsigned char ∗ pTemperature = new unsigned char[ tempLength ] ;

70 p t r P a o R e g i s t e r −>Read ( tempReg , pTemperature , tempLength ) ;

A questo punto, salviamo la temperatura nella memoria condivisa con il resto del sistema di visione. La locazione in cui salvarla `e stata concordata con gli sviluppatori dell’interfaccia del sistema di visione che si occuperanno di leggerne i valori e della parte di codice che andr`a a verificare se siamo in una situazione critica da segnalare oppure no.

72 i f( pTemperature != NULL) { 73 i n t t e m p e r a t u r a = (i n t) ∗ pTemperature ; 74 // s c r i v o l a t e m p e r a t u r a d i n T e l e c a m e r a i n memoria c o n d i v i s a 75 i f( pMemCondivisaQualitaImmagine != NULL) { 76 i f( n T e l e c a m e r a >= 0 && n T e l e c a m e r a < c . NUM TELECAMERE) { 77 pMemCondivisaQualitaImmagine [ n T e l e c a m e r a ] . t e m p e r a t u r a = (i n t) ∗ pTemperature ; 78 n T e l e c a m e r a++; 79 } 80 } 81 } 82 e l s e i f( pTemperature == NULL) { 83 // s e l a t e l e c a m e r a non r i s p o n d e i n s e r i s c o −1 n e l l a memoria c o n d i v i s a 84 i f( pMemCondivisaQualitaImmagine != NULL) { 85 i f( n T e l e c a m e r a >= 0 && n T e l e c a m e r a < c . NUM TELECAMERE) { 86 pMemCondivisaQualitaImmagine [ n T e l e c a m e r a ] . t e m p e r a t u r a = −1; 87 n T e l e c a m e r a++; 88 } 89 } 90 } 91 <... >

Infine la funzione chiude la connessione. Tutto questo viene ripetuto per ognuna delle telecamere. La funzione readTemperature() viene quindi messa in esecuzione periodicamente tramite un timer.

Analisi delle prestazioni e Test

I test sono stati effettuati con l’intento di dimostrare l’utilità del filtraggio di smoothing nella pre-elaborazione, e quindi dimostrare che il filtraggio proposto funziona meglio, nel caso in cui le immagini siano affette dal particolare tipo di rumore verticale visto nei capitoli precedenti, di un filtro standard di smoothing. Si riportano i risultati ottenuti nella tabella 5.1, dalla quale appare chiaro il miglioramento apportato al sistema dalla funzione Indivi- duaROIImmagineFiltraggio(). Viene, infatti, migliorato il riconoscimento dei difetti nel sistema del 12.5% portandolo al 100% dei difetti individuati; i difetti trovati che in realtà non esistono calano nel caso migliore dell’88%; e l’erosione dovuta allo smoothing dei difetti è nel caso migliore del 3.7%, ov- vero viene segnalato il 96.3% della lunghezza delle righe d’aria. L’erosione da parte della funzione che effuttua il filtraggio, è da attribuire all’effetto dello smoothing, che oltre ad attenuare il rumore, attenua inevitabilmente anche tutto il resto dell’immagine. I risultati migliori sono stati ottenuti sceglien- do i parametri dell’algoritmo di smoothing e del Canny in maniera accurata in base al tipo di immagine da elaborare. Volendo infatti fare una classifi- ca, si nota che l’errore minore sull’erosione delle righe d’aria viene compiuto

quando non si effettua nessuna pre-elaborazione, un’errore intermedio si ha con il filtro di smoothing proposto, ed infine, l’errore maggiore si ottiene nel caso di filtro mediano. Si `e giunti alla conclusione, poi, di come tali errori siano influenzati non solo dal tipo di smoothing effettuato ma anche dalla scelta dei parametri del filtro di Canny. Infatti nel caso di soglie del Can- ny [T1 = 25, T2 = 65] si ha una riduzione media del 6.6% della lunghezza,

mentre con le soglie [T1 = 35, T2 = 80] si ha una riduzione media del 10.3%.

Mentre nel caso di smoothing con soglie [S1 = 0.96, S3 = 0.5] si ha una ridu-

zione media del 7.9% e con soglie [S1 = 0.6, S3 = 0.4] una riduzione media

del 11.2%. In tabella 5.1 si sono riportati i risultati migliori ottenuti con la combinazione parametri canny, parametri smoothing che minimizza l’errore [S1 = 0.96, S3 = 0.5] e [T1 = 25, T2 = 65]. A fronte di queste migliorie si ha,

infine, un tempo di elaborazione di appena 17 ms per ogni frame, con un incremento temporale di appena 3 ms corrispondenti al 21.43% di tempo in pi`u. Infine, le elaborazioni complete di ogni frame durano in media 84 ms senza smoothing e 87 ms con lo smoothing.

senza smoothing con smoothing Difetti individuati 87.5% 100% Riduzione rumore - _{60% ÷ 88%}

Lunghezza righe - _{90.6% ÷ 96.3%} Tempo di Elaborazione 14 ms 17 ms

Tabella 5.1: Riepilogo delle prestazioni relative alle funzioni Individua- ROIImmagine() e IndividuaROIImmagineFiltraggio()

Per quanto riguarda i filtraggi del segnale che campiona la posizione del centro tubo nel tempo, si sono utilizzati i due filtri riportati in tabella 5.2. Il segnale filtrato corrispondente al filtro FIR passa-basso risulta essere il migliore, anche se impiega pi`u tempo ad andare a regime, 896 campioni, pari a 1.12 ms iniziali che non si possono analizzare. Il filtro FIR impiega

Fpass Fstop Dpass Dstop Ordine

Filtro L-P FIR 4 Hz 6 Hz 0.1 (69.6 dB) 0.001 (-15.6 dB) 896 α _{1 − α}

Filtro 2EXP 0.85 0.15

Tabella 5.2: Dettagli dei filtri testati

inoltre un tempo molto maggiore di elaborazione, pari a 0.029459 s per 10000 campioni filtrati, contro i 0.000109 s della media con doppio smorzamento esponenziale, pari a circa 270 volte in pi`u. Il segnale filtrato FIR ottenuto `e riportato in figura5.1. Tale segnale presenta un’oscillazione attorno al valore medio della posizione del centro tubo e un’escursione massima di 0.26 mm. Integrando la curva ottenuta dal FIR su periodi corrispondenti a 10 tubi (4000 campioni) si ottengono aree sottese in media del valore di 220 µm2_.

Lo studio della curvatura del tubo può avvalersi di uno dei due metodi: si può fissare una soglia massima per l’escursione del segnale rispetto al valore medio, oppure si può fissare una soglia massima per l’area sottesa dal segnale in un numero sufficiente di tubi, in quanto risulta difficoltoso sincronizzare i campioni con l’inizio e la fine del singolo tubo.

Si descrivono nei paragrafi che seguono i test eseguiti in maniera detta- gliata, e si chiarir`a il tipo di prove che sono state effettuate, quali parametri sono stati utilizzati, e pi`u in generale il modus operandi con cui sono state portate avanti.

Nel documento Analisi e tuning del sistema di elaborazione di una macchina di ispezione per il controllo di qualità del tubo vetro (pagine 112-125)