Vai al contenuto
PLC Forum


Gestione allarmi con DB Ottimizzato


suppaman87

Messaggi consigliati

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?

Link al commento
Condividi su altri siti


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 :D , è solo un confronto..

Link al commento
Condividi su altri siti

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.

Link al commento
Condividi su altri siti

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?

Link al commento
Condividi su altri siti

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.:(

Link al commento
Condividi su altri siti

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

Link al commento
Condividi su altri siti

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.:(

Link al commento
Condividi su altri siti

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.

Link al commento
Condividi su altri siti

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

Link al commento
Condividi su altri siti

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.

Link al commento
Condividi su altri siti

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 :D


 

Link al commento
Condividi su altri siti

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 ?

Link al commento
Condividi su altri siti

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.

Link al commento
Condividi su altri siti

  • 5 months later...
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

 

 

 

 

 

 

 

  

Link al commento
Condividi su altri siti

ifachsoftware

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

Link al commento
Condividi su altri siti

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.

Link al commento
Condividi su altri siti

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).

 

 

Link al commento
Condividi su altri siti

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.

Link al commento
Condividi su altri siti

Crea un account o accedi per commentare

Devi essere un utente per poter lasciare un commento

Crea un account

Registrati per un nuovo account nella nostra comunità. è facile!

Registra un nuovo account

Accedi

Hai già un account? Accedi qui.

Accedi ora
×
×
  • Crea nuovo/a...