Copia DB

[Gianka77]

Buongiorno,

avrei la necessità di copiare una DB Ottimizzata in una DB non ottimizzata, quindi indirizzata.
Le due DB Hanno ovviamente la medesima struttura.

La necessità deriva dal fatto che è una DB che vorrei usare nel Pannello Operatore per gli allarmi, ma purtroppo pare non voglia saperne di accettare variabili ottimizzate

Avete qualche consiglio ?

 

Grazie in anticipo

 

 

[ken]

Che pannello è? se usi normalmente DB ottimizzate penso tu stia utilizzando pannelli siemens. se è vero puoi usare db ottimizzate. c'era una discussione su come fare al meglio la cosa. più tardi provo a cercarla.

 

 

[Gianka77]

Ciao,

si scusate non ho inserito il modello del pannello TP 900 Comfort.

Provo a cercare nelle discussioni, ti ricordi mica il titolo ?

 

[ken]

no. comunque puoi fare così:

ti crei un array di word.

richiami poi il singolo bit della word. ti basta mettere alla fine della variabile .%x0 per il bit 0 .%x15 per il bit 15 della variabile

 

 

[batta]

Da un po' di tempo ho abbandonato tutti i legami per compatibilità con il "vecchio" S7-300, e faccio così:
- DB con allarmi dichiarati a bit, ognuno con il suo simbolo ed il suo commento, quindi comodi da utilizzare nel programma. Possono anche essere suddivisi in strutture.

- DB con array di word da dare in pasto al pannello operatore. L'array di word, inoltre, risulta molto comodo per rilevare l'entrata di un nuovo allarme e la presenza di allarmi.

 

I due DB possono essere ottimizzati, o non ottimizzati (anche uno ottimizzato e l'altro no), o si può anche usare un solo DB (i bit di allarme devono sempre essere in una struttura).
Se lavoro con pannelli operatore Siemens, uso tutto ottimizzato.

 

Il trasferimento dal DB con la dichiarazione dei singoli bit a quello con l'array di word lo faccio con l'istruzione GATHER_BLK.
In questo modo, tra l'altro, viene automaticamente fatto anche lo swap dei byte nelle singole word, quindi il primo bit della struttura degli allarmi viene subito interpretato dal pannello operatore come "allarme 1", e non come "allarme 9".
Con Gather, infatti, i bit della struttura vengono scritti nelle word iniziando dal bit a destra, e non c'è più quall'antipatico scambio di byte (standard Big Endian, ovvero il primo byte è quello a sinistra nella word) che costringeva ad utilizzare istruzioni di swap per passare gli allarmi al pannello, o a gestire lo scambio ordinando opportunamente le segnalazioni nel pannello operatore.

 

Per rilevare la presenza di allarmi e l'entrata di un nuovo allarme passo ad una funzione gli array di word come IN_OUT. Nella funzione l'array è dichiarato con sintassi "Array[*] of Word", ovvero senza definire la dimensione dell'array, e ciò permette di usare sempre la stessa funzione per array di dimensioni diverse.

All'interno della funzione, con le istruzioni "LOWER_BOUND" e "UPPER_BOUND" si rilevano quali sono il primo e l'ultimo elemento dell'array che viene passato alla funzione, e basta poi un ciclo FOR per verificare presenza allarmi ed entrata nuovo allarme.
Per rilevare l'entrata di un nuovo allarme, ovviamente, serve un altro array dove memorizzare lo stato degli allarmi per il ciclo successivo.

 

 

 

Modificato: 17 agosto 2020 da batta

[pilota60]

Se usi una CPU 1500 c'è la funzione ProDiag, presente già anche nella versione 15, che evita tutti questi problemi.
Gli allarmi vengono gestiti tutti dal PLC ed al pannello arrivano gli allarmi senza necessità di creare DB e senza creare codice nel HMI.

[Gianka77]

Grazie mille

 

[batta]

41 minuti fa, pilota60 ha scritto:

Se usi una CPU 1500 c'è la funzione ProDiag

Sì, carino e simpatico, ma gratis solo per pochi allarmi (non ricordo quanti), poi ti serve la licenza. Inoltre, occupa parecchie risorse nel plc (credo una quarantina di byte per ogni singolo allarme).
Poi, se non sbaglio, non ti risolve il problema di rilevare l'entrata di un nuovo allarme, come si usa abitualmente, per far suonare la sirena.
Inoltre, non sono riuscito a rendere rapido il collegamento della segnalazione alla variabile corrispondente. Linkare le variabili una per una, quando hai qualche migliaio di allarmi, non è il massimo.
Io l'ho guardato un po', e l'ho subito accantonato. Forse dovrei approfondire per scoprirne le potenzialità.

[acquaman]

13 ore fa, batta ha scritto:

ma gratis solo per pochi allarmi (non ricordo quanti)

25.
Io invece lo sto prendendo in considerazione e studiando, usando molto i blocchi standard e implementando al loro interno gli allarmi gestiti con il prodiag, ti ritrovi tutti gli allarmi già gestiti in automatico senza scrivere una riga di codice.

[acquaman]

14 ore fa, batta ha scritto:

rilevare l'entrata di un nuovo allarme

Effettivamente un bit che per una scansione va a 1 quando esce un nuovo allarme potevano metterlo.

[batta]

1 ora fa, acquaman ha scritto:

Io invece lo sto prendendo in considerazione

Prima o poi mi studierò meglio il ProDiag. Sicuramente offre dei vantaggi, anche se, al momento, non ne vedo molti, forse solo perchè non lo so ancora usare.
Per ora, rimango un po' più "tradizionalista": registrazione data/ora entrata/uscita/accettazione allarmi mi pare, concettualmente, più un compito da HMI/SCADA che da PLC.
È vero che c'è da scrivere un po' di codice ma, seguendo l'esempio descritto sopra, questo codice è veramente poco: si limita ad un richiamo di GATHER_BLK e ad un richiamo della funzione di rilevamento presenza/nuovo allarme.
Se nel DB degli allarmi per ogni allarme si scrive il commento adeguato, basta un copia/incolla per riportare tutti gli allarmi nel pannello operatore.

[pilota60]

1 ora fa, batta ha scritto:

Prima o poi mi studierò meglio il ProDiag

Ho caricato qui un tutorial fatto da Siemens durante il lockdown proprio sull'approfondimento del ProDiag.
Pesa 177Mb ed è in MP4.
Se a qualcuno interessa, il link dura fino al 25 agosto.

link https://we.tl/t-RnxJ7bPJ6f

Modificato: 18 agosto 2020 da pilota60
errore di battitura del link

[marco1278]

18 ore fa, batta ha scritto:

Da un po' di tempo ho abbandonato tutti i legami per compatibilità con il "vecchio" S7-300, e faccio così:
- DB con allarmi dichiarati a bit, ognuno con il suo simbolo ed il suo commento, quindi comodi da utilizzare nel programma. Possono anche essere suddivisi in strutture.

- DB con array di word da dare in pasto al pannello operatore. L'array di word, inoltre, risulta molto comodo per rilevare l'entrata di un nuovo allarme e la presenza di allarmi.

 

I due DB possono essere ottimizzati, o non ottimizzati (anche uno ottimizzato e l'altro no), o si può anche usare un solo DB (i bit di allarme devono sempre essere in una struttura).
Se lavoro con pannelli operatore Siemens, uso tutto ottimizzato.

 

Il trasferimento dal DB con la dichiarazione dei singoli bit a quello con l'array di word lo faccio con l'istruzione GATHER_BLK.
In questo modo, tra l'altro, viene automaticamente fatto anche lo swap dei byte nelle singole word, quindi il primo bit della struttura degli allarmi viene subito interpretato dal pannello operatore come "allarme 1", e non come "allarme 9".
Con Gather, infatti, i bit della struttura vengono scritti nelle word iniziando dal bit a destra, e non c'è più quall'antipatico scambio di byte (standard Big Endian, ovvero il primo byte è quello a sinistra nella word) che costringeva ad utilizzare istruzioni di swap per passare gli allarmi al pannello, o a gestire lo scambio ordinando opportunamente le segnalazioni nel pannello operatore.

 

Per rilevare la presenza di allarmi e l'entrata di un nuovo allarme passo ad una funzione gli array di word come IN_OUT. Nella funzione l'array è dichiarato con sintassi "Array[*] of Word", ovvero senza definire la dimensione dell'array, e ciò permette di usare sempre la stessa funzione per array di dimensioni diverse.

All'interno della funzione, con le istruzioni "LOWER_BOUND" e "UPPER_BOUND" si rilevano quali sono il primo e l'ultimo elemento dell'array che viene passato alla funzione, e basta poi un ciclo FOR per verificare presenza allarmi ed entrata nuovo allarme.
Per rilevare l'entrata di un nuovo allarme, ovviamente, serve un altro array dove memorizzare lo stato degli allarmi per il ciclo successivo.

 

 

 

 

Bello spunto su cui lavorare!!! 👍

[batta]

26 minuti fa, pilota60 ha scritto:

Se a qualcuno interessa, il link dura fino al 25 agosto.

Scaricato.
Grazie.

[batta]

Ho guardato tutto il video. L'oggetto è interessante, ha sicuramente dei pregi, ma è anche molto pesante per la CPU: 128 allarmi su una 1511 richiedono un tempo di circa 1,5 ms, che non è poco. Su una 1516, in 1,5 ms, si gestiscono 750 allarmi.
Questo tempo è comprensibile, dato tutto ciò che viene fatto per ogni singolo allarme ma, per fare 128 allarmi, ci vuole ben poco.

Per ogni motore, generalmente, gestisco 8 o 16 allarmi.
Su cpu 1516, di solito, mi ritrovo con almeno 2000 allarmi. 4-5 ms solo per la gestione allarmi sono troppi.
Nella maggior parte dei miei lavori dovrei sempre acquistare la licenza Unlimited (oltre 1000 allarmi).

 

Alcuni vantaggi poi, sono più teorici che pratici. Esempio: la possibilità di ritardare un allarme, o di aggiungere condizioni in AND per la generazione dell'allarme.
A prima vista questo toglie righe di codice. Ma, di solito, l'allarme viene usato anche nella logica del programma. Cosa mi serve ritardare un allarme, senza dover scrivere codice, se poi, nel programma, devo crearmi un doppione dell'allarme, con tanto di timer? Il quale timer, per non creare discordanze, dovrà avere lo stesso preset del ritardo dell'allarme configurato in ProDiag.
Chiaro che una simile gestione sarebbe demenziale e, nella realtà, gestirei il ritardo dell'allarme nel programma PLC, e non in ProDiag.
Anche il fatto di poter avere i bit di allarme sparsi dove si vuole è, a mio avviso, un vantaggio solo teorico, dato che considero molto più comodo (e concettualmente corretto) raggruppare gli allarmi in aree dedicate, appunto, agli allarmi.
Tra le tante cose poi, purtroppo, manca un bit che avvisi dell'entrata di un nuovo allarme. Io non ricordo un solo programma dove non mi sia servito questo bit. Per me fa parte delle cose essenziali, di quelle che butto dentro come i merker di sistema.
Inoltre, anche a livello pannello operatore, il Basic non va bene, si deve passare per forza al Comfort. Su impianti di una certa complessità l'uso del Comfort è praticamente obbligato ma, su piccole macchie, spesso il Basic sarebbe sufficiente.

 

Conclusioni personali:

- Bello, ma non esaltante.
- Il costo, tra licenze e obbligo di usare il Comfort anche dove basterebbe un Basic, non è trascurabile.
- Per ora, continuo alla "vecchia maniera".

 

[Livio Orsini]

Marco1278 quotare un intero messaggio non serve, anzi rende la discussione poco leggibile.

Per favore cerca di astenerti da questa pratica e limitati a quotare solo una frase significativa, quando è necessario.

Osserva le altre quotature delle discussione: si limitano al massimo ad una frase.

Modificato: 18 agosto 2020 da Livio Orsini

[marco1278]

16 ore fa, Livio Orsini ha scritto:

Marco1278 quotare un intero messaggio non serve... 

Scusa Livio, dal cell non mi ero accorto di aver quotato tutto. 

 

 

[ken]

Io continuo in stile s7-300, come ho sempre fatto.

Ho un FC in cui gestisco gli allarmi, una gestione veramente banale, in awl:

Un "=H01+L-S2331"
= db20.dbx10.0 // [9] Centralina idraulica linea - minimo livello olio H01+L-S2331

Ho segmenti scritti per comodità in awl solo perchè con s7 classico non si poteva mettere più di una riga a segmento; ora in Tia portal potrei fare anche in Kop. ogni segmento contiene 16 allarmi quindi una word.

 

Ora in Tia portal ho un array di 20 word; non è detto che le debba utilizzare tutte. Unica cosa che cambia è come viene scritto il bit di guasto:

UN    "=H01+L-S2331"
=     "DB20 Monitor linea +P00".Allarmi[13].%X0// [209] Centralina idraulica linea - minimo livello olio H01+L-S2331

 

Come tag al plc è una sola, visto che passo l'array intero.

Non mi sembra un dispendio di tag enorme come afferma il tecnico siemens nel video. come tempo per scrivere il software non mi sembra esagerato. se devo configurare bit per bit nella tabella variabili o scrivere righe di codice cambia poco. unica cosa più lunga è certamente copiare il testo nell'HMI e in caso di modifiche farlo in due posti.

[acquaman]

Sicuramente non è la panacea per tutti gli impianti, ma su grossi impianti dove usiamo blocchi standard utilizzati 50 o 60 volte(es blocchi per gestire valvole o pompe), integrando gli allarmi nel blocco ti dimentichi di tutto, devi solo gestire i bit cumulativi degli allarmi per i vari blocchi dell'impianto.

 

18 ore fa, batta ha scritto:

Nella maggior parte dei miei lavori dovrei sempre acquistare la licenza Unlimited (oltre 1000 allarmi).

In questi impianti di solito c'è uno scada di solito rindondato, con migliaia di euro di licenze, una per il prodiag passa inosservata, e se non c'è lo scada il pannello confort è d'obbligo visto che lavoriamo tutto con faceplate che si agganciano ai blocchi standard.

 

18 ore fa, batta ha scritto:

4-5 ms solo per la gestione allarmi sono troppi

Su questa tipologia di impianti non si ha grosse esigenze di velocità, la parte più complessa sono le regolazioni che hanno i loro OB

[acquaman]

 

18 ore fa, batta ha scritto:

Alcuni vantaggi poi, sono più teorici che pratici. Esempio: la possibilità di ritardare un allarme, o di aggiungere condizioni in AND per la generazione dell'allarme.
A prima vista questo toglie righe di codice. Ma, di solito, l'allarme viene usato anche nella logica del programma. Cosa mi serve ritardare un allarme, senza dover scrivere codice, se poi, nel programma, devo crearmi un doppione dell'allarme, con tanto di timer? Il quale timer, per non creare discordanze, dovrà avere lo stesso preset del ritardo dell'allarme configurato in ProDiag.

 

Il bit di allarme nella db del progiag c'è, non serve gestirlo nuovamente esterno.

[batta]

54 minuti fa, ken ha scritto:

Non mi sembra un dispendio di tag enorme come afferma il tecnico siemens nel video

Nemmeno a me pare questo grande spreco.

 

Pienamente d'accordo anche sul fatto che scrivere la condizione di allarme in ProDiag o in un segmento di programma, come tempo di sviluppo, poco cambia.

Senza considerare poi che non ci sono solo gli allarmi con logica banale (stato ingresso = allarme), ma anche allarmi ben più complessi, che dovresti comunque gestire nel programma.
In quanto a copiare i testi nel HMI, se gli allarmi sono commentati si fa presto.

Diverso se fai una FB, per esempio, per la gestione di un motore, dove all'interno della FB stessa configuri gli allarmi per il ProDiag.
Fatto in ProDiag, poi te lo dimentichi. Rimane però un dettaglio che non mi piace: nel testo della segnalazione, per capire di quale oggetto si tratta, si deve inserire il nome dell'istanza. Questo ti costringe ad assegnare nomi alle istanze che siano chiari per l'operatore che legge l'allarme. Questo però potrebbe risultare scomodo nel programma PLC.
E comunque, il collegamento dalla funzione ai bit del DB di allarme lo faccio passando la struttura di allarme del motore (o valvola, o qualsiasi altra cosa) come INOUT, quindi in modo molto rapido.

Piuttosto, ciò che non mi piace nel gestire il bit di allarme come "nomeVariabile".%xn, è che non puoi assegnare nome e commento ad ogni singolo bit.
Per questo preferisco creare una struttura con tutti i bit di allarme, ognuno con il suo nome e il suo commento, e poi trasferire tutto in un array di word (più comode anche per altri utilizzi, non solo per passare gli allarmi al HMI) con GATHER_BLK.
In pratica, come gestisco generalmente gli allarmi, utilizzo 3 bit per ogni allarme: un bit singolo, un bit nell'array di variabili da passare al HMI, un bit nell'array che mi serve per rilevare l'entrata di un nuovo allarme.

[acquaman]

23 minuti fa, batta ha scritto:

Pienamente d'accordo anche sul fatto che scrivere la condizione di allarme in ProDiag o in un segmento di programma, come tempo di sviluppo, poco cambia.

Hai ragione, io vedo un buon beneficio se si integrano gli allarmi prodiag in blocchi standard che che si usano decine di volte.

Potrebbe avere anche un senso una gestione mista, gli allarmi dei blocchi standard in prodiag e altri gestiti in modo tradizionale.

 

25 minuti fa, batta ha scritto:

si deve inserire il nome dell'istanza. Questo ti costringe ad assegnare nomi alle istanze che siano chiari per l'operatore che legge l'allarme. Questo però potrebbe risultare scomodo nel programma PLC.

il nome dell'istanza è sempre il tag del KKS del dispositivo questo per noi non è un problema.