In questa pagina vorrei soffermarmi su due fondamenti:
il PROGETTARE e l'OTTICA
STANDARD
PROGETTARE:
Progettare appunto,
e non "frullare istruzioni" sperando che
il risultato sia quello voluto; non ci si vuole assolutamente addentrare
all'interno di un concetto di progettazione simile a quella che affrontano gli
informatici, si utilizzerà un metodo più "alla mano", molto più
facile da comprendere e da utilizzare.
Veniamo dunque al discorso progetto:
la parte più importante da fare (e
metà lavoro) è quella di pensare bene le funzionalità della cosa, e
soprattutto l'interfaccia giusta: non c'è
nulla di più frustrante di dover modificare un'interfaccia con già del
codice scritto: ecco perchè è meglio pensarci prima! Poniamo di dover
fare un semplicissimo blocco per fare un flip-flop T (un flip-flop T non è
altro che un semplice relè passo-passo che ad ogni pressione del tasto cambia
lo stato dell'uscita: da aperto si commuta su chiuso e viceversa). Avremo
bisogno sicuramente, anche senza pensare troppo, ad almeno un ingresso ed
un'uscita. Rimane poi da determinare come capire se si sia premuto il pulsante;
evitando per un blocco così semplice di creare un blocco funzione (FB) ci
limiteremo a creare una funzione (FC) dovremo forzatamente assegnare un bit
per memorizzare lo stato del pulsante durante la precedente scansione, si
ritiene che un MerkerBit è più che sufficiente. Per poter assegnare in modo
arbitrario lo stato di scansione del pulsante lo poniamo nelle uscite, esso
avrà lo stato del pulsante nella precedente scansione del blocco. E' utile,
anche senza che sia indispensabile avere un bit temporaneo che funga da
"clock" per il flip-flop T. Chi ha una minima conoscenza di
elettronica capirà assai bene di cosa parlo, per coloro che invece si
accostano per la prima volta al mondo dei plc, arrivando
dall'elettromeccanica, il clock è in qualcosa che assomiglia molto al
pulsante con un condensatore in serie: sembra una cosa assai strana, però
realizza bene che dopo il condensatore ci sarà un impulso solo dopo una
pressione del pulsante, anche premendolo per molto tempo non ci saranno
impulsi.
Continuando sul discorso progettazione credo che un breve schizzo ( o per
quelli dotati di più memoria basterà fare mente locale) potrà essere
utilissimo: giusto per non andare fuori pista, segnarsi il
"percorso" dei dati da elaborare, con tutto ciò che entra in campo:
altre variabili, ingressi logici.
"OTTICA
STANDARD"
Per "ottica standard" si pensa
a un'abilità innata per alcuni softwaristi, e molto più difficile per altri,
di creare del codice riutilizzabile: è chiaro che se si sviluppa un codice
che poi avrà un impiego molto vasto si può capire che il tempo risparmiato
è notevole, se invece si crea un codice che spesso dev'essere rimaneggiato
per potersi adattare alla realtà del momento non ci sarà notevole guadagno
di tempo, se non ci sia addirittura una perdita di tempo per interpretare un
codice ed il suo significato.
Si cercherà anche qui di portare un piccolo esempio, anche se non è così
facile intuire la differenza fra un codice riutilizzabile ed uno
"chiuso" ad un caso specifico.
Si ammetta di creare un blocco per gestire una partenza di motori via
azionamenti o inverter, ammettiamo che in una prima commessa si presenti
questa necessità: impostazione della velocità di regime tramite HMI
(interfaccia uomo-macchina es. pannello operatore, pc, etc.) (per il plc
sarà una Word), ingressi di marcia ed arresto da ingressi del plc. Se una
volta realizzato un blocco del genere, collaudato e istallato si dovesse
presentare una seconda commessa con l'aggiunta di un comando di JOG (o marcia
lenta) con una seconda velocità gestita sempre da HMI bisognerebbe
rimaneggiare completamente il blocco, se invece a fronte del primo progetto si
fosse intuita la possibilità di un comando JOG, e magari di qualcos'altro in
relazione alle esigenze possibili, si sarebbe lasciata 'morta' la
sezione JOG nella prima commessa, mentre nella seconda si sarebbe risparmiato
del tempo.
Detta in questo modo sembra molto una cosa da "palla di
cristallo" e forse talune volte lo è: è appunto l'abilità del
softwarista che cerca di leggere a fronte di una richiesta per una commessa
specifica una soluzione in grado di risolvere il maggior numero di problemi e
situazioni.