LabVIEW è un ambiente di sviluppo e nel contempo un linguaggio di programmazione grafico. È diffuso nel settore dell'automazione, quindi trovare driver o supporto per questo prodotto software è relativamente semplice. La stretta interconnessione tra interfaccia grafica e logica del programma consente di eseguire prototipazioni software in modo estremamente rapido ed intuitivo: se i driver di un dispositivo sono disponibili, trasferire il segnale dal cavo allo schermo è questione di minuti.

E purtroppo gli aspetti positivi finiscono qui.

Difetti

Gran parte dei difetti è dovuto alla scelta di usare un linguaggio di programmazione grafico invece di esprimere la logica con un file di testo. Questo non sarebbe un grosso problema se la logica fosse comunque rappresentabile in formato testo, scelta operata per esempio dalla Siemens che in Step5 consentiva la programmazione in KOP e FUP (grafici), entrambi mappabili in codice AWL (testo). Purtroppo LabVIEW registra il codice in formato binario proprietario, quindi dal punto di vista logico ogni VI è un blob inaccessibile che porta ai seguenti (enormi) problemi:

  • i programmi sono legati all'ambiente di sviluppo;
  • operazioni base come ricerche e sostituzioni devono passare dall'ambiente di sviluppo;
  • per ogni VI devono essere definite informazioni non sempre rilevanti (l'icona e l'interfaccia grafica);
  • il merging è talmente costoso da risultare impraticabile.

In definitiva l'SCM viene ridotto ad una database di copie, invalidando totalmente un buon 10 anni di innovazioni nel controllo versione. A ciò vanno aggiunti altri problemi, alcuni dei quali sorprendenti per un prodotto che vanta più di 25 anni di sviluppo:

  • l'ambiente di sviluppo è pieno di errori anche gravi: per esempio il tentativo di una rimappatura furba dei nomi dei campi durante la modifica di un cluster può rendere un progetto inusabile senza che lo sviluppatore se ne accorga;
  • molte operazioni sono ridondanti: per esempio si può settare lo stato di un pulsante in almeno 4 modi differenti;
  • esiste una quantità enorme di "trucchi" abilitabili tramite combinazioni di tasti e azioni con il mouse: l'ortogonalità è totalmente assente;
  • le informazioni relative al codice sono sparse nell'ambiente integrato: parte nelle finestre di dialogo delle proprietà del VI, parte nell'icona e parte nella finestra di codice.

Sono presenti altri difetti più o meno rilevanti. Sebbene nuove versioni potrebbero (in linea teorica) aver risolto qualcuno di questi punti, dopo i primi 3 aggiornamenti operati dalla National Instruments, e dopo aver notato che alcuni problemi venivano risolti ma altri venivano introdotti, si è deciso di rimanere alla versione 8.6.1, dove per lo meno i bug sono ben noti.

Progetti pubblici

Durante lo sviluppo del programma TesBli è stato usato un bus di campo CANopen per agevolare il cablaggio elettrico. Il software doveva colloquiare con diversi nodi di I/O distribuiti Advantys STB (Schneider), con un inverter Altivar 312 (Schneider) e con un azionamento brushless HiDrive (Parker).

Il layer di astrazione per il colloquio con i devices fisici è risultato sufficientemente astratto da poter essere utilizzato da altri progetti. È quindi stato creato il progetto lv-canopen estraendo la parte relativa di colloqui e rendendola indipendente dal resto dell'applicazione.

eNTiDi logoeNTiDi software
Software per l'automazione industriale

via fossato, 56
 25038 Rovato (BS)

Telefono: 366 3206501
E-mail: ntd@entidi.it
PEC: entidi@mlcert.it

 Partita IVA: 02909410983