|
CONTENUTI Progettare in "ottica" standard Inserire un blocco standard in un software plc Modifiche, revisioni e versioni in blocchi standard
APPENDICI Come riempire le variabili non utilizzate nelle interfacce di blocco
|
Modifiche, revisioni e versioni in blocchi standard Questa, che vuol essere una pagina di conclusione (almeno temporaneamente, e se non ci fossero domande specifiche che potrebbero dar luogo a nuove pagine) di questo piccolo scritto, vorrebbe porre alcuni punti di riflessione, soprattutto se l'uso di questi blocchi standard non è limitato ad un singolo, ma ad un intero gruppo di programmatori. Molto spesso accade, e quasi sempre sul campo, che un blocco standard, che al collaudo in azienda era perfetto, si riveli incompleto (nella migliore delle ipotesi), oppure addirittura di errata concezione o sviluppo (nella condizione meno positiva). A parte tutto ciò che ne deriva sul momento, alla fine ci si troverà con due blocchi standard identificati dallo stesso numero, ma con funzioni poco o tanto differenti che fare? Il problema che si presenta di semplice soluzione, come si potrebbe pensare (basta cancellare dal 'database' comune la versione vecchia e rimpiazzarla con la nuova) non lo è: si pensi a questi casi, realmente accaduti, e alle loro possibili implicazioni.
CASO1- Il progettista 'principe' è un tipo dalle mille e più versioni: quando fa un blocco standard a cadenza assai stretta genera un miglioramento, spesso toccando anche l'interfaccia: così chi prende dal database la versione del blocco, e poi su quella elabora il suo software, se deve riprendere il blocco dal database si troverà di sicuro una nuova versione, con nuovi miglioramenti, altri bug (quale software non ne ha?) e soprattutto un know-how che non ha per il commissioning. Le soluzioni in questo caso sono su due versanti: il primo è quello di limitare le versioni a correzioni indispensabili: non alla ricerca spasmodica di una precisione che poi la meccanica non avrà mai, e poi in seconda analisi di documentare le versioni: oltre il front-end (l'interfaccia) e il principio di funzionamento del blocco stesso, anche le variazioni interne: basta un semplice file di testo, per chiarire le idee.
CASO2- Ci sono più softwaristi, quasi paritetici, ognuno, a suo uso e consumo, modifica i blocchi standard con o senza pubblicarne le modifiche in comune. Si provi a pensare se uno di questi debba mettere mano al lavoro di altri; ci vorrebbe molto tempo e il rischio di commettere errori non sarebbe vano. Anche in questo caso il discorso sopracitato di limitarsi alle modifiche necessarie è d'obbligo. Urge poi un coordinamento che possa dar modo ad un database comune.
Per Identificare le versioni e le revisioni i metodi sono molti, addirittura per Step7 esiste una comoda utility chiamata DocPro, tuttavia si pensa che si possa agevolmente, in realtà medio-piccole, riuscire a trovare un metodo di revisione delle versioni, già dal nome stesso. Si provi a pensare a questo:
[BLOCCO_STANDARD]1.00CN
Si cercherà di spiegarne i campi: -BLOCCO_STANDARD : Nome del blocco o della funzione standard -1.00 : Release attuale. -CN : Sigla che identifica lo sviluppatore che ha apportato la modifica.
Oltre a ciò sia Step MicroWin, sia Step7 consentono di aggiungere in modo differente proprietà al blocco.
STEP MICROWIN Qui l'unica personalizzazione è il nome dell'autore, nella cartella proprietà del blocco, che è accessibile dal click del tasto destro del mouse sul blocco.
STEP 7 Qui le possibilità di personalizzazione sono tante, quasi infinite, e tutte accessibili con la pressione del tasto destro del mouse sul blocco interessato: dal nome dell'autore, della "famiglia" del blocco, alla versione: quasi tutto ciò che si vuole.
Si ricorda infine, di non lesinare i commenti: sia nell'intestazione che fra i segmenti, ovunque possano risultare utili: ne risulteranno assai utili per eventuali revisioni. |
|
|