Grandi dubbi su variabili temp e la memoria

1 gennaio 2014

Ciao ragazzi vi scrivo afflitto da dubbi sulle variabili temp. Le variabili temp di un FB o FC si appoggiano tutte su una memoria propria . ( correggetemi se sbaglio) appunto per questo ho letto che bisogna fare molta attenzione nel usarla, per il motivo che si possono sovrapporre dei valori. Volevo porvi un piccolo esempio : allora io mi creo un FB e dentro la sezione TEMP dichiaro una variabile di un temporizzatore (s5t#50ms) . Ok ora che ho creato la mia FB ho bisogno di richiamarla 4 volte. Quando io andrò a eseguire il mio programma partirà FB1 poi supponiamo che parte dopo 20 MS FB 2 . Cosa succede che la variabile temp s5t#50ms del FB 1 verra sovrascritta dalla variabile Temp del FB 2? Portando così il programma in errore?grazie molte

Inviato dall'app. Mobile di PLC Forum da iPhone6,2

1 gennaio 2014

Esistono in quasi, se non in tutti gli ambienti di sviluppo due grandi categorie di variabili. Quelle globali e quelle locali, e questo vale anche per S7.

Quelle globali sono quelle che tu dichiari nelle tabelle delle variabili, ed esse sono visibili, e sopratutto mantengono il valore ad esso assegnato in tutte le routine (OB, FC,FB ecc.) Queste devono essere univoche in tutto il programma. In pratica non possono esistere due variabili che abbiano lo stesso nome.

Poi esistono le variabili locali, che vengono eseguite e sono valide e visibili solo ed esclusivamente nella routine nel quale sono state dichiarate. Queste sono le variabili TEMP di cui tu parli. Di queste (con lo stesso nome) ne possono esistere più di una in tutto il programma. Ma sempre una sola per ogni routine.

Pertanto acquisiscono il valore ad esse assegnate, e lo mantengono per tutto il tempo in cui è in esecuzione la routine di appartenenza. Una volta chiusa perdono il loro "indirizzamento". In genere servono per appoggiarci dei risultati (intermedi) durante l'esecuzione della routine. Tanto per farti un esempio, immagina che tu debba fare un semplice calcolo matematico (a+b+c). Quando esegui la prima addizione (a + b ) appoggi il risultato in una variabile temp. che poi utilizzerai per sommarla al valore c.

Una cosa importante che non va mai dimenticata:

Alle variabili temp., prima di essere usate devi assegnargli un valore, altrimenti acquisiscono un valore casuale.

Modificato: 2 gennaio 2014 da Giuseppe Signorella

2 gennaio 2014

Chiarissimo Giuseppe , praticamente l'esempio mio dei temporizzatori era senza senso , per il motivo che inserire un temporizzatore con un valore fisso nelle variabili locali temp non è logico. Ritornando sul tuo esempio(a+b+c) , se io lo richiamo 100 volte FB al interno del programma è succede che nello stesso istante di tempo viene richiamato 40 volte possibile che il risultato di (a+ risulti sfalsato? Possiede un limite elevato questa memoria temporanea ?grazie mille della risposta auguri di buon anno

Scusate ma lo smile con l'occhiali si è inserito automaticamente . Probabilmente la b col la ) forma questo smile . La formula giusta è (a+b...)

2 gennaio 2014

se io lo richiamo 100 volte FB al interno del programma è succede che nello stesso istante di tempo viene richiamato 40 volte possibile che il risultato di (a+ risulti sfalsato? Possiede un limite elevato questa memoria temporanea ?

Non capisco cosa vuoi dire con questa frase comunque...

Le variabili locali funzionano così:

Il sistema operativo assegna la memoria alla dichiarazione (quindi tutte le volte che richiami l'FB) , per es. se dichiari la variabile locale "pippo" come int, verranno allocati 2 bytes di memoria nella RAM secondo un criterio prestabilito dal sistema operativo, quindi ad un indirizzo di memoria sconosciuto al programmatore. Quando l'FB finisce, la memoria viene liberata (in termine tecnico deallocata) e potrà essere utilizzata da un'altra variabile locale.

Il sistema operativo Siemens non pulisce la memoria prima di riallocarla quindi (è questo il senso di quello che ti ha spiegato Giuseppe), quando tu richiami la variabile locale pippo all'interno dell'FB, sicuramente ti troverai un valore dipendente dall'ultimo utilizzo che il sistema operativo ha fatto di quella porzione di memoria. Quindi è obbligatorio assegnare un valore a queste variabili prima dell'utilizzo, altrimenti otterrai dei bug a volte anche difficilmente individuabili.

Ciao

2 gennaio 2014

GraZie della risposta . Ma nelle variabili locali temp oltre a stare molto attenti a assegnare un valore prima del utilizzo . Bisogna prestare altre attenzioni?

Inviato dall'app. Mobile di PLC Forum da iPhone6,2

2 gennaio 2014

No, sono variabili esattamente come tutte le altre, solo che vengono distrutte (deallocate) all'uscita della routine nelle quali sono state dichiarate.

2 gennaio 2014

Grazie lucius, a questo punto non mi è chiaro al 1000 . È preferibile usare più volte al interno del programma una FB anziché una FC come mai questo?

Inviato dall'app. Mobile di PLC Forum da iPhone6,2

2 gennaio 2014

C'è un altra avvertenza, lo spazio di allocazione delle variabili temp non è infinito, dipende dal tipo di cpu, se usi blocchi in cascata che hanno molte temp è possibile sforare e la cpu va in stop.

P.es. se lo stack è di 256 bytes, e OB1 ne usa supponiamo 56 te ne rimangono 200, tu richiami 2 volte di seguito un ipotetico FC1 che ne usa 190 non succede niente, ma se dall'interno di FC1 richiami un altro FC o FB che ne usa più di 10 la cpu va in stop.

2 gennaio 2014

Perché è preferibile usare più volte al interno del programma una FB anziché una FC come mai questo?

e chi l'ha detto? Modificato: 2 gennaio 2014 da JumpMan

2 gennaio 2014

Perché è preferibile usare più volte al interno del programma una FB anziché una FC come mai questo?

E chi te l'ha detto? La suddivisione di un programma in blocchi FB e FC è dettata da come il programmatore decide di strutturare il software e dal suo ordine (o disordine :smile: ) mentale.

L'unica differenza tra gli FB e gli FC è che nei primi puoi usare anche delle variabili locali statiche, quindi retentive (associando al richiamo dell'FB una DB locale o di istanza), mentre con l'FC ciò non è possibile.

Step7 per non perdere i contenuti delle variabili si appoggia sempre su DB che quindi, anche se dichiarate come locali o di istanza ad un FB, sono comunque visibili e modificabili anche al resto dell'applicazione. Questo è un sistema che non ha molto senso e che può creare problemi (e generare bug) soprattutto ai neofiti.

Io uso Siemens saltuariamente quindi non sono certo il più indicato a darti consigli su come è meglio strutturare un programma, comunque posso dirti che normalmente suddivido il tutto in blocchi logici tramite FC, (ad es. suddividendo le varie zone dell'impianto o le funzionalità) oppure per fare calcoli.

Le FB le utilizzo sempre quando mi servono appunto variabili locali statiche o per fare delle multi istanze, prestazione veramente notevole ed utile di Siemens ma purtroppo non facilissima non tanto nell'utilizzo quanto nel debug.

C'è un altra avvertenza, lo spazio di allocazione delle variabili temp non è infinito, dipende dal tipo di cpu, se usi blocchi in cascata che hanno molte temp è possibile sforare e la cpu va in stop.

Urca JumpMan, a me non è mai capitato di saturare la memoria, ma che programmi fai? Ciclosincrotroni al CERN? :lol: :lol: :lol:

Modificato: 2 gennaio 2014 da lucios

2 gennaio 2014

Che è meglio usare un blocco FB in più volte nel programma (richiamare per esempio un contatore creato in un FB per 15 volte nello stesso OB) mi è stato consigliato da un tecnico che seguiva plc siemens , mi ha spiegato che se uso FB rischio di fare meno casino con le variabili locali , per quello mi è salito questo dubbio , che ora mi rendo conto grazie a voi che se mi tenevo le mie vecchie idee stavo meglio , grazie mille ragazzi

Inviato dall'app. Mobile di PLC Forum da iPhone6,2

2 gennaio 2014

Urca JumpMan, a me non è mai capitato di saturare la memoria, ma che programmi fai? Ciclosincrotroni al CERN?

Mica ho detto che mi è successo, l'ho detto per completezza, comunque 256 bytes non sono poi così tanti... e un bel po' sono usati dalle local di OB1

FB rischio di fare meno casino con le variabili locali

Il casino che intendeva lui è quanto ti hanno spiegato qua sopra, era più facile spiegarti questo che farti deragliare obbligatoriamente verso gli FB

Modificato: 2 gennaio 2014 da JumpMan

2 gennaio 2014

Capito jumpman, voi cosa mi consigliate ragazzi? Per essere più ordinato possibile .

Inviato dall'app. Mobile di PLC Forum da iPhone6,2

2 gennaio 2014

Se posso darti un ulteriore consiglio, quando vai a scrivere una funzione devi pensare se questa andrà usata solo in quel progetto o se pensi che possa essere riutilizzata in seguito, in quest'ultimo caso evita categoricamente di usare al suo interno variabili dell'area M, Z, T, E, A indirizzati in maniera assoluta, questo ti consentirà la completa portabilità della funzione che stai scrivendo, se hai bisogno di leggere scrivere su quegli operandi passali nei parametri in/out.

Per i calcoli interni usa le temp,i valori che devono rimanere memorizzati li puoi passare al blocco chiamante tramite un parametro out o in-out , se sono molti conviene usare un FB e scriverli nelle variabili STAT (vanno nella DB di istanza). Le variabili STAT non compaiono nelle righe di richiamo di un FB, ma sono accessibili da tutto il programma e dagli HMI collegati (questo potrebbe essere un altro buon motivo per scrivere un FB piuttosto che un FC).

Poi la scelta tra FB e FC andrà ovviamente valutata caso per caso, in base alle esigenze e all' esperienza.

2 gennaio 2014

Grazie mille jump man per avermi tolto molta nebbia sul cervello duro che ho , grazie a tutti

Inviato dall'app. Mobile di PLC Forum da iPhone6,2

3 gennaio 2014

Tutto giusto JumpMan, non sono molto d'accordo solo su questo:

se sono molti conviene usare un FB e scriverli nelle variabili STAT

Ogni funzione è meglio che comunichi con l'esterno esclusivamente tramite parametri (variabili) di input/output, questo per motivi di: portabilità, chiarezza logica nella struttura del programma e migliore comprensione. E' vero che con Step 7 c'è questo concetto anomalo di DB di istanza visibile dall'esterno che può servire come scappatoia ma, nella logica della programmazione strutturata, secondo me sarebbe da evitare.

Ciao

3 gennaio 2014

Ogni funzione è meglio che comunichi con l'esterno esclusivamente tramite parametri (variabili) di input/output, questo per motivi di: portabilità, chiarezza logica nella struttura del programma e migliore comprensione

Sono d'accordo, ma per molti intendo moooolti per il momento vado di fretta e non mi viene in mente un esempio pratico, quando avrò un minuto lo scriverò

Modificato: 3 gennaio 2014 da JumpMan

7 gennaio 2014

Ciao volevo chiedere una cosa, c'è un motivo esatto che io provo mettere un fronte di salita nel mio FB e lo dichiarò su una variabile locale STAT mi manda in stop la cpu ? Ciao e graZie

Inviato dall'app. Mobile di PLC Forum da iPhone6,2

7 gennaio 2014

non c'è motivo, io lo faccio sempre, hai guardato il buffer di diagnostica ?

7 gennaio 2014

Si è c'è scritto questo: STOP dovuto a errore di programmazione (ob non caricato o non caricabile, FRB assente) punto di interruzione nel programma utente: programma ciclico (ob1) Classe priorità :1. N FB : 3 Indirizzò blocco : 8. Stato attuale di funzionamento: RuN

Inviato dall'app. Mobile di PLC Forum da iPhone6,2

7 gennaio 2014

[at] lucios

Provo a buttare là un esempio sperando non risulti troppo pesante da leggere…

Supponiamo di voler visualizzare su un HMI la produzione di una macchina che giunta tavole di legno (quelle che si vedono sui travi lamellari), le tavole entrano in fila nella macchina ed escono unite per poi essere troncate alla misura desiderata, l’FB che conteggia i dati di produzione potrebbe essere parametrizzato in questo modo:

IN:

- BitAzzTab / BOOL / Bit per azzeramento tabella
- FcLama / BOOL / Segnale di troncatura (finecorsa lama)
- SezTav / REAL / Sezione delle tavole
- LunTro / REAL / Lunghezza di troncatura
- Giorno / BYTE / Giorno attuale
- Mese / BYTE / Mese attuale
- Anno / BYTE /Anno attuale

OUT:

- po_ml / REAL / Produzione odierna: Metri lineari
- po_mc / REAL / Produzione odierna: Metri cubi
- po_qt / INT / Produzione odierna: Quantità tavole

STAT:

- FF / Array [0..31] of BOOL / (32 fronti utilizzabili all’interno dell’FB)
- VolUltTavTro / REAL / Volume ultima tavola troncata
- Dummy / Array [1..non] of INT / <<< Impostare non per mantenere indirizzo iniziale tabella MA = 100.0
- MA / STRUCT / Tabella produzione Mese Attuale
   |--GG / Array [1..31] of STRUCT
         |--- ml / REAL / metri lineari
         |--- mc / REAL / metri cubi
         |--- qta / INT / quantità tavole

TEMP:

- RetVal / INT /  Appoggio per RET_VAL

In questo modo ci si ritroverà subito nella DB di istanza, a partire dall’indirizzo 100.0 una tabella di 31 righe con la produzione relativa ad ogni giorno del mese (queste 93 variabili non è proprio il caso che compaiano nel richiamo dell’FB anche perché non servono nel resto del programma ma solo nell’HMI).

All’interno dell’FB ci saranno ovviamente le istruzioni necessarie per incrementare i dati nella giusta “riga” della tabella su fronte dell’ingresso #FcLama

Si potrebbero in seguito implementare ulteriori 12 struct (una per ogni mese) ed aggiornarle automaticamente al cambio di data:

- GEN / STRUCT / Tabella produzione GENNAIO
   |--GG / Array [1..31] of STRUCT
         |--- ml / REAL / metri lineari
         |--- mc / REAL / metri cubi
         |--- qta / INT / quantità tavole
- … / STRUCT / Tabella produzione …
   |--GG / Array [1..31] of STRUCT
         |--- ml / REAL / metri lineari
         |--- mc / REAL / metri cubi
         |--- qta / INT / quantità tavole

E’ molto semplice copiare in blocco i dati del mese attuale in un altro mese:

      CALL  "BLKMOV"  // copia tabella mese attuale in tabella Gennaio
       SRCBLK :=#MA
       RET_VAL:=#RetVal
       DSTBLK :=#GEN

(ecco perché ho usato sopra il tipo di dati STRUCT, rende tutto molto leggibile)

Considerazioni finali:

L’array Dummy lo metto per poter aggiungere parametri in seguito senza dover rimappare tutte le variabili nell’HMI, in caso di HMI Siemens con sincronizzazione automatica si potrebbe anche omettere.

E’ chiaro che avrei ottenuto lo stesso risultato anche mettendo le tabelle su una ulteriore DB (diversa da quella d’istanza) e facendo a meno dei dati STAT, ma per me è indifferente lavorare in una maniera o nell’altra, Siemens permette di fare questo ed io a volte lo sfrutto l’importante è commentare sempre bene tutto quanto)

7 gennaio 2014

Se lo provo mettere sulle temp non va in errore , però il fronte sembra non esserci , il contatore assume dei valori sproporzionati

Inviato dall'app. Mobile di PLC Forum da iPhone6,2

7 gennaio 2014

scusa coquinati, stavo scrivendo la pappardella per risposta a lucios.

FB : 3 Indirizzò blocco : 8.

se premi il pulsante Apri blocco, su che istruzione si apre?

Se lo provo mettere sulle temp non va in errore , però il fronte sembra non esserci , il contatore assume dei valori sproporzionati

è normale

hai rigenerato e ricaricato la DB di istanza dopo che hai messo la STAT ?

Modificato: 7 gennaio 2014 da JumpMan

7 gennaio 2014

Tranquillo:-) sono io che non mi sono accorto che stavi scrivendo :-) dopo provo leggermi con calma il tutto:-)

Inviato dall'app. Mobile di PLC Forum da iPhone6,2

7 gennaio 2014

Come mai è normale scusa ? Cioè mettere un FP in una temp. Il blocco lo rigenerato perché mi dava un errore di data di creazione è caricato adesso provo vedere

Inviato dall'app. Mobile di PLC Forum da iPhone6,2

Accedi

Grandi dubbi su variabili temp e la memoria

Messaggi consigliati

coquinati

Giuseppe Signorella

coquinati

lucios

coquinati

lucios

coquinati

JumpMan

JumpMan

lucios

coquinati

JumpMan

coquinati

JumpMan

coquinati

lucios

JumpMan

coquinati

JumpMan

coquinati

JumpMan

coquinati

JumpMan

coquinati

coquinati

Crea un account o accedi per commentare

Crea un account

Accedi

Naviga

Attività