Capitolo 3 Implementazione del Test Dinamico

Implementazione del Test Dinamico

3.1 Strumentazione di Test

In questo capitolo verrà analizzata l'implementazione del Dynamic Test, ovvero come le specifiche richieste in termini di monitoraggio funzionale dinamico del Thermal compensator siano state messe in atto in fase di produzione.

Il test viene effettuato sulla Linea TC2, una delle unità fondamentali all'interno dell'intero processo produttivo del Piezo Injector. Occorre specificare che al momento di questo lavoro il progetto si trovava nella cosiddetta fase 1, quella durante la quale vengono per la prima volta affrontati i problemi della produzione di serie ma in cui i volumi prodotti sono ancora relativamente bassi se paragonati alle fasi successive ed in particolare al funzionamento a regime. In un progetto di questo tipo è infatti normale che dapprima vengano valutate le funzionalità delle linee a volumi ridotti e tipicamente, dopo una validazione del processo produttivo, si passa ad aumentare la produzione con un conseguente ampliamento delle strutture. Per la corretta implementazione del test risulta fondamentale analizzare lo schema di massima delle interazioni fra i vari dispositivi utilizzati, schema che riportiamo in figura 3.1.

Di seguito andremo a descrivere le caratteristiche e le funzionalità dei vari blocchi, dedicando particolare attenzione a quelli di nostro interesse.

Fig3.1 Schema a blocchi della strumentazione del Dynamic Test con le relative interazioni

3.1.1 PLC

Il PLC (Programmable Logic Controller) ha essenzialmente lo scopo di coordinare le operazioni che avvengono sulla linea TC2, comprese le varie fasi automatizzate che non saranno oggetto di questo lavoro: si pensi ad esempio a tutte le operazioni di carico e di scarico dei pezzi anche in relazione al superamento o meno del test dinamico. Un PLC è essenzialmente un controllore programmabile che presenta una vasta gamma di possibilità di interfacciamento con i dispositivi elettronici (sensori, calcolatori) presenti sulla linea TC2. Per le esigenze del Test Dinamico sul termocompensatore è stato scelto un Siemens S7-400 le cui caratteristiche fondamentali sono riportate nella seguente tabella, e che è mostrato nel suo aspetto nella figura 3.2.

Analysis PC (Labview) ECU Attrezzatura TC2 Micro Epsilon DriverPC PLC Centro Statistico

CPU

Memoria di programma 2 MByte (1335 Kinstructions)

Memoria dati 2 MByte

Tempo esecuzione 100 ns fixed point, 600 ns floating point Linguaggi Programmazione LAD, FBD, STL, SCL

Livelli subroutines 8

I/O

Interfacce RS 485/PROFIBUS

Input/Ouput digitali Max. 62/58 Input/Output analogici Max. 12/14

Power Supplì ±24 V DC (da 120 a 230 AC)

Temperatura ambientale Min. 0°C Max 55°C (disposizione orizzontale)

Fig 3.2 Il PLC Siemens S7-400 montato sulla linea TC 2

Per quanto riguarda il test, osserveremo che il PLC avrà essenzialmente il compito di coordinare le varie fasi dello svolgimento. Vediamole più nel dettaglio. Per prima cosa, una volta accertato il corretto posizionamento del compensatore sotto test nell'apposito alloggiamento mediante dei sensori laser, comunicherà al Driver PC (le cui funzionalità saranno spiegate successivamente) la necessità di portare l'attrezzatura meccanica in posizione per il test. La colonna di pressione (v. paragrafo successivo) scenderà, andando a posizionare il compensatore nella corretta posizione e misurando al contempo la cosiddetta forza di settaggio camera (Fs). Il Driver PC comunicherà

Dinamico (40 N<Fs<70 N). Se la condizione sulla forza risulta essere verificata, il PLC invia il segnale di start al PC di analisi (v. paragrafo 3.1.6) che inizia così il test. A questo punto il PLC attende il risultato del test e, in base ad esso, decide se mantenere il pezzo sulla linea o se inserirlo fra gli scarti.

Inoltre il PLC ha l'importante compito di gestire la cosiddetta data collection. A questo proposito occorre dire che, secondo gli standard qualitativi dell'azienda, è indispensabile avere la possibilità di monitorare le statistiche di ogni fase della produzione e del testing. Tale aspetto è essenziale perché permette ad esempio, mediante un confronto temporale fra le statistiche, di individuare eventuali problemi che siano venuti a presentarsi in una fase del processo produttivo, oppure su una stazione di testing. A questo fine esiste in tutta la rete di stabilimenti Siemens VDO, un sistema centralizzato che raccoglie ed elabora statisticamente i parametri fondamentali di ogni linea. Naturalmente ogni modulo produttivo dovrà essere in grado di inviare tali dati in un formato opportuno affinché il centro statistico possa raccoglierli senza incorrere in problemi. Anche queste operazioni verranno quindi gestite dal PLC; sorge quindi la necessità di comunicare ad esso i risultai del test, non soltanto in termini di Good o Fail, ma anche a livello di valori numerici. Vedremo come questo aspetto abbia provocato non pochi problemi a causa della particolare configurazione dei collegamenti sulla linea, e come sia stato risolto con una interazione fra PC di analisi, Driver PC e PLC.

3.1.2 Attrezzatura TC2

Con questa terminologia indichiamo tutta la strumentazione meccanica necessaria allo svolgimento del test. Vediamola adesso più nel dettaglio, aiutandoci con lo schema di figura 3.3. Un singolo modulo di test è formato essenzialmente da un alloggiamento per il compensatore termico e da un'apparecchiatura meccanica superiore che potremmo definire "colonna di pressione". Questa colonna di pressione presenta, dall'alto verso il basso, quattro componenti fondamentali.

 La molla di carico: questa molla serve essenzialmente ad esercitare una forza di precarica sulla struttura sottostante ed in particolare sul materiale piezoelettrico. Questa forza, del valore di 120 Nw, è simile a quella alla quale viene sottoposta la valvola dell'iniettore una volta alloggiato lo stesso all'interno del motore.

 La master valve: una valvola che simula il comportamento dell'ago dell'iniettore piezoelettrico, e che quindi tende ad aprirsi in corrispondenza delle sollecitazioni dell'attuatore piezoelettrico sottostante.

 Il piezostack: uno stack identico a quello dell'iniettore, con le funzionalità fondamentali descritte nel capitolo 1.

 Il sombrero: una sorta di supporto metallico che, grazie alla sua particolare forma, permette una semplice installazione di un sensore di posizione, e che rappresenta il vero e proprio punto di contatto fra il termocompensatore sotto test e la struttura di testing stessa. Nel punto di contatto è montata una cella di carico, ovvero un dispositivo in grado di misurare la forza esercitata dalla colonna di pressione sulla parte superiore del componente sotto test. E' importante che il sombrero si trovi il più possibile nelle vicinanze del compensatore termico. Le sollecitazioni che dovremo misurare saranno infatti nell'ordine del μm; quindi interporre molti componenti fra il sombrero e il compensatore significa di fatto sommare agli spostamenti effettivi quelli dovuti all'elasticità dei materiali. Per questo motivo la posizione del supporto, inizialmente prevista subito sotto al piezostack, è stata via via abbassata al fine di avere delle letture sempre più veritiere.

La colonna di pressione è comandata da una pressa di precisione in grado di imporre alla struttura dei movimenti anche dell'ordine del μm. In questo modo riusciremo a settare con estrema precisione le condizioni di testing. La pressa è comandata da motori elettrici in corrente alternata comunemente definiti Driver, che a loro volta vengono pilotati dal Driver PC. Per quanto ci riguarda ci interesseremo soprattutto della master valve e del sombrero, in corrispondenza dei quali saranno installati i due sensori di posizioni denominati rispettivamente S1 e S2, necessari per l'acquisizione dei dati del test. L'hardware in questione è mostrato in figura 3.3, ad eccezione delle molla di carico che si trova al di sopra della master valve.

Fig 3.3 Disegno dell'hardware TC2

3.1.3 Driver PC

Il Driver PC è essenzialmente il calcolatore destinato al pilotaggio delle presse di precisione. Il pilotaggio avviene mediante un opportuno software sviluppato dal costruttore dello strumento, nel quale è possibile caricare dei programmi che indichino alla meccanica le operazioni da condurre. Queste operazioni possono essere sincronizzate attraverso riferimenti temporali, o in base ad input provenienti dall'esterno; è possibile ad esempio comandare alla pressa di scendere sul componente fino a che la forza misurata dalla cella di carico non raggiunga un determinato valore. Si pensi all'utilità di una cosa del genere ad esempio per individuare l'avvenuto contatto della colonna di pressione con il compensatore sotto esame.

Nello svolgimento del test quindi tale unità avrà il compito di settare correttamente le condizioni in cui la misura avviene. In particolare, una volta avvenuto il contatto, dovrà fare in modo che il compensatore lavori al centro della camera del cilindro. Per fare questo dovrà assicurare uno

spostamento verso il basso di 160 μm per poi procedere alla misura della forza di settaggio della camera (Fs) mediante la cella di carico posta sulla parte inferiore della colonna di pressione. Come già accennato, infine, il Driver PC ha inoltre rivestito un ruolo importante per la trasmissione dei dati al centro statistico.

3.1.4 Micro Epsilon

Ricordando le nozioni introdotte nel capitolo precedente, di fatto si ha necessità di misurare degli spostamenti, e quindi dobbiamo far uso di opportuni sistemi costituiti da sensori e amplificatori. Naturalmente esistono molti sistemi in grado di individuare movimenti nell'ordine del micron, e quindi è stato necessario effettuare una scelta fra le varie possibilità offerte dal mercato. A tal proposito cerchiamo di capire quali siano stati i parametri presi in considerazione al fine della scelta.

 Dinamica;

 risoluzione: considerando che avremo a che fare con range di accettazione nell'ordine dei 5 μm, è necessaria una risoluzione di almeno 0,5 μm;

 robustezza della misura: non stiamo parlando di una misura svolta in laboratorio, in condizioni ambientali ottimali, ma di un test di serie, da effettuare su una linea di produzione e pertanto sottoposto a molti fattori ambientali. Si pensi ad esempio alle numerose vibrazioni presenti, ai dispositivi utilizzati alimentati in alta tensione (es. driver delle presse) che possono provocare una notevole interferenza elettromagnetica soprattutto di tipo condotto;

 costo: al fine di avere un prodotto competitivo è necessario anche contenere i costi fissi tra i quali troviamo quelli imputabili alle apparecchiature di produzione e testing. Considerati tutti questi parametri la scelta è caduta sul Micro Epsilon DT 110-U05-M-C3, amplificatore analogico corredato di sensore induttivo basato sul principio di mutua induzione (da qui la necessità della natura metallica del target della misura). Nella tabella seguente andiamo a riportare le caratteristiche principali estratte dai data sheets.

Dinamica lineare (μm) 0 ÷ 500 Massima frequenza (kHz) 10,00 Risoluzione statica (nm) 50,00 Risoluzione dinamica (nm) 500,00 Non linearità (% fondo scala) 0,8 Temperatura operativa (°C) -50 ÷ 150

Uscita analogica Corrente – tensione

3.1.5 ECU

Con questo termine si indica tipicamente la centralina elettronica presente sul banco di testing. Questa ha essenzialmente lo scopo di simulare il comportamento della centralina realmente presente sull'autoveicolo e che, come sappiamo, con i suoi impulsi regola l'apertura della valvola dell'iniettore. Mediante dei comandi software è possibile fare in modo che essa invii degli impulsi al piezostack di opportuno livello energetico. Nel nostro caso vedremo che il pilotaggio avverrà con un treno di impulsi di periodo 24 ms e con una larghezza della fase alta di 7 ms in un caso e 15 nell'altro. L'onda quadra risultante dovrà avere un'ampiezza in termini di energia di 24 mJ ed un transitorio di salita e discesa trascurabile rispetto ai tempi in gioco. A tal proposito tra i vari file forniti dagli sviluppatori della centralina è stato scelto uno che garantisse i 24 mJ richiesti con un transitorio di salita di 200 μs. Da notare come il caricamento di questo file dovrà essere effettuato in automatico dal software di analisi, al fine di evitare errori umani che potrebbero pregiudicare il corretto svolgimento del test.

3.1.6 Analysis PC

L'Analysis PC è il calcolatore sul quale è installato il software di analisi appositamente sviluppato per questo test. Il software in questione è stato sviluppato con l'ambiente di sviluppo

Labview 7.1 della National Instruments per piattaforme Microsoft Windows. Essenzialmente

questo calcolatore avrà vari compiti: acquisire i segnali analogici provenienti dai sensori della linea, campionarli a frequenza opportuna ed infine elaborarli fornendo in ultima analisi il responso del test.

Per quanto riguarda l'acquisizione dei dati, essa avviene mediante una scheda National

Instruments, la NI 61-10. Essa fa parte della famiglia "61" ovvero di un insieme di schede

sviluppate per l'acquisizione di segnali anche analogici, particolarmente indicate, grazie alle loro prestazioni, nel campo dell'automotive. In figura 3.4 è mostrata la scheda NI 61-10.

Fig 3.4 La scheda NI 61-10

Nella tabella seguente andremo ad elencare le caratteristiche principali della scheda in questione.

Bus PCI

Analog Inputs 4

Input Resolution (bits) 12

Sampling Rate (MS/s) 5

Input range (V) ±0,2 to ± 42

Analog Outputs 2

Max Output Rate (MS/s) 4

Output Range (V) ±10

Digital I/O 8

Triggers Analog, digital

La scheda è inoltre dotata di un software, denominato Device Manager, che permette di configurare l'acquisizione dei dati. In particolare si possono assegnare i canali digitali e quelli

analogici e configurare degli opportuni task, ovvero dei processi di acquisizione dall'esterno. Nello spiegare queste ultime affermazioni faremo utilizzo di alcune figure esplicative.

Nella figura 3.5 vediamo una schermata molto importante: sulla sinistra notiamo il pannello di gestione dei canali fisici della scheda e dei task. Vediamo come i quattro ingressi analogici della scheda (cerchio rosso) siano assegnati rispettivamente ai due sensori di posizione, al segnale di trigger (spiegheremo più avanti di che cosa si tratti) e al segnale di forza proveniente dalla cella di carico. Allo stesso tempo notiamo che questi canali vengono utilizzati nel task denominato

analogIN, attraverso il quale realizzeremo l'acquisizione dai sensori. Esistono inoltre altri due

task importanti al fine del test ovvero digitalIN e digitalOUT che gestiranno l'acquisizione dei segnali di sincronizzazione con il PLC e l'invio dei trigger alla centralina.

Sempre sul Device Manager possiamo gestire nell'ambito della definizione dei parametri del task, la frequenza di campionamento e la durata dell'acquisizione. Nel nostro caso possiamo notare (cerchio azzurro in fig. 3.5) come per i task di acquisizione abbiamo settato i parametri

Rate e Samples To Read rispettivamente a 200 KHz e a 3800. Il primo dei due rappresenta la

frequenza di campionamento per l'acquisizione dei dati. La scelta di questo valore deriva di fatto da un compromesso fra bontà dell'acquisizione e velocità di elaborazione. Da un lato abbiamo la necessità di acquisire la forma d'onda, compresi i fenomeni transitori, nella maniera più fedele possibile; dall'altro essendo quello dinamico un test che esige una parte dell'elaborazione in tempo reale, abbiamo la necessità di ultimare questa elaborazione prima dell'arrivo dei successivi campioni dai sensori. Considerando dei fronti d'onda nell'ordine dei 100 μs, ed una frequenza di campionamento pari a 10 volte quella minima secondo il teorema di Nyquist, siamo arrivati ai 200 KHz impostati . Abbiamo poi notato come questa frequenza non provocasse una perdita di dati in fase di acquisizione ed elaborazione e pertanto l'abbiamo mantenuta. Per il secondo parametro (Samples to Read) abbiamo scelto 3800. Ciò equivale ad acquisire 19 ms della forma d'onda. Tale durata nasce da una nostra esigenza: non necessariamente dobbiamo infatti acquisire tutti i 24 ms dato che gli impulsi di larghezza 7 e 15 ms rispettivamente vengono inviati all'inizio del periodo. Nel caso peggiore, quello dei 15 ms, sarà necessario acquisire tutta questa fase, più una parte della forma d'onda successiva al fronte in discesa in modo da poter calcolare l'offset iniziale del sensore rispetto al quale calcolare lo spostamento per differenza. Osservando i dati acquisiti abbiamo notato come fosse sufficiente calcolare questo offset in un millisecondo, fra i 18 e i 19 ms; la restante parte di dati (fra 19 e 24) non avrebbe aggiunto alcuna informazione. Abbiamo pertanto deciso di escluderla dal task di acquisizione, per non appesantire inutilmente la mole di lavoro del software.

Per concludere il paragrafo diciamo come nel PC di analisi siano installati anche tutti i file di acquisizione necessari al funzionamento del software (i file contenenti i percorsi, i parametri di configurazione) e come sul suo hard disk il programma di elaborazione andrà a salvare gli output del test.

3.2 Il software di analisi

Lo sviluppo del software di analisi rappresenta senz'altro il cuore di questo lavoro, volto alla gestione del test dinamico di serie sul compensatore termico del Piezo Injector.

Prima di descriverne le funzioni fondamentali ricordiamo innanzitutto che tale software è stato sviluppato tramite l'ambiente Labview 7.1 per sistema operativo Windows. Tale software, nella sua versione completa, presenta anche un tool denominato Application Builder che dà la possibilità di creare a partire dal codice Labview, un programma sotto forma di file eseguibile (.exe) che può essere installato anche su macchine sulle quali non sia presente l'ambiente di sviluppo. Ovvi sono i benefici in termini di costi di licenza per un approccio di questo tipo, qualora, come nel nostro caso, il software debba essere presente su più stazioni che svolgano la stessa funzione.

L'applicativo che andremo a descrivere è piuttosto complesso per cui sarà indispensabile dare prima alcune nozioni generali. Innanzitutto ricordiamo come per un software che svolge una notevole mole di lavoro, sia indispensabile un approccio di tipo gerarchico. Sarà cioè importante suddividere il problema principale in una serie di più semplici tematiche da affrontare separatamente. Il nostro ambiente di sviluppo supporta questo tipo di visione attraverso la possibilità di creazione di Virtual Instruments (VI) che svolgono essenzialmente la funzione delle procedure e delle funzioni nei classici linguaggi di testo.

Anche in questa trattazione eseguiremo un approccio di questo tipo, anche se occorre una precisazione: non tutti i VI saranno affrontati in maniera esaustiva e ciò è dovuto alla notevole complessità del software realizzato. Ci soffermeremo sulle parti più importanti dal punto di vista concettuale, e, allo stesso tempo, vitali nella corretta implementazione delle specifiche.

Cominciamo col vedere quindi i principali temi affrontati, con le relative problematiche; successivamente analizzeremo le soluzioni approntate attraverso l'implementazione.

 Interfaccia grafica. Un qualsiasi software utilizzato su una linea di produzione deve necessariamente presentare un'interfaccia che sia il più possibile user friendly. Infatti dovrà fornire informazioni in modo chiaro ed intuitivo, permettendo allo stesso tempo ai responsabili del processo di intervenire in merito ai problemi riscontrati, senza che essi necessariamente conoscano il codice utilizzato per l'implementazione. Altro aspetto

fondamentale è rappresentato dalla multiutenza. Deve cioè essere messa a disposizione un'area protetta da password, all'interno della quale siano gestibili i parametri di sistema oltre che i limiti di validità del test. Oltre a questo l'utente deve poter avere accesso alle forme d'onda acquisite dai sensori, agli output numerici più importanti e ai risultati del test.

 Elaborazione. Questa sezione è sicuramente la più critica per le funzionalità del software. Infatti dobbiamo da un lato accertarci che l'elaborazione sia coerente, ovvero che effettivamente le operazioni effettuate siano corrette in funzione delle specifiche fornite. A questo si deve aggiungere un volume computazionale gestibile. Essenzialmente avremo una parte di elaborazione in tempo reale ed una parte definita di

post processing che dovrà fornire gli esiti finali del test insieme alle statistiche di quanto

avvenuto durante la sessione produttiva in corso. Nella prima delle due fasi si consideri l'importanza rivestita dal calcolo dell'offset iniziale dei sensori che, in caso di errore, pregiudicherebbe l'intera elaborazione dei dati. Nel post processing invece si andranno anche a valutare alcuni parametri a fine "diagnostico": molto importante è infatti monitorare l'elongazione del piezostack durante il test. Se infatti essa scendesse troppo avremmo probabilmente a che fare con un attuatore piezoelettrico danneggiato.

 Gestione file di input/output. Come accennato, per funzionare correttamente, il programma di analisi deve ricevere molti parametri in ingresso oltre che fornirne in uscita. Per fare in modo che rimanesse traccia di questi parametri e per evitare di doverli reinserire ogni volta al riavvio del programma, si è deciso di andarli a registrare in appositi file che vengono poi letti ogni volta che il programma viene riavviato. Pertanto ogni volta che modifichiamo un parametro di sistema, o un limite del test, questi file vengono aggiornati secondo questo concetto.

 Data collection. Per i motivi esplicitati nel precedente paragrafo, gli output numerici principali dovranno pervenire al PLC, che provvederà poi ad inviarli al centro statistico. Come si nota nello schema generale delle connessioni il PC di analisi non comunica in scrittura numerica col PLC e quindi abbiamo dovuto individuare un metodo alternativo per far pervenire questi valori.

3.2.1 Interfaccia grafica

L'interfaccia grafica è organizzata tramite dei pannelli che permettono una gestione intuitiva di tutto il Dynamic Test. In particolare all'avvio del programma abbiamo il pannello principale, all'interno del quale troviamo tutti i principali output del test. In figura 3.6 è riportato tale pannello con evidenziate le caratteristiche fondamentali.

Fig 3.6 Il pannello principale del Software di analisi

Osservando il main panel risulta subito evidente la visualizzazione di tre chart che rappresentano in modi diversi i segnali acquisiti. Quella di dimensioni maggiori rappresenta il segnale acquisito da tutti i sensori del sistema. Per comodità di visualizzazione, tale grafico è aggiornato ogni cinquanta iniezioni. Nei grafici piccoli invece troviamo indicato il valore misurato dal sensore S1 nei due cicli (7 ms grafico di sinistra, 15 quello di destra). Questi grafici sono particolarmente utili per capire la bontà dei risultati ottenuti. Infatti, quando iniziamo a testare un compensatore

esso presenterà un comportamento transitorio, che dovremo evitare assicurandoci di lavorare con il componente già a regime. Per poter attuare questa operazione scarteremo un certo numero di iniezioni all'inizio del ciclo. Quelle considerate saranno contenute fra le due linee verticali nei grafici; in questo modo possiamo avere informazioni in modo intuitivo sul superamento della condizione transitoria. Ad esempio in figura 3.6 si vede come questo sia effettivamente avvenuto all'interno della zona di nostro interesse.

Evidenziata in rosso troviamo l'area dedicata ai test. In base ai valori elaborati i led indicati si accendono o meno, a seconda dell'esito delle tre prove del Dynamic Test. Ovviamente essi determineranno l'esito complessivo della prova, provocando l'accensione di uno degli indicatori

Good/Fail, posti in basso alla schermata.

Evidenziati in blu troviamo invece gli output numerici del programma. In particolare troveremo le seguenti indicazioni: per ognuno dei due cicli di test, i valori riscontrati dai due sensori S1 e S2, con la somma dei due, rappresentante l'elongazione del piezostack durante i test stessi. Inoltre nella zona di destra troviamo anche i valori delle pendenze delle rette di interpolazione dei segnali rispettivamente dei sensori S1 e S2.

Evidenziati in verde troviamo invece alcuni parametri di controllo, utili a determinare l'affidabilità dei risultati forniti dal test. Particolare valore rivestono gli indicatori di Offset Valve e Offset Sombrero. Essi infatti riportano il valore dell'offset medio sulle varie iniezioni dei cicli, e rispetto a tale offset noi andiamo a calcolare gli spostamenti relativi.

In basso a destra nel pannello principale troviamo un'area evidenziata in giallo. In essa vengono indicati gli errori nel test derivanti da problemi meccanici all'interno della stazione. Questi errori sono essenzialmente tre: la possibilità di danneggiamento del piezostack, oppure errori di posizionamento iniziale dei sensori, rispetto alla loro dinamica di lavoro. Il più grave di questi errori risulta essere quello di danneggiamento dell'attuatore piezoelettrico; nel caso in cui tale errore si verifichi vedremo che il Labview dovrà mettersi in attesa, attendendo che le eventuali operazioni di manutenzione vengano effettuate. Una volta ultimate potremo utilizzare il tasto di

Reset Piezo in modo da rimuovere l'indicazione dell'errore permettendo al programma di analisi

di tornare pronto per un'ulteriore acquisizione.

Sempre sul pannello principale troviamo un pulsante per l'inserimento della password per la multiutenza, pulsante che diventa attivo soltanto qualora venga disattivata l'analisi (Pulsante

Active/Inacitive). In questo modo possiamo avere accesso all'area protetta, quella dalla quale si

possono modificare i parametri dell'analisi.

Fig 3.7 Pannello di inserimento/modifica password

La gestione della password è stata implementata in un opportuno strumento virtuale denominato

Panel Password.

In basso alla schermata si può notare come ci sia un menu ad etichetta con due ulteriori opzioni:

Report Mlift and statistics e Dynamic Actual Sensor Dysplay. La prima ha essenzialmente lo

scopo di fornire le statistiche del Dynamic Test oltre ad un report riguardante la retta di interpolazione, mentre la seconda risponde all'esigenza in fase di montaggio della stazione di verificare il corretto posizionamento dei sensori. Dalle specifiche del sistema di misura si nota infatti come i sensori abbiano una dinamica di 500 μm. Considerando degli spostamenti massimi di circa 30 μm, una posizione iniziale ad esempio di 480 μm non sarebbe accettabile: infatti

andremmo a rilevare una misura di 20 anziché di 30 avendo di fatto raggiunto il valore di fondo scala. A tal proposito è stato implementato un controllo che permette di verificare se l'offset iniziale sia compreso nell'intervallo [100 μm;450 μm] e di verificare il corretto posizionamento mediante due led a destra delle forme d'onda provenienti dai sensori visualizzate in tempo reale. In figura 3.7 è mostrata la schermata di visualizzazione dei sensori oltre all'implementazione del relativo controllo.

Un aspetto molto importante del test è rappresentato dalla gestione dei parametri di sistema e dei limiti di validità dei componenti sotto test. Come accennato, questi valori devono essere modificati solo dal responsabile del processo produttivo per evitare ad esempio l'avanzamento in produzione di componenti classificabili in realtà come scarti. Per soddisfare questa esigenza si è scelto un approccio di questo tipo. All'inserimento della password di amministratore compare un menu ad etichetta in basso a destra della schermata principale, e tra le opzioni possibili, notiamo l'etichetta SYS. Scegliendo questa opzione abbiamo un cambiamento della schermata, avendo così la possibilità di accedere a quattro pulsanti, che ci permetteranno di settare rispettivamente: limiti del test dinamico, parametri di sistema, percorsi di salvataggio e di recupero dei principali files, e indirizzi IP e porte utili per stabilire connessioni di rete per il data collection. Essenzialmente la gestione di tutte queste informazioni è molto simile e, per brevità, vedremo solo quella relativa ai parametri di sistema.

Innanzitutto all'avvio vengono automaticamente recuperati dai file salvati gli ultimi parametri inseriti (vedi relativo paragrafo sulla gestione dei file); se apportiamo delle modifiche e selezioniamo il pulsante in basso a destra (Values Accept), tali modifiche vengono salvate dal software sia nel file (per leggere alla successiva esecuzione) sia all'interno di una variabile globale, in modo che tali parametri possano essere richiamati all'interno del programma ogniqualvolta ce ne sia necessità. Le procedure di salvataggio e recupero dei file verranno analizzate nell'apposito paragrafo.

Fig 3.10 Procedura di salvataggio e recupero dei parametri di sistema

Sempre nell'area protetta da password esistono altre utilità, tra le quali ricordiamo la presenza di un pulsante Soft Start, che permette di dare il segnale di inizio test senza che il comando arrivi dal PLC. Questa funzione è utile soprattutto in fase di debug; ci permette infatti di lanciare dei test manuali al fine di verificare il corretto comportamento del programma senza interagire con il PLC e risparmiando quindi alcune operazioni.

Per ultimo ricordiamo che, una volta resa inattiva l'analisi, abbiamo a disposizione un pulsante

Program Abort che ci permette di uscire dal programma.

3.2.2 Acquisizione ed elaborazione dei dati

Questa rappresenta senz'altro la parte più corposa della trattazione, oltre che la più complessa. Ha essenzialmente lo scopo di delucidare come il software di analisi gestisca il test dinamico dal momento dell'avvenuto settaggio della camerina da parte dell'hardware del TC2, fino alla

Vediamo innanzitutto la gestione dell'acquisizione. Come accennato avremo di fatto due cicli, a cui corrisponderanno due diverse larghezze d'impulso inviato alla centralina, rispettivamente 7 ms e 15 ms. In ognuna di queste fasi avremo un certo numero di acquisizioni di riscaldamento, ovvero atte a far regimare il comportamento del compensatore, e poi delle iniezioni vere e proprie in cui i valori riscontrati saranno utilizzati ai fini dell'elaborazione. Sia il tempo di riscaldamento che il numero di iniezioni sono settabili dall'utente tramite il pannello dei limiti. Dopo numerose prove è stato deciso di utilizzare un riscaldamento con durata pari ad 1 sec e 30 iniezioni per l'acquisizione. Considerando la durata di 24 ms per ognuno degli impulsi inviati, ognuna delle due fasi del ciclo occupa un tempo pari a circa 1,8 sec. Considerando poi un intervallo di alcuna centinaia di ms fra un ciclo di iniezioni e l'altro, si arriva ad una durata complessiva di circa 4 sec, tempo compatibile con le necessità della produzione (si pensi a tal proposito che il test di un compensatore in laboratorio in fase di sviluppo del prodotto richiedeva fino a 5 minuti). Anche la durata di ogni fase è gestibile dal pannello e, qualora inseriamo un valore superiore agli 1,8 ms, anche le iniezioni successive alle 30 indicate come valide vengono scartate.

Concentriamoci su questa prima fase. Innanzitutto dobbiamo fare in modo che il file corretto della centralina venga caricato. Per fare questo esiste un opportuno VI il cui diagramma a blocchi è riportato in figura 3.11. In esso estraiamo il percorso dall'opportuna variabile locale settata mediante il pannello dei percorsi di sistema e mandiamo in esecuzione il file tramite la primitiva System Exec.vi che è l'equivalente di una riga di comando DOS per l'esecuzione. Una volta avvenuta l'esecuzione si va anche ad effettuare un controllo sul tempo necessario al caricamento del file. Qualora esso sia maggiore di una costante inserita all'interno dei parametri di sistema (nel nostro caso 5 sec.), il caricamento non va a buon fine evidenziando un malfunzionamento da gestire. Infatti lo stato del caricamento del file viene inserito in un'opportuna variabile logica il cui stato di True sarà indispensabile per l'inizio del test.

Fig 3.11 Diagramma a blocchi relativo al caricamento del file della centralina: in alto si nota l'estrazione del percorso e del nome file dal pannello mentre in basso il controllo sul timeout dell'esecuzione

Una volta avvenuto il caricamento dovremo andare ad acquisire i segnali provenienti dal PLC. Ciò significa mandare in esecuzione il task digitalIN e leggere, dai canali fisici della scheda, i segnali necessari ai nostri scopi. In particolare, oltre al segnale necessario a ricaricare il file della centralina qualora siano intervenuti problemi, riceveremo i segnali di Start e di Reset necessari alla sincronizzazione del test. Quello di start sarà da interpretare come il messaggio di avvenuto settaggio della camera di test, con la conseguenza di un compensatore di fatto pronto ad essere testato. La procedura di acquisizione dei segnali provenienti dal PLC consiste nell'apertura del

nella richiusura del task. E' molto importante in questa fase una corretta gestione dei segnali di errore in modo che essi possano essere visualizzati dall'utente che possa capire eventuali problemi di comunicazione fra i molti dispositivi utilizzati durante il test, evitando quindi di considerare validi valori numerici in realtà derivanti da errori.

Il passo successivo è rappresentato dall'acquisizione dei segnali veri e propri provenienti dai sensori, cosa che avviene mediante il task analogIN già evidenziato nella trattazione riguardante il Device Manager. Prima di effettuare la lettura occorrerà inviare alla centralina gli impulsi opportuni facendo in modo il piezostack venga eccitato secondo le modalità prestabilite. Ciò viene garantito dal task digitalOUT e da clock.vi. In questo VI si vanno a leggere i parametri di interesse dalla variabile globale dei parametri di sistema, e grazie a questi valori a generare delle forme d'onda di opportuna durata e duty cycle. Dapprima verranno generate quelle relative al ciclo di 7 ms, successivamente quelle dei 15 ms. Questo avverrà per tutta la durata del test impostata, come detto, attraverso un opportuno pannello. La procedura descritta è mostrata in forma di diagramma a blocchi nella figura 3.12.

Fig 3.12 Invio delle forme d'onda alla centralina: si nota come dipendentemente dal ciclo vengano estratti i parametri opportuni dal vettore dei parametri di sistema, oltre al controllo sulla durata massima dei cicli

Contemporaneamente all'invio dei segnali gestiremo l'acquisizione dai sensori. La corretta temporizzazione degli eventi sarà garantita dal tipo di gestione delle operazioni da parte di Labview. Infatti le varie operazioni rimangono in attesa fino alla disponibilità dei dati relativi al loro svolgimento; possiamo quindi dire che il task analogIN trasmetterà i dati quando essi

saranno presenti sui buffer di uscita della scheda National Instruments. Nella figura 3.13 è mostrato il processo di acquisizione e la linea di colore arancio più spessa rappresenta i dati che vengono trasmessi ai blocchetti successivi per le varie elaborazioni. Alcuni parametri, tra cui il

timeout sono stati ricavati da considerazioni empiriche derivanti dall'hardware elettronico a

disposizione.

Fig 3.13 Procedura di acquisizione dei dati dai sensori

Una volta che i dati vengono resi disponibili essi devono essere elaborati in modo da ottenere i valori di nostro interesse e, in ultima analisi, il risultato del test.

Come già accennato, un calcolo molto importante riguarda l'offset iniziale dei sensori, che potrebbe pregiudicare l'intero svolgimento del test. Consideriamo ad esempio la lettura in corrispondenza del sensore S2, quello posto in corrispondenza del sombrero. Quest'ultimo, a causa dell'elongazione del piezostack, tenderà a spostarsi verso il basso, con un movimento rispetto alla posizione iniziale. Calcolando la differenza fra la posizione rilevata in conseguenza dell'eccitazione e l'offset iniziale, riusciremo ad individuare l'abbassamento reale del sombrero stesso. Ciò dovrà essere effettuato in corrispondenza di ogni singola iniezione e tutte queste operazioni saranno effettuate per entrambi i sensori da un opportuno strumento virtuale denominato subcanaloffset.vi. Il suo diagramma a blocchi è riportato in figura 3.14; tale diagramma indica una notevole complessità anche se le operazioni basilari sono piuttosto semplici. Dobbiamo acquisire i dati relativi ad una iniezione ed effettuare sui segnali provenienti dai due sensori di posizione S1 ed S2 un media temporale dei valori compresi tra 18 ms e 19 ms, ovvero nell'ultimo millisecondo dell'acquisizione. La procedura è quindi del tutto analoga per i

due sensori; pertanto procederemo ad illustrare solo quella relativa ad S2 ovvero al sensore posto in corrispondenza del sombrero. Essenzialmente, tramite opportune funzioni dell'ambiente di sviluppo, andremo a tagliare la forma d'onda, estraendone la finestra di nostro interesse, per poi effettuare le operazioni di media temporale. In figura 3.14 è mostrato il diagramma a blocchi del

VI che implementa tali funzionalità.

Fig 3.14 Schema a blocchi relativo al calcolo dell'offset iniziale dei sensori: si nota come l'estrazione della finestra di interesse dipenda dai parametri di sistema relativi al ciclo in corso (7 o 15 ms)

Osservando lo schema possiamo notare alcune funzionalità interessanti. Innanzitutto vediamo come i parametri di sistema siano effettivamente estratti dalla variabile globale System

Parameter, che possiamo vedere a sinistra come un vettore dal quale estraiamo gli elementi di

nostro interesse. Osserviamo inoltre la presenza di un filtro passa basso sul segnale, la cui attivazione risulta opzionale, che serve per eliminare componenti frequenziali non di nostro interesse e che quindi possiamo imputare solo a disturbi sia di natura meccanica che elettrica all'interno della strumentazione di test. Altra caratteristica fondamentale riguarda l'uscita dello strumento virtuale. Come possiamo vedere essa è rappresentata ancora da un segnale, o meglio da un vettore di segnali, che però raggiungono l'esterno traslati di una quantità pari proprio all'offset calcolato in ciascuna delle iniezioni. Di fatto in questo modo avremo un'informazione del tutto equivalente a quella iniziale, ma le varie forme d'onda saranno adesso riferite ad un valore di non eccitazione del piezostack e tale valore corrisponderà sui grafici allo 0. In questo modo abbiamo di fatto trasformato dei valori realtivi, in valori assoluti. Le forma d'onda scalate in questo modo saranno quindi trasmesse al grafico riguardante l'acquisizione sul pannello

principale. E' importante notare come il calcolo dell'offset presenti una problematica molto importante riguardante le tempistiche del test. Abbiamo detto come tale calcolo venga effettuato nell'ultimo millisecondo di acquisizione della forma d'onda ovvero per i parametri da noi impostati fra 18 e 19 ms. Se noi cambiassimo, mediante il Device Manager, il valore finale con 24 ms (acquisendo di fatto tutta la forma d'onda), incorreremmo in un grave malfunzionamento. In tal caso il calcolo verrebbe effettuato fra 23 e 24 ms e così facendo i laboriosi calcoli necessari potrebbero rallentare il sistema a tal punto da far perdere l'istante del successivo trigger. Il test verrebbe comunque effettuato ma avremmo di fatto un trigger valido ogni due con il conseguente raddoppio dei tempi di esecuzione, cosa che non possiamo accettare nell'ambito di un test di serie, laddove un tempo ciclo basso significa essenzialmente un aumento della produttività delle linee.

Una volta calcolato correttamente l'offset dei sensori, dovremo andare ad effettuare le operazioni necessarie allo svolgimento del test dinamico. Concentriamoci sul primo test nel quale, ricordiamo, dovremo valutare il valore misurato dal sensore durante l'acquisizione relativa alla larghezza d'impulso di 7 ms. Per ricavare questo valore effettueremo di fatto due medie: una di tipo temporale sulla singola iniezione, calcolata fra due estremi (ta e tb) impostabili dall'utente mediante il pannello dei limiti, ed una di tipo statistico. Infatti andremo ad immagazzinare in un opportuno vettore tutte le medie temporali ricavate e tra esse calcoleremo l'ulteriore valor medio. Il valore così ricavato sarà confrontato con i limiti impostati, ovvero quello inferiore di 2 μm e quello superiore di 6 μm, in modo da stabilire il superamento della prima delle tre prove. Il confronto con i valori limite verrà trattato successivamente quando analizzeremo il Post

Processing. Nello schema di figura 3.15 sono analizzati il diagramma a blocchi che realizzano le

operazioni sopra citate.

Si nota come avvenga l'estrazione degli estremi della finestra di calcolo dalla variabile globale di sistema, e come effettivamente venga calcolata la media temporale mediante un'opportuna primitiva messa a disposizione dall'ambiente di sviluppo. Si nota inoltre come l'operazione citata venga effettuata per entrambi i sensori e per tutte le forme d'onda disponibili (sia quelle del ciclo a 7 ms che del ciclo a 15 ms). Questo è legato all'esigenza di monitorare il valore registrato da entrambi i sensori nei due cicli di test. Tale procedura è necessaria per misurare l'allungamento complessivo del piezostack permettendoci di capire se esso sia danneggiato, cosa che avviene se

monitoraggio del sensore S1 nello stesso intervallo di tempo ci permette di stabilire il superamento del secondo test. In conclusione alla fine della procedura spiegata avremo a disposizione tre valori numerici per ogni ciclo: S1, S2 e la loro somma.

Fig 3.15 Diagramma a blocchi relativo al calcolo delle medie del valore dei sensori

D'ora in poi i valori citati verranno indicati con S17ms, S115ms, S27ms, S215ms.

Leggermente diversa risulta l'elaborazione numerica per quanto riguarda il terzo ed ultimo test (Mlift). Come detto si tratterà di fare delle operazioni simili. Tuttavia prenderemo in esame il solo ciclo a 15 ms e, scelta un'opportuna finestra impostabile come la precedente, calcoleremo per ogni iniezione la retta di interpolazione dei minimi quadrati, che meglio approssima l'andamento dei campioni acquisiti. Di ogni retta calcoleremo la pendenza e effettueremo poi la media statistica dei valori ricavati. Anche se funzionalmente al test Mlift risulta utile il solo valore relativo al sensore S2 così ricavato, abbiamo implementato l'algoritmo per entrambi i

sensori, essenzialmente per intenti di controllo. In figura 3.16 mostriamo la sola implementazione relativa ad S2 per motivi di brevità, essendo l'altra del tutto equivalente.

Fig 3.16 Schema a blocchi per il calcolo del parametro Mlift: si nota la modalità in cui si ottiene la pendenza della retta di interpolazione dal numero di campioni e dall'intervallo di tempo di calcolo

Grazie a queste procedure calcoleremo quindi due parametri; MliftS2 e MliftS1 che si andranno ad aggiungere ai sei precedentemente calcolati. Tutti verranno visualizzati sul pannello principale del software una volta concluse tutte le iniezioni necessarie al test.

A questo punto possediamo tutti i valori necessari alla determinazione della validità del compensatore sotto esame.

Questi valori vengono utilizzati nella cosiddetta fase di post processing nella quale sono effettuate le verifiche richieste dal test dinamico, ovvero:

 2 μm<S27ms<6 μm;  S115ms>0,8*S17ms;  0<MliftS2<0,15 μm/ms.

Qualora tutte le condizioni siano verificate il componente sarà valido; dovremo quindi accendere l'indicatore di Good o quello di Fail sul pannello principale e, allo stesso tempo, aggiornare le statistiche a pannello che forniscono una indicazione rapida sul numero di pezzi processati, gli scarti, e sulle cause che hanno portato a scartare il componente. Da notare come l'esito complessivo del test venga salvato in una variabile globale denominata LabviewGoodPart. Notiamo come venga anche visualizzato il valore MliftS1 che di fatto non viene utilizzato in

nessun test. La spiegazione di ciò è da ricercarsi in motivazioni essenzialmente legate ad un controllo: infatti, dato l'allungamento supposto costante e dipendente dalla sola energia di eccitazione del piezostack, i due valori di Mlift dovrebbero, idealmente, essere uguali. In realtà ciò non avviene per motivi essenzialmente legati ai molti disturbi e al fatto che effettuiamo una media su un numero, per quanto significativo, comunque finito di iniezioni. Ci accontentiamo dunque che i due valori citati precedentemente risultino almeno dello stesso ordine di grandezza e, qualora ciò non avvenga, questo aspetto rappresenta l'indicazione di un sicuro problema durante il test.

Fig 3.17 Diagramma a blocchi inerente l'esito del test e l'elaborazione delle statistiche: nel frame di sinistra abbiamo la funzione di "and" logico fra le varie condizioni, in quello di destra l'aggiornamento del vettore delle statistiche

Le statistiche, come si nota, vengono immagazzinate in un vettore che viene visualizzato entrando, tramite il pannello principale, nella schermata Report Mlift and statistics. Inoltre la variabile Labview Good Part verrà inviata tramite il task digitalOUT al PLC, in modo che esso possa comprendere l'esito del test e decidere se mantenere il componente sulla linea o attivare la procedura di inserimento fra gli scarti. Risulta infine chiaro dal diagramma come l'esito del test sia influenzato anche da eventuali errori riscontrati durante l'elaborazione; infatti il risultato della prova è negativo non solo in conseguenza del fallimento del test ma anche di un errore ad esempio sul calcolo dell'offset di uno dei sensori di posizione, oppure in caso di danneggiamento del piezostack. Questa soluzione è stata implementata principalmente per motivi di carattere qualitativo: risulta chiaro come in tutte queste situazioni l'esito del test dinamico non sia attendibile e come, per questo motivo, il componente sotto test venga scartato per fini cautelativi. Non è infatti accettabile che un componente potenzialmente difettoso prosegua nel processo produttivo; di conseguenza secondo le procedure aziendali in queste situazioni il componente dovrà essere sottoposto ad un reworking per determinarne la corretta destinazione.

Damaged, Error Offset Sombrero, Error Offset Valve. Partendo dal presupposto che tutti e tre

risultano molto utili da un punto di vista diagnostico, vediamoli più nel dettaglio.

Il primo ci informa essenzialmente che il piezostack dell'attrezzatura di test risulta essere danneggiato; ciò può accadere in conseguenza di crash meccanici avvenuti sulle stazioni oppure ad un prolungato utilizzo del componente che ne abbia deteriorato il comportamento. In entrambi i casi il test non risulta veritiero e quindi è indispensabile intervenire sull'attrezzatura meccanica per rimuovere le cause del problema. A tal fine sul pannello è presente un indicatore che indica la somma dei valori misurati dai sensori S1 ed S2 in entrambi i test. Queste somme in fase di post process verranno confrontate con un valore impostabile mediante il Pannello di Sistema. Qualora una di esse risulti inferiore a tale valore il led presente sul main panel nel riquadro degli errori inizierà a lampeggiare e avremo contestualmente l'invio dell'informazione al PLC che provvederà a interrompere il normale flusso delle operazioni attendendo l'intervento di manutenzione. In seguito a tale intervento (presumibilmente la sostituzione del piezostack danneggiato) dovremo premere il pulsante Reset che ripristinerà lo stato attivo della stazione. Per quanto riguarda gli errori sugli offset, il controllo viene effettuato sulle medie rilevate e visualizzate e i valori minimo e massimo impostabili. Questi sono stati impostati rispettivamente a 150 μm e a 400 μm in modo da far lavorare i sensori nella zona centrale della dinamica ed evitando così le distorsioni del fondo scala. Per quanto riguarda gli effetti esterni il comportamento è del tutto analogo a quello evidenziato per l'errore precedente e tipicamente l'intervento di manutenzione da effettuare riguarderà l'avvicinamento o l'allontanamento dal bersaglio del sensore coinvolto. In aggiunta a ciò nel caso di questi errori, in base alle richieste, è stato inserita anche una finestra di messaggio di errore visualizzata a schermo.

In figura 3.18 mostriamo la gestione degli errori sopra indicati esplicitando totalmente per brevità soltanto quella relativa al Piezo Damaged. In figura si nota anche il VI SubLabViewReady che ha la funzione di comunicare un avvenuto errore al PLC.

Fig 3.18 Schema a blocchi relativo alla gestione degli errori

Con queste osservazioni concludiamo la sezione relativa all'elaborazione dei dati; ovviamente ciò che è stato indicato in questa parte rappresenta solo i concetti base. La fase dell'elaborazione ha richiesto un notevole impegno soprattutto per la notevole mole di dati che devono essere trattati ed, oltre agli aspetti visti, sono state necessarie molte misure aggiuntive che non includiamo per motivi di brevità dato che non aggiungono aspetti concettualmente rilevanti alla trattazione.

3.2.3 Gestione dei file di input/output

Questa parte del software riveste una notevole importanza principalmente per due aspetti: da un lato la fruibilità del software stesso che non deve prevedere ad ogni riavvio la necessità di reinserire i parametri necessari al test; dall'altro un semplice monitoraggio degli output del test dinamico. Concentriamoci inizialmente su quest'ultimo aspetto. Come già affermato, il progetto del Piezo Injector si trova all'interno della fase di startup e per questo motivo dobbiamo sia mandare avanti una produzione che risulti qualitativamente accettabile, sia sviluppare il processo

di misura complesso come il nostro ha bisogno prima di funzionare a regime. Un duplice intento che rende necessaria una continua osservazione dei dati di uscita del test in modo da controllarne anche l'affidabilità mediante operazioni di confronto con strumenti che possiamo considerare campione. Si pensi ad esempio che un non perfetto settaggio della molla di carico (vedi paragrafo 3.1.2), può provocare una notevole deriva della misura. Si pensi ad esempio che con una molla impostata a 110 N anziché a 120 N abbiamo osservato delle variazioni sulla perdita di corse del compensatore termico sul ciclo di 7 ms anche pari ad 1 μm, valore inaccettabile se si pensa che rappresenta il 25% dell'intervallo di tolleranza (fra 2 e 6 μm).

Dopo la necessaria premessa, passiamo ad osservare come siano stati gestiti gli input del software in base alle esigenze mostrate. Tali input sono molteplici e riguardano sia aspetti necessari ad un corretto svolgimento del test (limiti di validità dei test, parametri di sistema), sia aspetti più legati ad un semplice utilizzo del software (percorsi nei quali salvare gli output o nei quali ritrovare gli input). La procedura seguita è stata la stessa per tutte queste necessità e noi andremo in maniera del tutto equivalente ad illustrare quelle relativa ai parametri di sistema. Parlando dell'interfaccia grafica ci siamo soffermati sul System Panel (paragrafo 3.2.1) e sul salvataggio dei parametri nella variabile globale opportuna. Tutta la procedura si basa sull'utilizzo di due VI opportunamente sviluppati: PanelSystem.vi e SubLadeSYS.vi. Il primo manda in esecuzione il pannello di sistema ed effettua il salvataggio dei dati inseriti dall'utente, mentre il secondo ha una duplice funzione: da un lato costruisce il percorso del file

SYSParameter.xls nel quale sono contenuti i parametri, dall'altro ne va a leggere il contenuto

salvandolo nel vettore di valori che sarà poi passato alla variabile globale. Queste procedure sono più chiare se si osservano i diagrammi a blocchi dei due VI contenuti all'interno della figura 3.19. Possiamo notare come a causa della sua duplice funzione SubLadeSYS.vi venga richiamato anche all'interno dell'altro proprio nella sua funzione di costruzione del percorso.

Fig 3.19 Schema a blocchi riguardante il recupero e salvataggio dei parametri di sistema

Osservando lo schema si nota come il contenuto del file SYSParameter.xls venga preventivamente cancellato ogni volta che si inseriscono dei nuovi dati. Tale procedura serve essenzialmente a prevenire che avvengano sovrapposizioni fra dati affini pregiudicando il salvataggio dei valori e il successivo recupero degli stessi mediante la opportuna procedura. Tale recupero avviene mediante l'opportuna primitiva Labview denominata Read From Spreedheet

File.vi, che si presta particolarmente alla lettura dei dati e al loro successivo inserimento in

Passiamo adesso a parlare della gestione degli output. In fase di definizione delle specifiche è stato chiesto che i risultati numerici del test venissero salvati in un opportuno formato e che fossero manipolabili mediante un software adatto alla loro elaborazione, in particolare Microsoft

Excel. Altra specifica richiesta è stata che venisse generato un file che includesse i risultati di

tutti i test dinamici effettuati durante una giornata. Si è quindi scelto di nominare questi file proprio con la data che risulta automaticamente reperibile grazie ad un'opportuna primitiva dell'ambiente di sviluppo. Per prima cosa è stato quindi necessario creare l'opportuno file, riuscendo a capire la necessità di crearlo ex novo oppure di aggiungere i nuovi dati ad uno già esistente. Tale operazione è stata svolta da un opportuno VI le cui caratteristiche sono esplicitate dal seguente diagramma a blocchi di figura 3.20.

Fig 3.20 Schema a blocchi del VI dedicato alla creazione del nome del file di salvataggio dei dati

Come si nota il VI in questione si occupa anche della creazione di una stringa opportunamente formattata contenente gli output numerici da archiviare. I vari valori vengono convertiti in stringhe e separati da tabulatore in modo che vengano inseriti in celle adiacenti una volta aperti mediante Microsoft Excel. Alla fine dei valori è inserito un carattere di ritorno carrello per preparare il file all'inserimento di una nuova stringa relativa al pezzo successivo. Questi valori vengono passati al blocco successivo nel quale si ha la creazione del percorso relativo al file di

salvataggio estratto dalla variabile globale relativa ai percorsi, oltre che la formattazione dell'intestazione del file ovviamente eseguita solo nel caso del primo inserimento giornaliero. Tale blocco è mostrato nella figura successiva (3.21) che mette in evidenza anche il numero di cifre decimali scelte per passare i dati al file. Si noti anche come la scrittura o meno dell'intestazione sia inserita all'interno di un case che è a sua volta comandato da un valore logico che varia semplicemente dipendentemente dall'esistenza del file caratterizzato dalla data corrente.

Fig 3.21 Schema a blocchi relativo alla scrittura dei dati su file

3.2.4 Data collection

Abbiamo già parlato delle motivazioni e dell'importanza del data collection; adesso invece ci soffermeremo sulle problematiche riscontrate nell'implementazione di tale funzionalità e sui modi attraverso i quali tali problematiche siano state effettivamente risolte. Innanzitutto ricordiamo le specifiche: il PLC è provvisto di procedure ormai consolidate che gli consentono, mediante opportune librerie, di prelevare dei dati che siano salvati all'interno di variabili del software delle presse di precisione. Come ricordiamo tale software si trova all'interno del Driver

PC, mentre i dati che noi vogliamo trasmettere al PLC stesso si trovano, alla fine della procedura

utilizzare la connessione mediante scheda di rete presente fra i due calcolatori. Allora si è deciso di seguire la seguente procedura, formata da tre passi:

 fare in modo che il software Labview presente sul PC di analisi aprisse una connessione di rete secondo il protocollo TCP/IP e inviasse i dati da passare al PLC sfruttando il canale creato;

 ricevere i dati inviati sul Driver PC mediante un ulteriore applicativo Labview opportunamente creato che provvedesse a salvare tali dati in apposite variabili;

 passare questi dati mediante una libreria OCX al software delle presse, facendo in modo che venissero salvati in variabili non occupate dal programma già presente.

Nello sviluppare questa procedura la creazione della libreria OCX è stata svolta da esperti del software della presse, mentre noi ci siamo concentrati sull'implementazione dell'applicativo

Labview necessario alla raccolta dei dati provenienti dal PC di analisi. La richiesta fatta è stata la

seguente: riuscire ad immagazzinare cinque valori (vedremo successivamente quali) in altrettante variabili numerate da 3 a 7. Per il resto siamo stati liberi di seguire una qualsiasi procedura, ad esempio in termini di caratteri di separazione dei vari valori.

Vediamo adesso in maniera più dettagliata come l'invio e la ricezione siano stati effettivamente realizzati cominciando dal software del test dinamico, responsabile della gestione del canale di comunicazione oltre che dell'invio dei dati. Cominciamo col dire che la funzionalità può essere mantenuta o meno abilitata e che i vari parametri necessari al corretto passaggio dati possono essere settati mediante un opportuno pannello, nella gestione del tutto equivalente a quelli visti finora, come ad esempio quello dei parametri di sistema. Tale pannello è mostrato in figura 3.22 e, come si può notare, fa uso dei cosiddetti ring ovvero di strutture messe a disposizione dall'ambiente di sviluppo, consistenti essenzialmente in scelte multiple, particolarmente utili per evitare errori di digitazione che potrebbero risultare critici. Ad esempio un errore nella scelta del numero della stazione avrebbe conseguenze disastrose: rischieremmo di scambiare le statistiche di una stazione con quelle di un'altra e quindi di approntare ad esempio modifiche non necessarie all'attrezzatura meccanica.

Fig 3.22 Pannello frontale per l'impostazione dei parametri di connessione

In questo pannello è possibile impostare l'indirizzo IP del Driver PC a cui inviare i dati, la porta da utilizzare per la connessione e il numero della stazione, oltre alla possibilità di attivare o meno la funzione di invio dati. Questi valori verranno salvati all'interno di opportune variabili globali che verranno richiamate all'interno del VI denominato SendValues.vi, il cui diagramma a blocchi è riportato in figura 3.23.

Si può vedere come effettivamente sia questo blocco a gestire tutta la connessione, a partire dall'apertura del canale fino alla chiusura dello stesso. Nella parte centrale vediamo come la stringa da inviare venga generata in un opportuno VI che, tra i vari valori prodotti e scritti nelle variabili globali, andrà a scegliere quelli che debbano effettivamente arrivare al PLC. Lo stesso

VI si occuperà della formattazione della nostra stringa anche in termini di cifre decimali, aspetto

qua non trascurabile per il corretto dimensionamento del pacchetto dati da inviare tramite la connessione. Possiamo infine notare il controllo che ci permette di disattivare l'intera funzionalità. Qualora infatti la variabile Send sia a 0, nessuno dei case viene eseguito, lasciando di fatto l'intero VI disabilitato.

Tutto questo ci permette in effetti di inviare i dati; ma essi dovranno essere anche essere ricevuti, ovvero dovremo fare in modo che un altro opportuno applicativo sia in grado di "ascoltare" eventuali connessioni TCP/IP attive e ricevere i dati, evitando tra l'altro la visualizzazione di errori di Timeout sul pannello del software di test dinamico. Questo applicativo è stato effettivamente implementato ed ha preso il nome di DynamicToPromess, dal momento che ha il compito di passare i risultati del Dynamic Test al software delle presse di precisione, il cui produttore è appunto Promess. Nella figura successiva, la 3.24, vediamo il pannello del

DynamicToPromess che andremo adesso a descrivere nelle sue caratteristiche principali.

In alto possiamo notare la presenza di una spia a forma di L.E.D. che indica l'apertura della libreria OCX che stabilisce la comunicazione col software della pressa. Questo aspetto è ovviamente fondamentale per il corretto funzionamento della comunicazione. Sempre nel pannello troviamo, oltre ad informazioni quali un numero progressivo che caratterizza i componenti e la data dei test, anche i valori da comunicare al PLC memorizzati nelle variabili da 3 a 7. Tali numeri di variabili saranno quelli effettivamente utilizzati sul programma delle presse, essendo i valori 1 e 2 già utilizzati per altri scopi durante il ciclo del test dinamico (vanno a contenere due valori di forza tra cui in variabile 2 quello di settaggio della camera di test). I valori passati sono essenzialmente le letture dei sensori S1 ed S2 in entrambi i cicli di test, nonché il valore del parametro Mlift. In questo modo sul PLC si riuscirà a capire, una volta riscontrata la presenza di uno scarto, a quale dei valori registrati sia effettivamente dovuto. Sempre sul pannello si nota anche la presenza di una stringa data read; l'utilità di questo indicatore sta nel riuscire a visualizzare quale sia la stringa complessivamente inviata dal programma di analisi, in modo da poter monitorare di fatto il numero di byte complessivi inviati (con la ovvia corrispondenza di un carattere pari ad 1 byte).

Passiamo adesso ad analizzare il funzionamento del software di ricezione dei dati. Se osserviamo il suo diagramma a blocchi possiamo vedere come, dopo una prima fase di inizializzazione delle varie variabili, si vada ad eseguire la libreria OCX necessaria alla comunicazione con il software delle presse. Se l'apertura arriva a buon fine allora il led sul pannello si accende ed, in presenza del pulsante Active acceso, avviene la lettura dalla connessione aperta dal software di invio. Tale lettura avviene grazie alla procedura realizzata tramite il diagramma a blocchi di figura 3.25. Tale diagramma rappresenta il fulcro del programma di ricezione ed è stato realizzato dopo numerosi tentativi che incontravano dei problemi soprattutto per motivi di temporizzazione e di sincronizzazione. Essi sono stati risolti con l'utilizzo di un sistema di fatto di invio e attesa di ricezione lasciando al software d'analisi la responsabilità pressoché totale del corretto funzionamento della comunicazione.

Cerchiamo di evidenziare le caratteristiche principali di questo blocco. Vediamo come per prima cosa vengano ascoltate eventuali connessioni presenti sulla porta specificata che dovrà essere, naturalmente, la stessa settata sul programma di invio dei dati.

Fig 3.25 Diagramma a blocchi che implementa la lettura di connessione

Qualora non avvengano errori, ovvero se la connessione viene rilevata senza problemi andiamo, grazie alla primitiva TCP/IP read, a leggere i dati inviati. Abbiamo scelto di indicare una dimensione massima di 512 byte, un timeout di 500 ms, oltre alla modalità CRLF. Essenzialmente quest'ultima caratteristica significa che la fine di un pacchetto di invio è evidenziata da un ritorno carrello seguito da una tabulazione. Se non arriva questo segnale entro 500 ms dalla richiesta di primitiva, l'operazione di lettura fallisce e viene restituito un messaggio di errore a pannello. Se tutto funziona correttamente la stringa letta viene estratta e passata ai blocchi successivi in cui verrà formattata opportunamente. In particolare avremo delle primitive che riconosceranno il carattere ";" utilizzato come separatore e andranno a separare le stringhe inviate proprio in corrispondenza del suddetto carattere. Saranno quindi create le variabili così come verranno passate al programma della pressa. Infine la libreria provvederà a trasferirle nel modo opportuno così come è evidenziato nel diagramma a blocchi di figura 3.26. Infine dei led posti in alto al pannello andranno ad evidenziare attività sulla connessione permettendo un controllo visivo utile soprattutto in fase di debug al momento della ricezione delle informazioni.

Fig 3.26 Procedura di passaggio dei dati al software della pressa

Con queste considerazioni abbiamo concluso la parte relativa all'implementazione del test dinamico. Nel capitolo successivo mostreremo le elaborazioni statistiche dei dati ricavati dal nostro test, andando a valutare questi dati sia da un punto di vista "sperimentale", per valutare la bontà del sistema di misura da noi progettato, sia dal punto di vista dello studio del processo. Un'attenta analisi statistica dei risultati permette infatti di andare a capire se esistono problemi ad un certo livello del processo produttivo e, se tali dati vengono correttamente interpretati, si possono anche trovare le giuste misure correttive. Infatti un processo produttivo complesso e tecnologicamente avanzato come il nostro, ha continuamente bisogno di questo monitoraggio, dato che le operazioni di miglioramento e di messa a punto sono di fatto quotidiane.