La generazione del report di un processo di calibrazione `e fondamentale per informare l’utente sull’esito della calibrazione delle varie mappe e curve e anche dei singoli brea- kpoints, pertanto dopo opportuni test condotti su VI separati si `e scelto di generare un report di tipo xls, visualizzabile ed eventualmente modificabile con Excel ma anche con un qualsiasi editor di testo. LabVIEW mette a disposizione una libreria per la generazio- ne e la modifica di report di processo, e per`o tutti i blocchi che ne fanno parte richiedono la dipendenza da controlli ActiveX che purtroppo non sono supportati dal PC realtime; pertanto si `e deciso di scrivere il contenuto del report come se si trattasse di un semplice file di testo, tramite il blocco ‘Write to Text File’.
A tale scopo si `e pensato di creare un SubVI polimorfico in grado di gestire completa- mente tutte le azioni relative al report, di cui in figura 4.22 `e riportato il block diagram; tale scelta `e stata dettata da diverse ragioni, tra cui la flessibilit`a di uso, dato che con un SubVI `e possibile gestire pi`u operazioni con uno stesso blocco, e la necessit`a di implementare la generazione di un report anche per il tool di calibrazione del controllo Lambda, per il quale, come si vedr`a nel seguito, verr`a riutilizzato in toto il SubVI qui descritto previe opportune modifiche.
Figura 4.22: SubVI per la gestione del report di calibrazione
Il SubVI ‘CreateTextReport’ `e costituito da una case structure principale comandata dall’enum ‘Action’, in alto a destra; gli input del SubVI sono tutti i controlli visibili alla
sinistra della case structure, mentre gli output sono tutti gli indicatori posti alla sua de- stra. I vari input verranno brevemente accennati nel seguito della trattazione, e tuttavia vale la pena identificarne almeno due di fondamentale importanza: ‘File’, che `e una va- riabile di tipo stringa contenente il percorso di salvataggio e il nome del report generato, e ‘RefnumIn’, ovvero il puntatore al file stesso; si fa notare, e ci`o verr`a spiegato pi`u avan- ti, che ‘RefnumIn’ viene passato anche come output del SubVI, nel qual caso si chiama ovviamente ‘RefnumOut’. Questo SubVI `e in grado di gestire da solo tutte le operazioni relative al report di calibrazione, dalla sua creazione, alla sua modifica, alla sua chiusura, e la scelta dell’operazione da compiere viene effettuata impostando l’input ‘Action’ in uno dei seguenti stati:
• Create report: apre il file passato come input ed inserisce il frontespizio, la data e l’ora di creazione; in questo caso l’unico input al SubVI `e il percorso di salvataggio del report. Questa azione verr`a inserita nel VI principale, precisamente nello stato ‘Download Configuration File’ della macchina a stati 1;
• Save base maps: le mappe di default preesistenti in ECU vengono scritte nel report di calibrazione; gli input al SubVI sono il puntatore al file, il cluster di errore e le mappe base sotto forma di dato variant. Questa azione verr`a inserita nello stato ‘BackupECUDefaultMaps’ della macchina a stati 1;
• Add breakpoint: questo stato aggiorna il report ogni volta che viene calibrato un breakpoint, aggiungendo al valore di guadagno determinato anche l’eventuale pre- senza di warning. Gli input al SubVI sono diversi; escludendo i soliti puntatore e cluster di errore, pu`o valere la pena elencare gli altri uno per uno:
– valore di RPM corrispondente al breakpoint attuale;
– valore di temperatura dell’olio corrispondente al breakpoint attuale; – valore di angolo VVT target corrispondente al breakpoint attuale; – valore di tensione batteria corrispondente al breakpoint attuale; – valore di guadagno determinato corrispondente al breakpoint attuale;
– indice del breakpoint appena calibrato: `e il contatore principale dei breakpoint presente nella macchina a stati 3;
– parametro attualmente in calibrazione;
– booleano che indica se il breakpoint attuale `e il primo della curva o della mappa ad essere calibrato;
– booleano che indica se la calibrazione del breakpoint corrente `e andata a buon fine oppure il codice di analisi dati ha restituito un warning.
`
E chiaro che dei primi quattro input elencati verranno scelti solo quelli relativi al pa- rametro che si sta calibrando; per VBATCOMP, ad esempio, si utilizzer`a la tensione batteria e il regime motore, mentre per KIMAP si utilizzer`a il regime motore e la temperatura dell’olio. Questa azione andr`a inserita in tutti gli stati ‘Check results’ o ‘Interpolation’ delle macchine a stati 3 pi`u interne;
• Compare maps: confronta, riportandole fianco a fianco, le mappe e le curve preesi- stenti in centralina prima della calibrazione con le mappe e le curve ottenute dopo il processo di calibrazione; l’unico altro input, oltre ai soliti puntatore e cluster di errore, `e costituito da una variabile di tipo variant che verr`a descritta nel seguito. Questa azione verr`a inserita nello stato ‘Upload calibration’ della macchina a sta- ti 1, avendo cura di eseguirlo per`o solo al termine dell’intero processo, dopo aver calibrato tutte le mappe e le curve previste;
• Dispose report: questa azione riceve in input il puntatore al report e il cluster di errore per chiudere il file di testo, e verr`a inserita nello stato ‘End of calibration’ della macchina a stati 1.
Si `e parlato poco sopra di un input di tipo variant: in Lab- VIEW le variabili variant rappresentano un tipo di dato che comprende sia un valore (numerico, booleano, stringa o altro) sia i metadati necessari all’interpretazione del valore stesso. In pratica una variabile variant pu`o contenere qualunque tipo di dato standard o definito dall’utente, e si adatta molto bene ai
VI per i quali gli input variano a seconda della funzione che essi devono compiere, con- sentendo cos`ı al programmatore di realizzare un unico VI in grado di decodificare diversi input invece che tanti VI diversi, con notevole risparmio di spazio e incremento di effi- cienza. Nel nostro caso la variabile ‘Variant’ rappresentata in figura 4.22 viene utilizzata, come visto, sia dal caso ‘Save base maps’ sia dal caso ‘Compare maps’: per il primo, essa contiene un array monodimensionale di cluster costituiti da una stringa, indicante il nome della mappa, due vettori di stringhe, contenenti i breakpoints, e una matrice, contenente i valori della mappa, come si pu`o vedere nella figura a destra; per il secondo, essa contiene un array bidimensionale degli stessi cluster appena definiti, dato che il caso ‘Compare maps’ effettua un confronto tra le mappe precedenti e successive alla calibrazione e per- tanto si `e pensato di aggiungere una dimensione all’array di cluster in modo da consentire l’affiancamento delle varie mappe.
Un’ultima considerazione sulle variabili di tipo variant: come accennato, esse richie- dono un’interpretazione del loro contenuto prima di poterlo utilizzare nel codice, e per- tanto per decodificare una variabile variant `e necessario impiegare il blocco ‘Variant to
Data’, visibile anch’esso nella figura in alto a sinistra, al quale `e necessario passare in input un oggetto che definisca la struttura della variabile che si sta decifrando. Nel nostro caso, come si pu`o vedere, si `e passato proprio l’array di cluster che rappresenta le varie mappe.
Figura 4.23: Codice per la creazione del report
Figura 4.24: Codice per l’aggiunta di un breakpoint calibrato al report
Le figure 4.23 e 4.24 mostrano rispettivamente l’utilizzo del SubVI ‘CreateTextRe- port’ per generare un nuovo report e per aggiungere un breakpoint appena calibrato. `E interessante notare che in entrambi i casi gli output del SubVI, quello verde in alto corri- spondente al puntatore del file e quello giallo in basso corrispondente al cluster di errore, alimentano due shift registers del timed loop principale, e non solo: nella figura 4.24 si vede che anche due input del SubVI, sempre corrispondenti al puntatore del report e al cluster di errore, provengono dagli stessi shift registers di cui sopra, inizializzati con due costanti. Questa logica si `e resa necessaria dal momento che, una volta aperto il report, per poter aggiungere in esso ulteriori righe di testo senza sovrascrivere l’intero file bisogna- va passare in input al SubVI sempre lo stesso puntatore: si capisce quindi che l’utilizzo degli shift registers era decisamente appropriato allo scopo, tanto pi`u che cos`ı facendo si ha la certezza di lavorare sempre sul report aggiornato dato che il contenuto del file rimane sempre nella memoria del PC e viene aggiornato ad ogni iterazione del timed loop principale, ovvero ogni 10 millisecondi.