Esempio concreto di DB

[Rexsus18]

Ciao Ragazzi. Sono nuovo in questo grande forum e soprattutto sono nuovo col mondo del PLC. Ho sentito tanto parlare delle famose DB, dove si dice che servono a memorizzare una serie di dati in un registro dati. Volevo chiedervi, riuscireste a farmi un esempio concreto di cosa si riesce a fare con una DB in modo da comprenderne le sue potenzialità? Magari la domanda vi risulterà ultra banale ma per favore provate a spiegarla come se doveste spiegarla ad un ragazzo appena uscito da scuola che ha tutte le basi tecniche. Vi ringrazio!!!

[batta]

DB sta per Blocco Dati. in un DB dichiari le variabili di cui hai bisogno. Le variabili possono essere di qualsiasi tipo (bool, int, real, ecc.) e possono essere organizzate in strutture ed array.

Per poter fare analogie con sistemi diversi di allocazione delle variabili, dovresti dire che plc conosci.

Facciamo un confronto con le DM di Omron. L'area DM la potresti intendere come un unico grande DB.

A mio avviso, superata qualche piccola difficoltà iniziale, dopo si farà in fretta a comprendere i molteplici vantaggi che ci sono gestendo le variabili con i DB.

I due vantaggi più evidenti sono:

- poter suddividere le variabili in diversi DB a seconda della loro funzione (es: variabili di setup, variabili di lavoro, variabili di una parte di impianto/macchina).

- non avere (quasi) vincoli nel caso si debbano inserire variabili. Esempio: hai definito da DM1000 a DM1099 le tue variabili di setup. In seguito a modifiche, quelle 100 variabili non ti bastano più. Se hai già usato le variabili successive, dovrai aggiungere le nuove variabili di setup in un'area diversa. Tutto funziona, ovviamente, ma diventa disordinato. Se, invece, hai un DB con le variabili di setup, puoi aggiungere altre variabili dove e come vuoi, perché questo non avrà nessuna influenza sugli altri DB.

Insomma, entro i limiti della memoria dati a disposizione, con i DB sei libero di organizzare questa memoria come meglio credi.

[step-80]

59 minuti fa, batta ha scritto:

Esempio: hai definito da DM1000 a DM1099 le tue variabili di setup. In seguito a modifiche, quelle 100 variabili non ti bastano più. Se hai già usato le variabili successive, dovrai aggiungere le nuove variabili di setup in un'area diversa. 

Esattamente quello che mi capita quotidianamente con plc di altra marca. 
Per ovviare a ció, sono costretto a creare Struct con dentro ‘n’ variabili ‘free’ ( che so tipo 50,100,200..lo valuto un po a spanne a seconda di quante var so che ci metteró). Poi a seconda della necessità sostituisco ‘freeW_100’ con ‘velocita_jog’ . 
Questo sistema mi è sempre stato ampiamente sulle scatole. Perchè direte voi? Perchè lavorare con il simbolico con questa marca equivale a spararsi in bocca. La gestione dello scambio dati col pannello e delle variabili retain è a dir poco pietosa. Alla fine TUTTI preferiscono usare indirizzi assoluti(Il consiglio arriva anche dal supporto tecnico) ma con tutte le limitazioni del caso . 
in poche parole spessissimo va buttata un sacco di memoria perche io devo sapere a priori quanta ne useró e quindi si tende a stare larghi. 
Con le DB questo non accade, lo trovo un modo molto funzionale ed intelligente per organizzare i dati. 

[leleviola]

3 ore fa, step-80 ha scritto:

in poche parole spessissimo va buttata un sacco di memoria perche io devo sapere a priori quanta ne useró e quindi si tende a stare larghi. 
Con le DB questo non accade, lo trovo un modo molto funzionale ed intelligente per organizzare i dati. 

 

Si vero questo è un vantaggio di usare le DB perchè sei libero di ampliare come vuoi le variabili necessarie dentro la DB ma chi è abituato ormai da tanti anni a lavorare con l'assoluto è abituato a organizzarsi preventivamente le aree di memoria da utilizzare a secondo se retain o no con sovrapposizioni varie a cui devi tener conto, si insomma sei più libero di organizzarti le variabili ma è anche vero il contrario se ti organizzi bene in assoluto alla vecchia maniera senza DB. Dico questo perchè se devi ampliare o modificare una DB sei costretto a successivamente a ricompilare tutto il progetto e questo può andar bene se non lavori online ma se hai necessità di lavorare online e devi modificare la dimensione o gli elementi di una DB sei poi costretto a ricompilare tutto il progetto e ripassare poi dallo STOP del PLC che ovviamente non a tutti piace oppure può comportare dei fermi macchina non contemplabili. In pratica un progetto fatto in assoluto se è organizzato bene a livello di memoria e hai necessità di fare modifiche hai forse meno paranoie e nesun problema a fare modifiche online, vero è che oggi giorno basta saper organizzarsi con le DB e si ottiene comunque gli stessi risultati, basta organizzarsi

[step-80]

@leleviola ovviamente organizzandosi non casca il mondo, ma questa cosa almeno a me da parecchie noie. 

Oltre a quelle citate nel messaggio precedente, c' è da considerare anche un'altra cosa. Spesso nelle strutture si ha bisogno di dati di diverso genere(Word, Bool, Float ecc) e questo senza DB è ancora più un casino perchè se prima risolvevo solo rinominando la variabile, ora aggiungendo per esempio 2 bool ad una struttura che prima conteneva solo word ..vien fuori un macello con gli assoluti. So che la cosa è superabile ragionando per esempio sempre a Word...ma questo mi comporta il creare sempre 16 o 32 bool(che comunque non so mai se saranno abbastanza) che poi non uso e che mi confondono le idee, e questo mi scoccia. 

 

Altra cosa, sono praticamente costretto a rendere ritentiva una intera struttura anche se le variabili realmente da rendere ritentive sono 2 o 3. Non è detto che questo sia sempre un vantaggio,anzi.

Può essere che all'interno abbia dei Bool che allo spegnimento voglio assolutamente siano false anche se al momento dello spegnimento erano True. Ok, si possono inizializzare ma questo è tutto lavoro in più da fare e,soprattutto, possibile punto di errore umano(e io ne faccio tanti). 

Tutto questo è ulteriormente reso noioso dal fatto che sul sw che uso non si possono annidare strutture, fatto che renderebbe la logica macchina molto piu comprensibile.

La velocità Jog dell'asse 'tavola rotante' è molto più comodo cercarla in (sparo a caso) DatiMacchina.TavolaRotante.DatiSetup.VelJog che averla sparsa per le Global col nome 'VelJogTavolaRotante'. Questo almeno per me .

[batta]

1 ora fa, leleviola ha scritto:

sei poi costretto a ricompilare tutto il progetto e ripassare poi dallo STOP del PLC

Perché dici questo? Lo stop del PLC è richiesto quasi esclusivamente a seguito di modifiche hardware o alla parte safety.
Non è vero nemmeno che devi ricompilare tutto. Viene ricompilato solo il DB e i blocchi che accedono al DB. Ma avviene tutto in automatico, tu non devi fare assolutamente nulla.
L'unico problema, se modifichi un DB, è che vengono reinizializzate le variabili. Questa è l'unica cosa che mi è antipatica. Ma, se sei online, fai l'istantanea del DB prima della modifica, e riparti con i valori appena salvati. Senza mai mettere in stop, e senza interferire con la produzione.

 

In quanto ad altre considerazioni, mi trovo in pieno accordo con quanto scritto da Step-80.
Vuoi mettere la comodità di avere tutte le variabili (booleane, int, real, ritentive e non) relative ad un certo compito raggruppate in un DB o in una struttura, piuttosto che sparse in giro? Questa è una booleana e la metto in quell'area; questa è anche lei booleana, ma mi serve ritentiva, quindi la devo mettere da un'altra parte; questa è una real ritentiva, quindi la devo mettere in quest'altra area...

Una volta si poteva fare solo così e, quindi, si faceva così. Ora che c'è la possibilità di organizzare tutti i dati in modo molto più coerente ed efficiente, continuare alla vecchia maniera per scelta, mi pare un controsenso.

[ilguargua]

2 minuti fa, batta ha scritto:

Ma, se sei online, fai l'istantanea del DB prima della modifica, e riparti con i valori appena salvati.

Ecco come si fa!

Visto che il progetto (data la situazione attuale) non è ancora operativo, la cosa non mi creava grandi danni, ma mi chiedevo se non ci fosse un metodo per non riazzerare tutte le volte il contaore che avevo creato.

 

Questo forum è un aiuto non da poco per la nostra professione, quindi ringrazio Batta (vera colonna portante per i PLC Siemens) e tutti gli altri partecipanti per l'impegno che quotidianamente mettono a disposizione di tutti.

 

Ciao, Ale.

[leleviola]

22 minuti fa, batta ha scritto:

L'unico problema, se modifichi un DB, è che vengono reinizializzate le variabili. Questa è l'unica cosa che mi è antipatica. Ma, se sei online, fai l'istantanea del DB prima della modifica, e riparti con i valori appena salvati. Senza mai mettere in stop, e senza interferire con la produzione.

 

si è vero batta non mi ricordavo di tale possibilità e in effetti è il metodo per non portare in STOP la CPU, scusate

[batta]

17 minuti fa, ilguargua ha scritto:

Ecco come si fa!

A dire il vero, ho saltato un passaggio (non era il tema della discussione).
Quando sei online, vedi questo:

Con la freccia verde verso l'alto, fai l'istantanea dei valori attuali del DB. Poi, con la freccia rossa verso sinistra, copi l'istantanea nei valori di avvio.
Dopo la modifica del DB (e, quindi, la reinizializzazione delle variabili), il DB ripartirà con i valori di avvio e, visto che i valori di avvio contengono i valori attuali appena salvati...
In alternativa, puoi usare la freccia rossa verso il basso, e copiare l'istantanea nei valori attuali.

 

Le stesse operazioni le puoi fare anche col tasto destro del mouse, dopo aver selezionato il DB nell'albero della navigazione del progetto. Puoi anche fare selezioni multiple di DB, o selezionare tutto il gruppo, più gruppi, o tutti i blocchi di programma. Non farlo però con eventuali DB di blocchi safety, pena dover mettere in stop la cpu.

 

[batta]

16 minuti fa, leleviola ha scritto:

n effetti è il metodo per non portare in STOP la CPU

Scusami se ti correggo, ma se non salvi i valori attuali la cpu non va in stop. Dopo ti trovi nel DB valori vecchi, ma la cpu non va in stop.

 

Nei DB ottimizzati si può anche attivare la "riserva di memoria". Questo permette di aggiungere variabili senza reinizializzare il DB.
Purtroppo, serve solo se aggiungi variabili (fino al limite di memoria configurato nelle proprietà del DB), non se cambi nomi a variabili esistenti. E, con la riserva di memoria attivata, a quel DB potrai solo aggiungere variabili ma non modificare quelle esistenti. Per poter apportare modifiche, si deve disattivare la riserva di memoria, e verrà richiesta quindi la reinizializzazione del DB.
Questo non risolve tutti i casi, ma ti permette di fare modifiche al volo senza reinizializzazione, e rimandare la reinizializzazione al momento opportuno.

[TheOutSideR]

3 ore fa, leleviola ha scritto:

Si vero questo è un vantaggio di usare le DB perchè sei libero di ampliare come vuoi le variabili necessarie dentro la DB ma chi è abituato ormai da tanti anni a lavorare con l'assoluto è abituato a organizzarsi preventivamente le aree di memoria da utilizzare a secondo se retain o no con sovrapposizioni varie a cui devi tener conto, si insomma sei più libero di organizzarti le variabili ma è anche vero il contrario se ti organizzi bene in assoluto alla vecchia maniera senza DB.

2 cose:

In assoluto è comodo perché sai quanti indirizzi stai occupando? Se guardi la colonna degli indirizzi potrai vedere quanto hai occupato, questo intendi? Mentre con simbolico non puoi farlo?

 

e poi cosa intendi per sovrapposizioni?

1 ora fa, batta ha scritto:

L'unico problema, se modifichi un DB, è che vengono reinizializzate le variabili.

Volevo sapere. Reinizializzare le variabili ha il problema di mettere i valori a livello iniziale e quindi sballare tutto il ciclo?

Per esempio se si ha una funzione che ha memorizzato un valore (per esempio numero pezzi contati o posizione encoder...) quando rimando in start i valori dovrebbero non tornare al valore iniziale per non danneggiare il sistema, giusto?

 

Un altra un po OT, come gestisco un valore temp se mando in stop (magari per una mancanza di tensione) ma questo va mantenuto ??

[leleviola]

In assoluto indirizzi in assoluto e trasferisci i dati negli operandi assoluti e quelli rimangono, in simbolico l'organizzazione della memoria è definita nel sistema se la modifichi rispetto a quella precedente deve essere riinizializzata, l'escamotage che diceve batta è di caricare preventivamente i valori precedenti e poi ricaricarli in rinizializzazione, in assoluto i valori caricati negli operandi assoluti quelli sono e quelli rimangono prima e dopo delle modifiche alla eventuale logica necessaria.

Le sovrapposizioni vuol dire che quando decidi di utilizzare un certo numero di operandi assoluti la scelta degli opernadi da utilizzare deve essere fatta considerando le prerogative degli operandi che vai a usare e perciò devi sapere per esempio quali sono ritenitivi e quali no e da li scegliere quelli che è possibile a seconda delle caratteristiche del PLC e se per caso devi fare in seguito delle modifiche o delle aggiunte può non essere possibile mantenere in ordine numerico seguente un certo numero di operandi che in precedenza avevi definito in un certo ordine, insomma devi essere tu a fare delle scelte ponderate sull'uso della memoria che ha delle caratteristiche ben definite e che solo in parte puoi modificarne le prerogative.

In simbolico definisci tu le carattestiche della memoria ritenitiva e pensa il sistema a gestire le risorse disponibili senza necessariamente utilizzare l'assoluto, l'assoluto dovresti al limite utilizzarlo per far leggere i dati da un HMI se l'HMI tratta solo in assoluto e non in simbolico, anche se ultimamente gli HMI cominciano a trattare anche in simbolico lo scambio dati col PLC

Modificato: 23 marzo 2020 da leleviola

[batta]

2 ore fa, leleviola ha scritto:

in assoluto i valori caricati negli operandi assoluti quelli sono e quelli rimangono prima e dopo delle modifiche alla eventuale logica necessaria.

Anche i blocchi non ottimizzati vengono reinizializzati se apporti modifiche. Succedeva anche con il 300, solo che non ti usciva l'avviso quando scaricavi il blocco.

 

2 ore fa, TheOutSideR ha scritto:

Reinizializzare le variabili ha il problema di mettere i valori a livello iniziale e quindi sballare tutto il ciclo?

Quando un blocco viene reinizializzato, le variabili assumono il valore scritto nella colonna "valore di avvio".
Quindi, il valore corrente di un eventuale conteggio pezzi, dopo la reinizializzazione, viene perso. Questo accade quando scarichi il DB, non al riavvio della CPU.

Per mantenere i valori al riavvio della cpu, si imposta la ritenzione.

 

2 ore fa, TheOutSideR ha scritto:

Un altra un po OT, come gestisco un valore temp se mando in stop (magari per una mancanza di tensione) ma questo va mantenuto ??

Una variabile "temp", come dice il nome, è temporanea. Non perde il valore solo se mandi in stop la cpu, perde il suo valore ad ogni ciclo della cpu, sempre.
In pratica, l'area delle variabili temp, quando esci dal blocco dove sono dichiarate, viene considerata libera, ed il sistema potrebbe usare quella stessa area per variabili temp di un altro blocco.
Con le cpu 300/400, entrando in un blocco, una variabile temp potrebbe avere un valore qualsiasi. La prima operazione da fare su una variabile temp doveva assolutamente essere un'operazione di scrittura. Con le cpu 1200/1500 le variabili temp vengono automaticamente azzerate. Personalmente, anche se c'è questo azzeramento in automatico, preferisco sempre inizializzare il valore delle variabili temp scrivendolo nel codice.
Le variabili temp devono sempre essere usate esclusivamente per risultati temporanei all'interno della funzione. Non le puoi usare per memorizzare dati.

[TheOutSideR]

Oh penso di aver capito! Per far chiarezza spiego tutto.

Indirizzamento assoluto: le variabili (che siano di un tag table o di un DB) hanno l'aspetto %MB1, %I0.0,%MW4 (sono esempi a caso). In questo caso queste variabili sono scritte dall' operatore che deciderà la memoria di locazione (si spera secondo una logica). Queste sono, tra le tante cose di essere dotate di capacità di non reinizializzare il valore (cioè le variabili non si resettato ogni volta al valore base, sembra quasi di parlare di ritenzione). Questo può avere il vantaggio quando si lavora in run time e si necessita fare modifiche. In questo modo le variabili non si rinizializzano.

 

Indirizzamento simbolico: può essere un nome (Motor_1 o il semplice Tag_1). In questo caso la memoria si approccia in modo diverso. La cpu da una allocazione casuale. Da come ho capito che mi avete detto le variabili si rinizializzano quando si carica il programma (non necessariamente passando da start a stop).

 

Ho capito o non ho capito un cavolo?? e nel caso fosse giusto, perché allora non si userebbe SOLO assoluto in quando più affidabile???

[batta]

Rileggi la prima riga del mio precedente post.

 

Anche i DB non ottimizzati vengono reinizializzati dpo una modifica.