In questo articolo analizziamo due approcci alla costruzione di State Machine in LabVIEW, confrontando pro e contro e scoprendo in quali scenari ciascuno risulta più adatto.
LabVIEW State Machine
UnaState Machinedescrive un’applicazione come sequenza di stati con regole di transizione.
In LabVIEW si realizza tipicamente con:
- un While Loop che gestisce il ciclo,
- una Case Structure che rappresenta gli stati,
- uno shift register che memorizza il prossimo stato.
- Il messaggio solitamente unenumo unastringa(altri tipi di dato sarebbero troppo poco descrittivi per leggibilità e integrazione)
Il vero nodo sta nel tipo di dato usato come messaggio, che può esserestringa,ringoenum.
Il ring equivale a gestire numeri: limitato e poco utile per rappresentare un tipo “messaggio” per la State Machine. La community apre la discussione quindi, tra stringhe ed enumeratori.
Messaggi String : Fessibilità
L’uso dellestringhecome message type, in una State Machine diLabVIEWè il metodo più flessibile e meno vincolante.
Ogni stato è rappresentato dal valore della stringa, passato nello shift register e richiamato dalla Case Structure.
Questo approccio consente di aggiungerestati rapidamente, non obbliga alla dichiarazione di una typedef, ed è adatto a prototipi o logiche ridotte, anche quando i messaggi sono raccolti per esempio da strumentazione.
Il limite principale è l’assenza dicontrollo in edit-mode: un errore di battitura genera uno stato non previsto, da curare con uno statpo default per gestire eccezioni di messaggi non interpretati (come per esempio suggerito nei 5 stati fondamentali Idle, Init,Default, Error, Exit.
Le stringhe sono inoltrecase sensitive(superabile abilitandoinsensitive matchsulla stuttura del case).
Il debug, se non si applicano strategie preventive, diventa complesso, in particolare quando si devono gestire molti messaggi (pensiamo alle architetture piu complesse tra piùproduttori e consumatori).
Per riassumere:
| PRO | CONTRO |
|---|---|
| Creazione immediata di stati. | Nessun controllo a compile-time |
| Massima flessibilità in sviluppo iniziale | Rischio di duplicati ed errori di battitura |
| Messaggi da Hardware (i.e. ASCII) | Debug complesso senza strategie preventive |
| Manipolazione estesa, Serializzazione, Protocolli Custom |
L’uso delle stringhe è molto diffusop tra i programmatori della community e le motivazioni sono verso la flessibilità e l’esperienza che permette stratergie di prevenzione errori.
È sempre necessario unDefault case(non una stringa “Default”), che intercetta valori non mappati.
Oltre a garantire la compilazione, è utile in architetture con più State Machine che condividono un dispatcher: gestisce stati non utilizzati senza replicare logiche e mantiene l’architettura leggera.
Un esempio di utilizzo dei messaggi arriva dallaJKI State Machineun esempio di implementazione molto versatile e dove i vantaggi dei msg come stringhe è completamente utilizzato.
Osserviamo come può essere possibile creare stati “segnaposto” che possono essere utilizzati anche per organizzare meglio tutti i messaggi nel case selector e formare anche macro command, per esempio concatenando messaggi e scodandoli estraendo una linea concatenata.
Enumeratori come messaggi: Meno Errori e Rigore
L’uso deglienumeratori (enum)come case selector in una SM di LabVIEW è la soluzione che possiamo definire più scolastica.
I messaggi sono dichiarati in una type-def che garantisce che ogni nuovo messaggio da gestire deve essere prima DICHIARATO (in uno stile più C-like) e si distribuisce direttamente ai subVI che usano la typeDef dimessaggio.
Ogni stato è rappresentato da un valore simbolico definito nell’enum e, se tipizzato cometypedef, ogni modifica si propaga automaticamente a tutto il progetto.
Questo garantisce coerenza e rende più semplice l’aggiornamento delle Case Structure.
Il principale vantaggio rispetto alle stringhe è ilcontrollo a compile-time: se uno stato non è gestito nella Case Structure, LabVIEW lo segnala subito, evitando comportamenti imprevisti a runtime. Gli enum sono inoltrestrongly typede non possono essere modificati a runtime, caratteristica che aumenta stabilità e riduce il rischio di errori.
Possono essere poi convertiti in TypeDef, generando coerenza tra tutte le copie di se stessi sparse per il codice, garantendo una replicazione della stessa struttura SM ovunque sia posizionata.
La comodità sta nella capacità di aggiornare il typedef quando si aggiungono o modificano stati, riflettendo il cambiamento ovunque sia utilizzata.
| PRO | CONTRO |
|---|---|
| Controllo a compile-time | Richiede gestione del typedef |
| Aggiornamento automatico della Case Structure tramite typedef | Meno immediati nella prototipazione rapida |
| Maggiore leggibilità e coerenza del codice | |
| Non necessita del caso di Default |
L’uso degli enum è consigliato nelle State Machine destinate a sistemi complessi e manutenibili: il rigore imposto dal typedef previene errori e rende l’architettura più scalabile sul lungo periodo.
Conclusione
La scelta del case selector in una State Machine di LabVIEW determina stabilità e manutenibilità del progetto.
- Lestringhesono pratiche per prototipi e logiche ridotte, ma espongono a errori di battitura, duplicati e mancanza di controlli a compile-time.
- Glienumeratoriimpongono disciplina progettuale attraverso typedef e garantiscono coerenza grazie al controllo a compile-time. Sonostrongly typed: gli stati sono definiti a priori e non mutano a runtime.
Per applicazioni professionali e scalabili, glienumrappresentano la scelta consigliata. Le stringhe restano utili solo in contesti sperimentali o di test rapido, dove la velocità conta più della robustezza.
La scelta e la discussione rimane accesa, anche in Bytelabs ci sono diverse scuole di pensiero e questopostdal forum della community NI fa capire quanto non ci possa essere una scelta migliore.
Secondo noi non importa piu se usare TypeDef enum o String, importa piuttosto stabilire uno standard di lavoro condivisio tra il team.
