"Embedded in the mud, glistening green and gold and black, was a butterfly, very beautiful and very dead. “Not a little thing like that! Not a butterfly!” cried Eckels. "

A Sound of Thunder by Ray Bradbury

Le temporizzazioni interne per un controllo motore sono vitali, di solito avvengono attraverso gli efficaci interrupt sul timer, ma visto che ne ero sprovvisto implementai un uKernel per gestire delle pseudo task cooperative ( che a me piace dire di tipo Round Robin). Questo tipo di ausilio mi ha permesso di avere delle sezioni di codice che venivano richiamate con tempi predefiniti e che per esempio mi permettevano di gestire la macchina a stati per eseguire le rampe di velocità e nello stesso tempo di tenere sotto controllo il segnale di tachimetrica che doveva essere letta in polling dal core del uKernel.

Sulla tachimetrica poi c’era un altro problema legato all’ampio range di misura. In questi motori il segnale proviene da tre magneti calettati sull’albero motore che creano a loro volta 3 periodi di tachimetrica ad ogni giro. A frequenze molto basse la lettura viene fatta a periodimetro ( misura del tempo fra i fronti ) ma con l’aumentare della frequenza la risoluzione del mio timer diminuisce e quindi bisogna switchare on fly ( mamma mia che termini... ) la lettura in modalità frequenzimetro ( apertura di una finestra a tempo e conteggio dei fronti ). Questa operazione, molto delicata, deve essere fatta cercando di mantenere una certa linearità sulla risoluzione per non avere altri effetti infausti nel controllo PID.

La modalità di innesco a taglio di fase consiste nell’attivare il gate ( magari con una tripletta di zippilli ) del triac, nel tempo stabilito dal nostro PID ( o dalla nostra rampa iniziale ), all’ interno della nostra semionda di rete. Il disinnesco del triac avviene al prossimo cross sullo zero della corrente. La fase della corrente, rispetto a quella della tensione, ovviamente è sfasata di qualche grado per la grossa induttanza del motore stesso e così si doveva fare un po’ di attenzione al prossimo innesco... Questo era un elemento importante di non linearità nel controllo, ma c’era anche un altro fattore di non linearità, che era dovuto appunto al momento di innesco del triac, considerando la variazione non uniforme di tensione fra un innesco e l’altro nelle varie parti della semionda

Guardavo la serie di moduli che assemblati insieme avrebbero creato il mio programma, non erano molti, una decina in tutto. Sarebbero stati almeno la metà se non li avessi infarciti con tante dichiarazioni, definizioni, rimandi. Per non parlare poi dello spazio preso dai commenti sempre molto generosi ( e un po' prolissi... ). In una directory a parte qualche file mathcad con dentro un po' di analisi sulla tachimetrica sugli errori, un documentino sul filtro di Kalman e i suoi miracoli. I datasheet non erano molti, il micro, l’operazionale usato sulla tachimetrica, qualche fotocopia di una rivista americana illegibile sui motori e le loro caratteristiche elettriche e meccaniche. In un file di history dove descrivevo tutto quello che facevo e che era un po’ il diario giornaliero delle mie esperienze. Come editor utilizzavo quello della Norton perchè era l’unico che aveva la ricerca di stringhe su gruppi di file.

Ora con l’oscilloscopio leggere l’attivazione del triac era problematico, si riusciva a vedere qualcosa solo se mi triggeravo sulla tachimetrica, ma questa diventava leggibile solo dopo un bel po’ di periodi di rete. Fortunatamente però era uno dei primi oscilloscopi digitali e così dal trigger potevo tornare indietro e vedere la mia rampa. Con questo tipo di oscilloscopi si doveva fare attenzione all’Aliasing ma questo tipo di problema lo avevamo solo leggendo segnali di frequenza molto alta...
Gli inneschi erano graduali lineari perfetti e tutto questo accadeva mentre la tachimetrica prendeva forma. Niente spike né disturbi di nessun altro genere, il problema poteva capitare all’inizio della accensione o dopo decine di cicli di rete o dopo svariati minuti... ma ( e c'è sempre un ma.... ) prima o poi capitava inevitabilmente. Così passai quella mattinata osservando la ruota del cestello che faceva avanti e indietro alzando ed abbassando il trigger dell’oscilloscopio, aumentando e diminuendo i valori di innesco nella rampa, modificando il carico del cestello … e via andare accumulando un insieme di prove tante volte scorrelate ma che insieme potevano aiutarmi.

In uno di quei giorni perduto fra i miei test, per errore, misi tutto il sistema sotto gruppo di continuità, dopo un po' fusi tutto. La puzza e i colleghi che mi presero ( giustamente ) per il culo, ci volle un po’ a passare...
Ogni tanto mi alzavo, Alfio aveva da poco installato la rete aziendale, per raggiungere un pc nella scrivania a fianco dove stavo provando una delle distribuzioni Linux, e ricordo che dovevo cercare il manuale del monitor, per sapere il valore delle frequenze di sincronismo verticale e orizzontale... adeguatamente avvertito che se per caso sbagliavo l’impostazione il monitor si sarebbe danneggiato irreparabilmente... (... altri tempi )

E intanto il motore girava, prima a sinistra, poi a destra e poi quel fastidioso strappo.
Guardavo l’oscilloscopio e poi lo strappo.
Presi la traccia dei zippilli sul triac e la sovrapposi alla traccia di innesco del triac.
Il taglio di fase era evidente, dopo lo zippillo si vedeva la fase innescata. Tornai per l’ennesima volta indietro sino all’inizio, quando proprio in quel momeno mi accorsi di un elemento anomalo.
Tutta la rampa era perfetta tranne che per un elemento. Il primo zippillo di innesco del triac era troppo vicino dall’inizio della semionda di rete; e in quella condizione quella piccola parte di fase da 10 ms avrebbe alimentato il motore. Poteva questa essere la causa dello strappo? Poteva un'unica semionda dare abbastanza energia al motore per riuscire a strappare la tensione di quella cinghia? Un furioso brain storming si attivò perchè nella mia mente stavo trasformando quell’unico indizio in una prova. In quel momento l’analisi sul firmware si concentrò sulla variabile di innesco e da li a poco mi accorsi del baco. Quella variabile, nella fase di rampa controllata, non veniva inizializzata. Verificai che all’accensione del micro veniva correttamente inizializzata, ma le volte successive manteneva l’ultimo valore di innesco del triac. ( merd... scusate il francesismo ).
Così aggiunsi un paio di istruzioni per caricare il registro di ritardo del triac con un valore di default coerente.

movlw        STARTUP_TRIAC
movwf        Rit_Triac

La frequenza dello strappo era tale che potevo permettermi di verificare l’effetto della modifica per un paio di giorni e dopo che furono passati rilasciai la nuova release alla San Giorgio.
Per qualche motivo per me oscuro da lì a poco la ricca produzione per la azienda si avviò con vertiginosi lotti da cento moduli al giorno, e il mio capo cambiò la macchina passando da una thema turbo all’audi a8 ( beato lui... )