Laboratorio 1 - Database 2

Vi avevo avvertiti di restare sintonizzati perché sarei tornato presto a dirvi come era stato il nostro approccio al mondo del database. Il momento era maturo anche se forse avremmo dovuto aspettare una settimana in cui potevamo dedicarci maggior tempo e non solo qualche ritaglio qua e là.

Avrete già capito che sto cercando qualche piccola scusa per indorare la pillola, perché il primo impatto è stato equivalente ad una sconfitta. L'idea, ve la ripeto, è che il nostro software prenda tutte le informazioni di configurazione da un database e sempre verso lo stesso database ritorni le misure effettuate dagli strumenti per renderle accessibili a tutti gli interessati. Il piano è di usare una piattaforma seria e performante come Oracle, così ci ha suggerito il nostro esperto DBA, ma prima di affrontare il mostro ci ha anche suggerito di iniziare la progettazione delle tabelle usando qualcosa di più semplice, come Access, senza per questo perdere di generalità.

007: Licenza di spiare (le porte seriali e non solo)

In piena onestà, dobbiamo ammettere che oggi siamo dovuti ricorrere alla vile arma dello spionaggio. Tranquilli, nulla di illegale, si tratta solamente del nostro software che mira ad integrare sotto un unico cappello tanti strumenti di misura prodotti da case differenti che altrimenti funzionerebbero solo con il loro software specifico e in maniera indipendente.

Dopo un paio di mesi abbondandati che stiamo lavorando alla struttura generale del software e all'integrazione della prima famiglia di strumenti, oggi ci siamo ritrovati in una situazione imbarazzante. Il manuale dello strumento, che non è privo di errori e imprecisioni, si è dimenticato di dirci come far fare al dispositivo una procedura piuttosto importante. Sapevamo che poteva essere fatta perché il software in dotazione, di cui non abbiamo il codice sorgente, era in grado di farlo, quindi doveva esserci una via.

Missione sniffing

Il protocollo di comunicazione dello strumento in questione ormai è diventato la nostra seconda lingua. Quando vediamo una strisciata di doppietti esadecimali inviati o ricevuti dal macchina sappiamo subito capire di cosa sta parlando, anche perché altrimenti non avrebbe senso il titolo di questa rubrica. La soluzione più facile era "ascoltare" cosa diceva il computer allo strumento quando sul software proprietario pigiavamo il bottone corrispondente al comando incognito. Sì, ok, ma come? La comunicazione avviene su un cavo e non possiamo certo avvicinare l'orecchio.

Per questo genere di spionaggio, che in gergo tecnico prende il nome di sniffing, ci sono degli appositi pacchetti software, molto spesso specifici per una tipologia di comunicazione (ethernet, seriale, usb...) e anche gratuiti, che una volta installati sul pc sono in grado di catturare in modo passivo i pacchetti inviati e ricevuti attraverso quello specifico canale.

Detto fatto. Installato il programmino e avviata la modalità di registrazione, abbiamo cliccato sul bottone misterioso e siamo corsi a leggere cosa i due si erano detti. Un minuto dopo, anche il nostro software era in grado di farlo!

[LabVIEW] Consigli per una bella UI

Venerdì sera scorso ero un po' demoralizzato. Per quella giornata avevamo previsto di fare una piccola applicazione per leggere alcuni dati e mostrarli in modo chiaro e semplice agli utenti, ma non ci siamo riusciti. Non che il compito fosse troppo arduo, ma le troppe interruzioni e le urgenze avevano ridotto al minimo il tempo a nostra disposizione, così durante il week end ho investito un paio d'ore di riposo per fare quello che ci mancava.

Non è ancora finita, ma il grosso dell'applicazione è lì, anche perché il sabato e la domenica sono per la famiglia e non certo per il lavoro che già mi prende dal lunedì al venerdì.

Appena ho raggiunto lo scopo che mi ero prefissato per queste ore straordinarie, mi sono imbattuto in una bellissima playlist sul tubo di Simon Hogg con un buon numero di video-tutorial su come migliorare l'aspetto e la funzionalità delle interfacce utente sviluppate con LabVIEW. Incollo la playlist qui sotto...

LabVIEW ad oggetti

Sono particolarmente soddisfatto questa sera perché proprio sul finire della giornata lavorativa abbiamo concluso un punto importante nel lavoro di programmazione che stiamo facendo e di cui vi ho già accennato in precedenza. Nello specifico volevamo maneggiare dei "record" contenuti su il database interno dello strumento, e fino a qui non ci sarebbe nulla di eccezionale, se non fosse che la struttura dei "record" non fosse uniforme e ce ne fossero parecchie varianti.

La complicazione sta proprio nel dover gestire questa diversità nonostante ci sia una radice comune e per tutti i tipi sia necessaria un'identica sequenza di operazioni. Chi ha programmato ad oggetti, sa che questo è il caso tipico di applicazione dell'ereditarietà e del polimorfismo, cardini di questo modo di progettare un software. Avevo parlato di queste due caratteristiche della programmazione ad oggetti nel mini corso che avevo anche pubblicato su questo blog, se qualcuno fosse interessato erano rispettivamente la lezione 4 e la lezione 5.

Di fronte a questa sfida, non ho resisto alla tentazione e ho provato l'estensione ad oggetti del linguaggio di National Instruments. Mi ci è voluto un po', specie per capire il gergo e le modalità in cui la programmazione ad oggetti testuale è stata tradotta in icone, ma devo dire che una volta appreso il minimo, si va avanti piuttosto facilmente.

Per chi volesse avere un'introduzione e una spinta per iniziare, il posto giusto è questo webinar di presentazione e i link ivi presentati. E' in inglese, ma è talmente ben fatto che deve essere assolutamente visto anche se siete dei maghi di C++.

Non tutte le GUI sono uguali

Esempio di come non vorrei fosse una GUI

Se mi vedete un po' latitante di questi giorni è perché sono presissimo in laboratorio, anzi tutto il laboratorio è in fermento perché in base alla nostra programmazione interna dovremmo essere piuttosto vicini alla prima milestone del software che stiamo sviluppando. Abbiamo persino un diagramma di Gantt per dirci a che punto siamo!

Fino all'inizio di questa settimana ci siamo occupati di implementare tutti i comandi che erano descritti sul manuale, incluso correggere i numerosi errori del manuale stesso. Ma da un paio di giorni abbiamo iniziato la fase due, ovvero inserire la libreria di comandi messa insieme in un'interfaccia grafica decente.

Ecco, questo decente è la discriminante. Se chiedete ad un fisico quadratico medio, verosimilmente nella sua vita da ricercatore avrà avuto qualche contatto con la programmazione e per lui il massimo di interfaccia utente sarà un terminale testuale con messaggi di debug che apparivano e sparivano alla velocità della luce.

Un'interfaccia deve essere funzionale, facile da usare, intuitiva e perché no, anche bella. Esattamente l'opposto di quanto descritto sopra. Per il nostro software abbiamo scelto la piattaforma di sviluppo LabVIEW, di cui vi ho già parlato, dove costruire interfacce grafiche belle è piuttosto semplice, anche se per renderle funzionali, user-friendly e intuitive ci vogliono comunque un sacco di ore di lavoro.

Spero che come scusa per essere un po' assente basti!

[LabVIEW] La definizione di nuovi tipi, controlli e indicatori

Chi nella propria vita ha programmato almeno un po' in un linguaggio testuale, sicuramente si è imbattuto nella definizione di nuovi tipi di dati. A partire dai tipi standard, come i numeri interi, quelli in virgola mobile, i caratteri e i booleani, in gran parte dei linguaggi di programmazione è possibile definire nuovi tipi. La domanda sorge spontanea: è possibile fare altrettanto in LabVIEW?

Scaricate il progetto tutorial da questo indirizzo e continuate a leggere...

[LabVIEW] L'oscilloscopio virtuale

Lo scopo di questo post è di farvi vedere come realizzare con LabVIEW una piccola applicazione, senza troppe pretese, ma completa e funzionale in tutto e dall'aspetto professionale. Ecco gli aspetti che andremo a toccare in questa puntata di LabVIEW per tutti:

• Come realizzare un'applicazione usando la programmazione per eventi.
• Abilitare il login dell'utente in modo avere disponibili comandi differenti a seconda della tipologia di utente (normal user, power user e super cow). 
• Modificare il menu dell'applicazione aggiungendo comandi definiti dall'utente. 

Se siete pronti, direi che possiamo iniziare, scaricatevi l'intero progetto dell'oscilloscopio virtuale da qui e cominciate a sfogliare il diagramma mentre leggete il resto. 

[LabVIEW] Come ottimizzare la Top Level Application

Ho avuto il mio primo incontro/scontro con LabVIEW, il linguaggio di programmazione visuale di National Instruments quando ero ancora all'università. All'epoca ero troppo interessato a far funzionare le cose e troppo poco istruito in programmazione per farmi troppo domande e cercare di ottimizzare le cose. Da allora, più o meno da vicino, ho sempre avuto a che fare con i VI (virtual instruments) ovvero i programmi e adesso tornerò a farne un uso pesante.

A differenza di allora, adesso oltre che a funzionare, mi piace cercare di ottimizzare i miei programmi per evitare di avere del codice che divora risorse come uno squalo senza restituire nulla in cambio. Man mano che trovo qualche cosa di utile, cercherò di scriverla qui in un post, non aspettatevi un vero e proprio tutorial o un corso di LabVIEW, ma più semplicemente una collezione di informazioni che spero vi possano essere utili come lo sono state a me.

Finita l'introduzione, veniamo al discorso di oggi. Ottimizzare l'esecuzione della top level application, ovvero come utilizzare gli eventi.

Il laboratorio creativo

E' stata una settimana lavorativa all'insegna della creatività. Quella precedente abbiamo iniziato a mettere le mani, un po' per gioco, un po' per scherzo su una nuova linea di attività di cui vi ho già accennato più volte. Questa settimana è stato il tripudio dell'inventiva: presi dalla smania di fare abbiamo iniziato a scrivere il codice e al tempo stesso abbiamo iniziato a buttare nero su bianco quello che vogliamo fare e come vogliamo farlo.

La progettazione è forse la fase più complessa, perché se si costruisce una casa senza fondamenta, è solo una questione di tempo: prima o poi questa verrà giù. E così ci siamo ritrovati a riempire lavagne con schemi, più o meno simili all'architettura del software, diagrammi con "il chi fa cosa" e così via. Dalla lavagna siamo passati ad un documento di Word e a fare le stime dei tempi richiesti da inserire in un diagramma di Gantt. Scrivere è utile, lo devo ammettere, perché ti permette di chiarirti le idee e revisionarlo insieme ad altri ti fa identificare tutti quelli che possono essere i punti deboli del tuo piano.

Nel frattempo però, presi dall'euforia, abbiamo anche cominciato a scrivere un po' di codice. Dopo un paio di giorni abbiamo deciso che l'angolo del laboratorio dove il progetto era nato non era esattamente il più appropriato e che questa nuova linea necessitava di una sua postazione dedicata. Pronti via, sbaraccato un tavolo, fatto spazio e installato il nostro pc di sviluppo, ovviamente con doppio schermo.

Venerdì mattina, abbiamo impiegato una buona mezz'ora per raccontarci tutte le idee che c'erano venute in mente nella notte appena trascorsa. Se non è creatività questa! Adesso dobbiamo finire la fase progettuale e poi mantenere lo stesso slancio per i prossimi mesi!

Il convertitore seriale Ethernet

Dopo aver letto l'introduzione "non tutte le seriali sono uguali" noterete subito l'imprecisione nel titolo di questo post, infatti con il termine seriale non si identifica un protocollo, ma una modalità di trasmissione, e a voler ben vedere, visto che anche l'Ethernet è seriale, non ci sarebbe nulla da convertire.

Il seriale nel titolo si riferisce alla RS-232, che una volta era presente su tutti i pc, mentre adesso è divenuta una rarità. In genere questi convertitori, tipo questo giusto per darvi un esempio,  sono in grado di gestire anche i due fratelli maggiori della 232 e utilizzati prettamente in ambito industriale, ovvero la 422 e la 485.

In parole povere, questo convertitore è uno scatolino, che può avere dimensioni anche molto piccole, che da un lato accetta una connessione 232/422/485 (nel resto dell'articolo, per semplicità, chiameremo seriale) e dall'altro ha un plug di rete normalissimo. Svolge due funzioni principali: la prima è la conversione dei livelli ed è un'operazione puramente elettronica, ovvero cambia lo standard elettrico (tensione, differenziale o single-ended...) dei segnali in ingresso in modo da renderli compatibili con lo standard in uscita. La seconda invece riguarda il protocollo, così che i bit della seriale nel mentre che fluiscono dentro lo scatolino vengono impacchettati nel payload di un datagramma TCP/IP e viceversa.

L'utilità è indiscutibile e evidente. Le comunicazioni che utilizzano il protocollo 232 hanno il grosso limite di essere limitate a due dispositivi, un pc e uno strumento esterno, limite superato nei protocolli 422 e 485. Ma pensate un po' al vostro ufficio, che tipo di prese informatiche trovate nel muro vicino al vostro pc? Ovviamente solo prese Ethernet. Diventerebbe così veramente facile interfacciare strumenti remoti utilizzando l'infrastruttura già esistente.

Il CRC: i polinomi di bit

Avete in mente i segnali di fumo usati dagli indiani per comunicare? Ecco la comunicazione seriale tra un pc e un dispositivo può essere facilmente assimilata alle nuvole di fumo (1) intervallate da buchi (0) bianchi.  Il problema è quello di verificare che la sequenza di 1 e 0 arrivi al destinatario esattamente come il mittente l'aveva prevista. Sono molte infatti le cause per cui un messaggio potrebbe arrivare corrotto al ricevente e ovviamente le conseguenze, specie nei sistemi elettronici di sicurezza, potrebbero essere dannose e pericolose.

Una possibilità è di inviare insieme al messaggio anche un codice di verifica, generato a partire dal messaggio, e che possa essere utilizzato per verificarne l'integrità. Questo codice di controllo prende il nome di CRC ovvero cyclic redundant code: è ciclico per il modo in cui viene calcolato su tutti i byte che compongono il messaggio ed è ridondante perché all'interno del codice non ci sono informazioni nuove rispetto al messaggio e quindi se vogliamo è uno spreco di risorse, se non fosse che ci garantisce l'integrità del resto del messaggio.

Non tutte le seriali sono uguali

Se prendete un nativo-digitale, diciamo un adolescente di oggi, questo saprà sicuramente aiutarvi a navigare sui tablet di ultima generazione ovviamente in touch, ma se gli domandate se il suo pc di casa ha una porta RS-232, cadrà quasi sicuramente dal pero.

RS-232 è il nome proprio di quella che amichevolmente viene chiamata porta seriale di cui una volta tutti i computer erano dotati e che adesso è stata largamente sostituita da altre connessioni. Le connessioni seriali, ovvero quelle in cui i bit di ogni singolo byte sono inviati singolarmente uno dopo l'altro su una sola linea di trasmissione, sono sicuramente tra le più comuni nelle comunicazioni tra computer e altri dispositivi esterni. Tra queste ricordiamo non solo la buona vecchia RS-232, ma anche la moderna USB e la regina di tutte le connessioni seriali ovvero l'Ethernet.

Ritorno alle origini

Oggi mi è sembrato di vivere un flash-back! E devo dire che è stato molto bello e stimolante. Non immaginatevi nulla di fuori luogo e sconveniente, solo che oggi abbiamo iniziato una nuova iniziativa al lavoro e mi sono ritrovato a fare cose che facevo più di dieci anni fa.

Come vi ho già detto altrove,  uno dei miei compiti lavorativi sarà collegare svariati, in numero e tipo, dispositivi ad un computer centrale che li gestisce e controlla tutti simultaneamente. Oggi abbiamo buttato giù le basi dell'architettura, abbiamo cioè discusso quello che secondo noi è il sistema più pratico e efficiente per sviluppare il software, mantenerlo in vita il più a lungo possibile ed eventualmente espanderlo. Il progetto è ancora in beta e aspetta l'approvazione dall'alto e probabilmente subirà qualche revisione, ma dopo una mattina passata a discutere di come fare le cose, oggi pomeriggio avevamo le mani che ci prudevano e non abbiamo resisto alla tentazione di fare già qualcosa.

E così, un po' alla rinfusa e senza la dovuta sistematicità, abbiamo preso il primo strumento che ci è passato tra le mani e lo abbiamo attaccato al computer. Prima di sera i due si parlavano. Per il momento si dicono molto poco, ma è chiaramente il primo passo necessario. Domani saremo tutti ad un corso di aggiornamento, ma credo che faremo fatica a restare concentrati perché continueremo a pensare al nostro nuovo progetto.

Cos'è la telemetria

Chi come me ha dedicato questa domenica pomeriggio a guardare il Gran Premio d'Italia, avrà sentito nominare più volte il termine telemetria, in riferimento al fatto che il muretto della Ferrari non era in grado di riceverla dalle auto in pista. Prima dell'inizio della mia carriera di uomo che sussurra alle macchine (in generale, non le automobili) avevo sempre pensato che la telemetria fosse un qualcosa di specifico delle corse automobilistiche e che il termine fosse utilizzato sono in quel contesto specifico.