B. Icon and Connector Pane After you build a VI, build the icon and the connector pane so you can use the VI as a subVI The icon and connector pane correspond to the function prototype in text-based programming languages Every VI displays an icon in the upper-right corner of the front panel and block diagram windows An icon is a graphical representation of a VI If you use a VI as a subVI, the icon identifies the subVI on the block diagram of the VI

B. Icon and Connector Pane – Good VI Icon Characteristics of a good VI icon Conveys the functionality of the VI using: Relevant graphics Descriptive text

B. Icon and Connector Pane – Create Icon Create custom icons by right-clicking the icon in the upper right corner of the front panel or block diagram and selecting Edit Icon or by double-clicking the icon You also can drag a graphic from anywhere in your file system and drop it on the icon

B. Icon and Connector Pane – Setting up the Connector Pane Right-click the icon in the upper right corner of the front panel and select Show Connector Each rectangle on the connector pane represents a terminal Use the terminals to assign inputs and outputs Select a different pattern by right-clicking the connector pane and selecting Patterns from the shortcut menu

Icona dei Connettori Ogni VI può essere a sua volta incluso in un altro VI come un subVI. Ogni operatore dello schema a blocchi è in realtà un subVI L’icona dei connettori definisce input ed output di ogni subVI Un subVI espone la sua icona dei connettori al posto del pannello frontale

Icona dei Connettori Anche per la definizione di input ed output si procede per via grafica L’icona dei connettori, in modalità show connectors, permette di associare ogni elemento del front panel ad un terminale del VI Ogni terminale può essere consigliato (default), obbligatorio od opzionale È importante mantenere la convenzione che vuole gli input a sinistra e gli output a destra

B. Icon and Connector Pane – Standards Use this connector pane layout as a standard Top terminals are usually reserved for references, such as a file reference Bottom terminals are usually reserved for error clusters

C. Using SubVIs – Terminal Setting Bold: Required terminal Plain: Recommended terminals Dimmed: Optional terminals You can designate which inputs and outputs are required, recommended, and optional for your subVIs Right-click a terminal in the connector pane and select This Connection Is. Select Required, Recommended, or Optional. LabVIEW sets inputs and outputs of VIs you create to Recommended by default. Set a terminal setting to required only if the VI must have the input or output to run properly.

D. Undefined or Unexpected Data ∞ (Inf) Infinity Divided a number by zero? NaN Not a number Produced by invalid operations, such as taking the square root of a negative number Check for unexpected Inf values or NaN values in your mathematical operations LabVIEW can process complex numbers. There is a complex number option on the numeric palette.

Errori RunTime Gli errori si distinguono a seconda dell’utilizzatore che li genera: se avvengono mentre stiamo progettando il VI sono errori di DESIGN TIME e impediscono l’avvio del VI stesso se avvengono quando il VI è in esecuzione sono errori di RUNTIME e non sono prevedibili a priori Ogni subVI in grado di generare errori deve prevedere un errore in input ed uno in output

Il Flusso degli Errori Ogni VI che può generare un errore RunTime dispone di due connettori, chiamati error in (no error) ed error out Il tipo di dati che gestiscono questi terminali è un cluster particolare, composto da status, codice e messaggio Alcuni controlli, come il blocco case, sono in grado di adattarsi al tipo di dato errore grazie al polimorfismo

Il Flusso degli Errori un VI che trovi un error in diverso da no error non viene eseguito, ma passa l’errore al terminale error out direttamente un VI che riscontri un errore RunTime scrive sul suo terminale error out l’errore riscontrato, se nulla è collegato ad error out, compare una finestra di errore standard all’utente

E. Error Checking and Error Handling – Manual Error Handling To disable automatic error handling for a subVI or function, wire its error out cluster to the error in cluster of another subVI or function or to an error out indicator Use the LabVIEW error handling VIs, functions, and parameters to manage errors

E. Error Checking and Error Handling – Error Clusters Use the error cluster controls and indicators to create error inputs and outputs in subVIs The error in and error out clusters include the following components of information: Status Code Source Go to Help»Explain Error to access the Explain Error dialog box. Status is a Boolean value that reports TRUE if an error occurred. Most VIs, functions, and structures that accept Boolean data also recognize this parameter. For example, you can wire an error cluster to the Boolean inputs of the Stop, Quit LabVIEW, or Select functions. If an error occurs, the error cluster passes a TRUE value to the function. Code is a 32-bit signed integer that identifies the error numerically. A non-zero error code coupled with a status of FALSE signals a warning rather than a fatal error. Source is a string that identifies where the error occurred

C. Using SubVIs – Handling Errors Use a Case structure to handle errors passed into the subVI

C. Using SubVIs – Handling Errors Avoid using LabVIEW error handler VIs inside subVIs

Sequenze di esecuzione Lavorando in dataflow non si possono controllare le sequenze di operazioni ma solo il flusso di dati Flussi paralleli avvengono secondo le disponibilità del processore e dell’hardware e non possiamo quindi definirne la sequenza Nel caso delle operazioni debbano necessariamente essere eseguite in successione possiamo ricorrere al FLUSSO DEGLI ERRORI per imporre una sequenza specifica Oltre agli errori anche altri tipi di dato contenenti risorse (task, handle, file) sfruttano una catena di connettori IN/OUT utili per creare sequenze

Modello standard di subVI

subVI con memoria FUNCTIONAL GLOBAL VARIABLE Un subvi con uno shift register non inizializzato MANTIENE IN MEMORIA I DATI DELL’ULTIMA VOLTA CHE E’ STATO USATO… quindi lo posso usare come memoria stabile...

Modalità di Esecuzione Grazie alla finestra VI properties possiamo definire varie proprietà di esecuzione del subVI, la principale rimane però la modalità di esecuzione L’esecuzione è detta reentrant se possono esistere più istanze del medesimo subVI in esecuzione in contemporanea L’esecuzione è invece non-reentrant se esiste una sola istanza del subVI cui accedono successivamente i vari VI che lo richiamano In entrambi i casi un unica istanza del subVI viene collegata ad ogni VI che l’ha richiamata, rendendo quindi possibili operazioni iterative in successione (ad esempio un inizializzazione di una risorsa solo alla prima chiamata od un contatore interno)

Memorie dei subvi e execution mode Se il subVI è REENTRANT allora OGNI ISTANZA ha un suo spazio di memoria, se il subVI è NON-REENTRANT allora lo spazio di memoria è unico! REENTRANT NON REENTRANT A 1 B 2 C 3

Projects Whenever more than a VI is required to perform a task we can create and extended group: a project A project is made by the following: One or more TARGET (hardware on the which we’re working) One or more VI per target, if needed grouped in virtual folders One or more LIBRARY grouping different Vis with a common task One or more BUILD SPECIFICATIONS To create executables from our project To create installer for such executables

Project TARGET VI Library VIs Installer Executable

Buone pratiche di programmazione Scegliere uno dei due approcci : BOTTOM-UP: identificare i compiti più difficoltosi del progetto, sviluppare un modulo che li assolve, quindi integrarlo in step successivi nel progetto utile solo se il progetto è semplice, ma il risultato è dubbio e si vuole valutarne la fattibilità TOP-DOWN: definire in linea di massima il funzionamento del progetto, partendo da uno schema logico di funzionamento, e delegare i vari compiti a template (moduli definiti solo in input-output) che verranno realizzati in seguito Utile quando il progetto non prevede vincoli di fattibilità tecnica, anche in casi non complessi!

Buone pratiche di programmazione Mantenere il codice pulito ed intuitivo Scrivere sempre da sinistra a destra Non andare oltre le dimensioni dello schermo Disegnare icone intuitive ed usare nomi estesi Commentare i passaggi meno espliciti Sfruttare al massimo librerie e progetti Se si pensa che una serie di funzioni sia correlata,usare una libreria Se si pensa che qualcosa potrebbe essere riusato, metterlo in una libreria Mantenere il progetto ordinato con cartelle virtuali e librerie

Librerie e LLB Libreria Contiene tutti i vi, i tipi di controlli e le variabili di rete che adempiono a funzioni complementari (es controllare un motore tramite un protocollo specifico, connettersi ad un db).. LLB File compresso direttamente accessibile da labview, comodo per trasportare gruppi di vi tra diversi utenti Libreria + LLB => tenere ordinato contenuto e contenitore

ESERCIZIO Creare in un progetto, la libreria analisi segnale che contenga i seguenti vi: media mobile in grado di effettuare una media mobile su una waveform dato il numero di campioni ed la percentuale di sovrapposizione composizione in grado di sommare al quadrato un insieme di waveform e poi applicarvi la radice quadrata, istante per istante confidenza in grado di aggiungere ad una data waveform il limite superiore ed inferiore dati incertezza standard e livello di confidenza SNR rapporto tra il valore del segnale ed il rumore (incertezza) istante per istante

ESERCIZIO Sfruttando la libreria analisi segnale acquisire per almeno 30s i segnali dei trasduttori che vi vengono messi a disposizione, considerando una frequenza di campionamento adatta per acquisire segnali fino a 2kHz Visualizzare in un grafico la storia temporale dell’acquisizione, in un altro il segnale ottenuto dalla composizione vettoriale, a cui aggiungere l’intervallo di confidenza del 95% con incertezza pari a 1% del fondo scala, in un altro visualizzare il SNR

Suggerimenti Scegliere se usare un approccio TOP-DOWN o BOTTOM-UP Organizzare lo sviluppo secondo un progetto condiviso, DESCRIVENDOLO prima, se possibile tramite schemi standard o creando template vuoti Definire per ogni subVI da integrare INGRESSI ed USCITE Separare il più possibile interfaccia e calcolo

Esempio: SNR Signal to Noise Ratio (SNR): Rapporto tra segnale e rumore (in questo caso lo stimiamo tramite l’incertezza) Normalmente è espresso in decibel quindi usiamo come uscita sia il valore nominale che il valore convertirlo in dB INGRESSI: segnale (waveform), obbligatorio incertezza (double), consigliato (default ___?) USCITE: SNR (waveform) SNR dB (waveform)