Gestione allarmi con DB Ottimizzato

[suppaman87]

Buongiorno,

 

Nei "vecchi" S7-300/400 ero solito utilizzare una o più db dedicati per la gestione degli allarmi: quindi creavo un bit per ogni allarme.

Nell'HMI (parliamo sempre di siemens) la variabile di trigger associabile al testo di una segnalazione non può essere booleana, deve essere word (o array di word eventualmente). Quindi andavo a creare una variabile utilizzando poi l'indirizzo assoluto del db, ad esempio DB100.DBW0, e questa comprendeva tutti i miei 16bit di allarme.

 

Ora con i nuovi S7-1200/1500 e le DB ottimizzate non è più possibile utilizzare l'indirizzamento assoluto. Quello che faccio attualmente è togliere la spunta a "accesso ottimizzato al blocco" nel DB in questione dedicato agli allarmi in modo da poter sfruttare ancora il vecchio sistema.

 

Mi sembra strano però che non ci sia altro modo per gestire la cosa con il db ottimizzato.

 

Al momento l'unica alternativa che sono riuscito a trovare è utilizzare l'accesso slice, con la notazione "DB Allarmi".wordAllarmi.%Xn" (dove n sta per il numero del bit). In questo modo definendo una intera word, che sarà poi possibile utilizzare nell'HMI, dal codice poi posso comunque accedere ai singolo bit. In questo modo però i singoli bit e quindi i singoli allarmi non hanno un nome, un simbolo, e risulta molto meno intuitivo a mio avviso gestire il tutto.

 

Esistono altri metodi o altre soluzioni che mi sfuggono?

Voi solitamente come gestite gli allarmi?

[drugo66]

Ciao,

qui c'è una discussione simile.

[suppaman87]

Grazie per la dritta, anche se poi la discussione è degenerata..

 

Visto che eri stato tu l'artefice della mia stessa domanda e che è passato un po di tempo, posso chiederti che soluzione adotti attualmente?

 

PS. non voglio riscatenare nessuna polemica  , è solo un confronto..

[drugo66]

Per gli allarmi sono passato da tempo ai merker; per il ciclo utilizzo word.%Xn, scrivendo prevenivamente cosa esegue ogni singolo bit; per i comandi manuali da pannello utilizzavo bit dichiarati nei db, ma sto passando anche qui ai merker.

[suppaman87]

Alla fine, spinto dalla curiosità ho provato anche a sentire direttamente siemens, la quale in generale mi ha consigliato le stesse soluzioni già proposte nell'altra discussione e da me anticipate..

 

Poi per quanto riguarda la serie 1500 invece, mi ha consigliato di utilizzare la nuova funzione Program_Alarm (qui potete trovare la relativa documentazione).

A prima vista comunque mi sembra più complessa e macchinosa, ma ripeto, ho solo dato un occhiata al volo. Appena posso approfondirò la faccenda.

 

Qualcuno di voi ha già avuto modo di utilizzare questo sistema?

[acquaman]

Quello che vuoi fare, dare in simbolo ad ogni bit della word, mi sembra si potesse fare ma solo in una DB di istanza di un FB e non mi ricordo più come si fa.

[suppaman87]

45 minuti fa, acquaman scrisse:

Quello che vuoi fare, dare in simbolo ad ogni bit della word, mi sembra si potesse fare ma solo in una DB di istanza di un FB e non mi ricordo più come si fa.

 

Forse intendi con il metodo di sovrapposizione delle variabili AT ?
Se ti riferisci a questo, anche li, siamo alle solite. Il risultato che si ottiene mi sembra praticamente identico allo slice

[acquaman]

Si, ho dovuto rinfrescarmi la memoria su come funzionava, ma non risolve il problema, i simboli ai bit non li metti comunque.

[acquaman]

Però con l'AT forse puoi mettere un commento al singolo bit ed è già qualcosa.

 

Comunque l'AT non sono più riuscito a farlo funzionare.

[suppaman87]

A quanto ho capito puoi utilizzare l'AT solo creando un array.. e nell'array ovviamente non posso rinominare il singolo bit 

[acquaman]

Non so se puoi farlo anche con l'array AT perchè non riesco a crearlo, non ho molto tempo per provare, però con l'array normale puoi commentare ogni singolo elemento dell'array e nell'editor puoi visualizzare anche il commento dei tag quindi più o meno quello che volevi fare.

[batta]

Tutto questo solo per voler a tutti i costi utilizzare il DB "ottimizzato"? Sicuri che ne valga la pena?

[batta]

Secondo me molto dipende dal numero di allarmi e dalla complessità della macchina/impianto da gestire.
Se si tratta di un lavoro con massimo qualche centinaio di allarmi, la strada più comoda forse è quella di utilizzare i merker, appoggiandoli magari in un DB per il trasferimento al pannello operatore (da HMI non mi piace leggere i merker).
Se si tratta di impianto complesso, meglio usare subito i DB, fregandosene dell'accesso ottimizzato al blocco.
Questa, ovviamente, è solo la mia opinione.

[suppaman87]

9 ore fa, batta scrisse:

Tutto questo solo per voler a tutti i costi utilizzare il DB "ottimizzato"? Sicuri che ne valga la pena?

 

Come detto attualmente utilizzo i DB con indirizzamento assoluto e tutto funziona bene, quindi non ho nessun problema.

 

Quindi diciamo che più che la necessità, la mia era una semplice curiosità.

Mi sembrava strano che Siemens non avesse messo a disposizione uno strumento per poter interagire in questo senso, così ho pensato che magari mi ero perso qualcosa tra le nuove versioni del TIA.

Comunque in definitiva direi: si, posso benissimo fregarmene dell'accesso ottimizzato


 

[acquaman]

Spesso esigenze banali danno il via a confronti interessanti, e mettendo insieme le varie esperienze si accresce le singole conoscenze.

[drugo66]

Qui c'é un esempio di quello che potrebbe essere una soluzione; gli allarmi sono dichiarati come array di 16 Bool, quindi con la possibilità di definirne un simbolico; poi se ne copia il valore ad una Word (ho usato un FC che copia una Word intera), ovviamente la copia è da eseguire solo al termine della gestione degli allarmi; a questo punto controllando che la Word sia diversa da zero si ottiene l'eventuale somma allarmi, mentre, se si vuole resettare gli allarmi tutti insieme, basta utilizzare l'istruzione FILL.

Che ne dite ?

[acquaman]

Come esercizio bello, Drugo ma lo trovo contorto, perchè prendere dei bit ed inutilmente spostarli in word e per quale beneficio,io resto gli allarmi in DB non ottimizzata come faccio sul 300.

[ifachsoftware]

Personalmente preferisco utilizzare una soluzione imparata con la programmazione ad alto livello : ossia fare una separazione a livelli tra i dati utilizzando dei DTO (Data Transfer Object)

 

Ossia : Ho degli allarmi da gestire nel mio programma , e gli allarmi sono dei Bit , quindi per ogni macchina mi creo un Data Type chiamato per esempio UDT_ERR

 

TYPE "UDT_ERR"
VERSION : 0.1
   STRUCT
      wAlarms { S7_SetPoint := 'True'} : Word;   // Word with Alarms
      Err_00 { S7_SetPoint := 'True'} : Bool;   // Error 00
      Err_01 { S7_SetPoint := 'True'} : Bool;   // Error 01
      Err_02 { S7_SetPoint := 'True'} : Bool;   // Error 02
      Err_03 { S7_SetPoint := 'True'} : Bool;   // Error 03
      Err_04 { S7_SetPoint := 'True'} : Bool;   // Error 04
      Err_05 { S7_SetPoint := 'True'} : Bool;   // Error 05
      Err_06 { S7_SetPoint := 'True'} : Bool;   // Error 06
      Err_07 { S7_SetPoint := 'True'} : Bool;   // Error 07
      Err_08 { S7_SetPoint := 'True'} : Bool;   // Error 08
      Err_09 { S7_SetPoint := 'True'} : Bool;   // Error 09
      Err_10 { S7_SetPoint := 'True'} : Bool;   // Error 10
      Err_11 { S7_SetPoint := 'True'} : Bool;   // Error 11
      Err_12 { S7_SetPoint := 'True'} : Bool;   // Error 12
      Err_13 { S7_SetPoint := 'True'} : Bool;   // Error 13
      Err_14 { S7_SetPoint := 'True'} : Bool;   // Error 14
      Err_15 { S7_SetPoint := 'True'} : Bool;   // Error 15
   END_STRUCT;

END_TYPE

 

 

 

Ossia : Ho degli allarmi da gestire nel mio programma , e gli allarmi sono dei Bit , quindi per ogni macchina mi creo un Data Type chiamato per esempio UDT_ERR

strutturato con una Word chiamata wAlarms e

16 Bool chiamati Err_00 ... Err_15

 

Err_00 potrebbe diventare Err_00_EmergencyPressend

Err_01 potrebbe diventare Err_01_ErrorLoading

 

Che in Tia portal si possono facilmente rinominare dando leggibilità ai nomi della variabili , per poi poterli usare

 

 

Questa struttura la userò nella DB Interessata per esempio

 

In DB_Macchina1

creo il campo Err di tipo UDT_ERR

 

Poi da codice andrò ad utilizzare DB_Macchina1.Err.Err_00 

 

Oppure potrei passare il dato di tipo UDT_ERR come parametro IN_OUT a tutti quegli FB/FC che ne vogliano fare uso

 

Per esempio definisco in un FC il parametro Err di tipo UDT_ERR

 

Ed usero' per la gestione Err.Err_00

 

Per gestire i dati della word , alla fine del main richiamero' una o piu' FC di questo tipo

 

FUNCTION "FillwAlarms" : Void
{ S7_Optimized_Access := 'TRUE' }
AUTHOR : CR
VERSION : 0.1
   VAR_IN_OUT 
      Err : "UDT_ERR";
   END_VAR

BEGIN
    ENO := TRUE;
    
    // Fill word of alarms with single bits
    
    #Err.wAlarms.%X0 := Err.Err_00;
    #Err.wAlarms.%X1 := Err.Err_01;
    #Err.wAlarms.%X2 := Err.Err_02;
    #Err.wAlarms.%X3 :=  Err.Err_03;
    #Err.wAlarms.%X4 := Err.Err_04;

    ......

    #Err.wAlarms.%X15 := Err.Err_15;
 
END_FUNCTION

 

 

a questo punto avrò sempre aggiornata la word degli allarmi , avendo dei nomi per i singoli bit sempre aggiornati , e che possono pure venir passati tra le funzioni in maniera veloce.

 

L'unico scotto è che avremo il tempo della chiamata di FillwAlarms , ma con le nuove cpu non dovrebbe essere un problema

 

Con questa struttura basterebbe pubblicare la sola word wAlarms al Wincc , oppure testare se <> 0 per capire se sono presenti degli Allarmi

 

 

 

 

 

 

 

  

[Operational Amplifier]

Ciao ifachsoftware,

Cosa intendi con la sintassi { S7_SetPoint := 'True'}, è una tua notifica...?

 

[ifachsoftware]

E' quello che genera Tia Portal (dovrebbe essere il flag per impostare il parametro da supervisione)  , puoi tranquillamente tralasciarlo

[Operational Amplifier]

Ok..comunque condivido la tua filosofia!!!

[ifachsoftware]

Grazie 

[suppaman87]

Io attualmente sono arrivato ad una cosa del genere:

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.

Questo array verrà poi utilizzato come variabile di trigger nell'HMI.

Tra l'altro in questo modo i byte della word sono "ordinati" correttamente, e non c'è più bisogno di fare attenzione al numero di bit come prima.

 

Alla fine mi sembra un buon compromesso, si ha la piena leggibilità delle variabili e il codice risulta abbastanza semplice e snello.

 

L'unica rottura potrebbe essere che bisogna aggiornare l'UDT ogni volta che si vuole modificare un bit.

[ifachsoftware]

Si ,ma in Tia Portal la cosa bella è che se rinomini un campo della struttura , ti aggiorna automaticamente da tutte le parti in cui è usato (è per questo che vanno sempre previsti tutti e 16 i bit , magari chiamandoli Bit_xx_Spare).

 

 

[suppaman87]

1 ora fa, ifachsoftware scrisse:

Si ,ma in Tia Portal la cosa bella è che se rinomini un campo della struttura , ti aggiorna automaticamente da tutte le parti in cui è usato (è per questo che vanno sempre previsti tutti e 16 i bit , magari chiamandoli Bit_xx_Spare).

 

Non ho usato una struttura, ma un UDT, anche cambiando il simbolico di un bit devi aggiornare il richiamo dell'UDT all'interno della DB. Poco male in realtà, basta un semplice click.

Utilizzando la DB Otimizzata puoi dichiarare quanti bit vuoi, non è necessario riempire la word. In ogni caso non era necessario neanche con le vecchie db, rimaneva comunque lo spazio allocato anche senza dichiarazioni.