Gestione allarmi con DB Ottimizzato

[ifachsoftware]

Ciao , anche nel mio esempio era un UDT

 

[acquaman]

Già gestire gli allarmi è abbastanza noioso, ma voi veramente spostate ogni singolo bit uno ad uno per creare le word da leggere sull'HMI?

 

Nell'ultima linea che ho fatto avevo più di 2000 allarmi, lo trovo un sistema un po dispersivo ed una grossa perdita di tempo.

[ifachsoftware]

Anch'io lo pensavo quando me lo hanno insegnato a fare su PC dei consulenti Microsoft molto preparati (programmazione in C#) , poi ho capito il vantaggio e non tornerei mai indietro.

Ora lo stesso principio l'ho portato anche sui PLC riuscendo a creare programmi complessi ottenendo un'ottima leggibilità e facilità di modifiche.

Ti spiego i vantaggi : a livello di programma ti gestisci gli allarmi a livello di Bit , e te ne freghi della presentazione nell'HMI.

Quando dovrai pensare all'HMI in una sola funzione li mappi e li sposti a tuo piacimento.

Se dovessi ottimizzare i dati per mandare degli allarmi ad un HMI e magari degli altri dati scambiarli in rete su word diverse , ti basterebbe rifare il mapping in un unico punto.

Ottieni la separazione dei dati dall'applicazione in maniera pulita.

Nessuno ti vieterebbe di creare un FC dove mappi gli allarmi per un pannello , e un altro FC dove li mappi per esempio su un altro formato per lo scambio in rete.

Se arrivassi dal cliente e ti trovassi che lo scada vuole gli allarmi in un altro modo , entri nell'FC e modifichi velocemente l'interfaccia senza toccare la logica applicativa.

 

Lo stesso principio lo utilizzo facendo una separazione tra gli ingressi e le uscite

Ossia faccio un FC dove scrivo per esempio

 

DBINPUT.MICRO_ALTO := E0.0;

DBINPUT.MICRO_BASSO := E0.1;

 

ecc...

 

Poi all'interno del programma lavoro sempre solo con DBINPUT.MICRO_ALTO

 

Quindi se dovessi arrivare sul posto e scoprire che il micro è normale chiuso , basta che entro nell'FC e corrego

 

DBINPUT.MICRO_ALTO := NOT E0.0;

 

Ed avrei finito senza correre in giro a negare tutti gli ingressi.

Un altro vantaggio sarebbe che in questo modo internamente al programma lavorerei sempre con la logica che scelgo (fregandomene se è negato o affermato).

 

 

Grazie a questa struttura in 30 min ho rimappato un'applicazione dal cliente dove avevano cappellato tutti gli IO che avevano comunicato.

 

Spero di averti reso l'idea

 

Ciao

 

 

 

 

 

 

[acquaman]

Quindi tu mappi anche ingressi ed uscite e non usi il simbolico?

 

Mi spiace ma non capisco l'utilità di perdere tanto tempo a rimappare 2000 allarmi e 3000 IO qualunque linguaggio usi. 

 

Per il discorso di ricablare degli ingressi errati basta cambiare l'indirizzo al simbolo nel simbolico nulla di complicato o lungo e sopratutto quante volte ti capita che cappellano tutto il cablaggio. 

[ifachsoftware]

 

Se ti trovi un normale chiuso invece che un normale aperto non ti basta rinominare il simbolico.

Potresti anche avere necessità piu' complesse tipo doverti gestire in un ingresso il risultato di certe logiche combinatorie che non erano previste , ma tipiche solo dell'adattamento del programma all'impianto in questione.

Il vantaggio sarebbe che puoi realizzare il tuo programma senza sapere a priori come verranno mappati gli I/O.

L'informatica certe metodologie di lavoro le chiama Pattern , e ti garantisco che hanno un loro perchè , anche su impianti banali di pochi I/O.

E' una questione mentale che ti permetterà facilmente di far evolvere il programma nel tempo.

 

Ti faccio un altro esempio : se mappi i tuoi bit interni sulle uscite con una funzione dedicata , potresti per esempio escludere delle parti facilmente magari per fare dei test.

[acquaman]

Quote

Se ti trovi un normale chiuso invece che un normale aperto non ti basta rinominare il simbolico.

Quante volte ti capita un caso del genere da giustificare il lavoro che hai descritto.

Quote

Il vantaggio sarebbe che puoi realizzare il tuo programma senza sapere a priori come verranno mappati gli I/O.

Ti crei il simbolico con indirizzi fittizzi, fai il tuo programma poi esporti il simbolico in excel lo sistemi e lo riimporti.

Quote

anche su impianti banali di pochi I/O

Lo puoi fare solo su impianti banali di pochi IO, quando devi appoggiare qualche migliaio di IO il tempo che perdi è veramente tanto, oltre alla rottura di p...e a fare un lavoro di questo genere.

 

Continuo a non capirne l'utilità, ma ognuno ha il suo stile di programmare. 

[batta]

il 23/3/2018 at 13:41 , suppaman87 scrisse:

Ho creato una UDT "Allarmi" composta da tutti i miei singoli bit a cui posso dare il nome simbolico che voglio, e metto l'UDT all'interno di un DB Ottimizzato.

Poi tramite l'istruzione GATHER_BLK trasferisco il contenuto della struttura dentro un array di word.

 

Io ho provato, ma GATHER_BLK in ingresso accetta solo elementi di un array di bool.
 

[suppaman87]

il 29/3/2018 at 19:42 , batta scrisse:

 

Io ho provato, ma GATHER_BLK in ingresso accetta solo elementi di un array di bool.
 

 

Dovrebbe essere una funzionalità aggiunta nel TIA V15. Se guardi nella scheda degli highlights della nuova versione indica appunto che le funzioni SCATTER/GATHER ora accettano anche Struct e Data Type. Anche se indica la funzione compatibile sono con S7-1500 io ho provato su S7-1200 e sembra funzionare lo stesso. Non ho ancora scaricato sul plc fisico ma non da errori di compilazione e sul simulatore funziona... a giorni dovrei avere il plc e farò delle prove.

Nelle versioni precedenti effettivamente non era possibile.

 

 

il 29/3/2018 at 10:44 , ifachsoftware scrisse:

Lo stesso principio lo utilizzo facendo una separazione tra gli ingressi e le uscite

Ossia faccio un FC dove scrivo per esempio

 

DBINPUT.MICRO_ALTO := E0.0;

DBINPUT.MICRO_BASSO := E0.1;

 

Questo personalmente non lo trovo molto utile, concordo con quanto detto con acquaman, mi sembra un lavoro che richiede tempo e inoltre secondo me invece peggiora la leggibilità del codice. Non hai mai visibilità diretta di cosa succede sugli I/O ma devi sempre andare a fare riferimento all' FC dove hai fatto la mappatura. Sinceramente non vedo i vantaggi anche se effettivamente è un sistema che ho visto utilizzare da diverse persone.

 

 

il 28/3/2018 at 16:35 , acquaman scrisse:

Già gestire gli allarmi è abbastanza noioso, ma voi veramente spostate ogni singolo bit uno ad uno per creare le word da leggere sull'HMI?

 

Nell'ultima linea che ho fatto avevo più di 2000 allarmi, lo trovo un sistema un po dispersivo ed una grossa perdita di tempo.

 

Per quanto riguarda gli allarmi invece, la perdita di tempo a mio avviso è minima, basta eseguire due istruzioni, a prescindere che gli allarmi siano 1 o 10.000

Con poco tempo ottieni i vantaggi del DB simbolico e continui ad avere un ottima leggibilità.

 

 

Poi ognuno ha i sui gusti e metodi di programmazione.
Mi fa piacere però che siano spuntate fuori idee diverse, così chi legge può scegliere il metodo che ritiene più opportuno tra varie possibilità
 

[batta]

Quote

Dovrebbe essere una funzionalità aggiunta nel TIA V15.

Proprio come dici tu. Io avevo provato con la V14 e accettava solo array. Con la V15 accetta anche struct.

[suppaman87]

Confermo, appena provato anche su plc fisico e tutto ok. Non so perchè abbiano dichiarato la compatibilità solo con 1500..

 

[ifachsoftware]

Scusate , ho il tia Portal V15 e sia con un progetto S71200  che un progetto S71500 non trovo l'istruzione GATHER_BLK  ; sapete dirmi dove otto che voce posso trovare questa istruzione ?

 

Grazie

 

 

[batta]

Si trova nel gruppo "Operazioni di trasferimento".
Ma non è necessario sapere dove si trova. In KOP, per esempio, ti basta inserire un box vuoto (trascinando il quadratino con i due punti interrogativi, oppure con Shift+F5), e poi inserire il nome dell'istruzione.
Oppure, digiti il nome (o un pezzo del nome) nella casella di ricerca.

 

[ifachsoftware]

Era quello che facevo , il problema è che ci voleva la ver 4.2 del fw della mia cpu , e poi forzare l'aggiornamento del set di istruzioni.

 

Dopo aver fatto l'aggiornamento funziona tutto.

 

Grazie