La legge di Murphy

Recita la prima legge di Murphy: Se qualcosa può andar male, lo farà.
I primi due corollari sono:
1) Niente è facile come sembra;
2) Tutto richiede più tempo di quanto si pensi.
Come avrete intuito qualcosa non è andato per il verso giusto, ed è a questo punto che mi sento di sottoscrivere pienamente il postulato di Boling: Se sei di buon umore, non ti preoccupare, ti passera'. Anche la seconda legge di Crisholm fa al caso, visto che: Quando tutto va bene, qualcosa andra' male.
Stò parlando della comunicazione seriale. La ricezione di dati dal commutatore non è poi così facile da eseguire come sembrava, o almeno non lo è per me. Il problema è che quando mando il comando di lettura dello stato del commutatore (stat), perdo la prima ricezione di dati. Anche se utilizzo Mscomm1_onComm(), ovvero l'oggetto che si attiva su evento dalla seriale, il programma continua il suo flusso e perdo la stringa. Purtroppo non ho avuto tempo per risolvere la questione ma credo che il problema sia anche nel firmware. Quando mando il comando (stat) al commutatore, questo mi restituisce i parametri scritti in EEprom, ovvero il call e nome operatore, il nome che abbiamo assegnato ad ogni relè e quale relè attivare in base alla banda del TX. Il micro invia ogni singolo parametro come un pacchetto, quindi con un inizio ed una fine, e forse è proprio questo il motivo percui perdo la prima ricezione, forse l'evento vede una pausa e continua l'elaborazione del resto del codice .
La prossima prova sarà di creare una stringa unica con tutti i parametri ed inviarla al pc così, quando l'evento la riceve, finchè non la riceve completamente non restituisce il controllo al software.
Spero che l'evento funzioni così. Con il compilatore basic per il micro esiste un comando che mette in stand-by l'esecuzione del programma finchè non finisce di ricevere dalla seriale, e questo mi permette di ricevere senza errori.
Questa mattina, facendo ulteriori prove ho trovato delle soluzioni poco ortodosse che non mi sono piaciute sopratutto come filosofia di programazione. Attualmente per ovviare al problema aspetto finchè non riceve l'ultimo pacchetto e poi genero un evento a livello di Form, a quel punto elaboro la stringa ricevuta e la utilizzo nel codice. Scritta così potrebbe anche sembrare una soluzione passabile, ma vi assicuro che è un accrocchio.
Ho bisogno di dominare pienamente la comunicazione con dispositivi esterni, anche in previsione di futuri progetti e quindi ho bisogno di creare del codice "riutilizzabile", che non sia fine alla risoluzione di un solo caso.
Questa mattina ho lasciato il PC installando VisualBasic 2008, ho intenzione di fare delle prove anche se quasi sicuramente finiro il programma con il VB6. Le prove fatte un paio di anni fà con VB2005 non erano state positive e a malinquore mi ero visto costretto a ritornare al VB6. Il problema principale fu su ADO, non riuscii a comprenderne la filosofia di funzionamento e la nuova gestione dei record. Vedremo come va con questo.
Concludo citando la seconda legge di Scott: Quando si trova e si corregge un errore, si vedra' che andava meglio prima.
Beh, speriamo non sia così ;-)