Variabili Locali Fc Dopo Interruzione Di Un Ob

[mfantina]

Ciao a tutti,

ho avuto un problema su un impianto con la costruzione di una variabile di tipo ANY e vorrei sapere questo:

In un blocco parametrizzato utilizzo delle variabili locali (IN, OUT e TEMP), se durante l'elaborazione di questo blocco mi interviene un OB (es. OB86), cosa mi succede ai valori delle variabili temporanee che stavo utilizzando??

Grazie a tutti!!!

Marcello

[mario_lato]

Ciao Marcello,

non è possibile usare variabili tipo ANY dentro blocchi parametrizzati !!!!! dovresti consultare meglio il manuale

ciao Mario

[mfantina]

Di nuovo io.

A parte il discorso delle variabili ANY... vorrei sapere cosa succede all'area delle variabili temporanee dopo un intervento di un OB. Nel mio caso ho un OB86 per la diagnostica dei nodi Profibus che potrebbe intervenire in qualsiasi momento. Utilizzando FC parametrizzati, che usano IN/OUT/TEMP, e l'OB86 usa variabili temporanee, cosa succede i caso di intervento dell'OB86 nel mezzo dell'esecuzione dell'FC.

All'inizio dell'FC mi inizializzo le variabili TEMP e le utilizzo nelle varie elaborazioni. Se l'OB interviene tra le inizializzazioni e l'utilizzo delle variabili, cosa succede?

Prima di richiamare l'OB vengono memorizzate le varie informazioni di elaborazione, ma per l'area delle variabili temporanee??

Grazie.

Marcello

[mario_lato]

ciao Marcello,

mi correggo... è possibile usare variabile tipo any ma solo con alcuni tipi di blocchi par. se vuoi,

visto che non sei molto pratico,

ti indico dove puoi trovare il manuale Siemens che ti spiega esattamente come finziona il discorso

ciao Mario

[mario_lato]

ciao Marcello,

mi spieghi esattamente quale è il tuo problema ?

[mario_lato]

mi sono documentato, l'area delle variabili temporanee viene sicuramente sporcata....mi sembra un modo

molto poco ortodosso di gestire i blocchi. Fatti consigliare da qualche esperto

ciao

[batta]

L'area di memoria dedicata alle variabili locali di un blocco dovrebbe rimanere impegnata fino all'uscita dal blocco stesso.

Se stai eseguendo FCxxx e ad un certo punto viene chiamato un OB, l'esecuzione di FCxxx non è comunque terminata, quindi le sue variabili locali dovrebbero rimanere integre, anche se nel frattempo viene eseguito l'OB.

[batta]

mi sono documentato, l'area delle variabili temporanee viene sicuramente sporcata....

Potresti dirmi dove l'hai letto?

Grazie

[mfantina]

Visto che anche nei blocchi standard Siemens, in particolare ho visto l'FC25 (MAX) nella biblioteca funzioni IEC di STEP7 v5.4, vengono usati come parametri IN delle variabili di tipo ANY e delle BOOL come variabili TEMP come le uso io, vorrei sapere quale altro modo più ortodosso ci sia... Mi potete dare il nome di quel manuale?

[mario_lato]

Marcello,

non frainterdermi.... probabilmente non hai compreso bene quanto volevo spiegarti.

Ho capito che seu alle prime armi circa l'utilizzo di blocchi parametrizzati e quindi volevo

aiutarti trasmettendomi le mie conoscenze.

Se un interrupt interviene le variabili temporanee vengono sovrascritte: ad esempio mi è capitato che

su un pannello siemens dove per gestione della produzione utilizzavo un blocco con

puntatore di variabili temporanee, all'intervento di un OB dovuto ad un allarme sulla rete.... mi si sono

sovrascritte le variabili relative a produzione e conteggi vari (avevo visualizzato sul pannello numeri che non centravano nulla !!! nei campi dove in realtà avrei dovuto avere informazioni circa modello in produzione ecc.)

Da quel momento mi sono documentato

In giornata ti indico il manuale che mi richiredi.... ti consiglio di leggere il manuale S7 al capitolo variabilii temporanee.

se hai bisogno di altre spiegazioni..sono a disposizione

ciao

[batta]

Io non ho trovato niente che dica che le variabili locali vengono sovrascritte dal richiamo di un ob.

Se così fosse, visto che è impossibile sapere quando viene lanciato un OB, non si potrebbero MAI usare le variabili locali.

Una variabile locale ha vita fino a quando non esco dal blocco nel quale è stata dichiarata.

[Vince73PLC]

Concordo con quanto scritto da Batta. Se fosse come dice Mario Lata non si potrebbero usare MAI le variabili locali proprio per l'imprevedibilità di un richiamo OB.

Il problema avuto da Mario Lata è a mio avviso dovuto a un passaggio di parametri di tipo complesso su Fc o Fb.

Vado a memoria, dovrei ricercare la documentazione quindi potrei anche scrivere qualcosa di errato:

in caso di passaggio di parametri di tipo complesso in un FC viene passato un pointer.

in caso fb in e out il valore, in/out invece ancora un pointer.

in caso di fb di multiistanza la situazione dei puntatori è ancora più complessa poichè per accedere ai dati di istanza la cpu sfrutta il registro AR2 e DI.

In conclusione quando si passano in Fc o Fb parametri di tipo complesso, è necessario prestare moltissima attenzione ad una eventuale programmazione di registri AR1 e AR2 nei blocchi stessi.

Saluti

[mario_lato]

Provare a dare un'occhio a quanto descritto di seguito, in particolare al punto variabili

temporaneee "VAR CONSTANT"

tale attributo impone che il valore della relativa variabile non possa essere modificato una volta che è stato dichiarato;

è quanto è necessario fare per evitare di "sporcare" l'area

11.6.3 Tipi di variabile

La Norma definisce un vasto set di tipi di variabile ma ammette anche la definizione di nuovi tipi da parte dell’utente; si possono poi individuare diverse categorie secondo cui organizzare tali tipologie.

All’inizio di ogni POU( ) è possibile dichiarare le seguenti variabili:

 Variabili locali, cioè visibili solo all’interno della POU; devono essere dichiarate utilizzando la parola chiave VAR :

VAR

vel : REAL;

allarme : BOOL;

END_VAR

 Variabili di ingresso, ossia variabili che consentono alle POU di ricevere dati dall’esterno:

VAR_INPUT

ERRORE: REAL;

VAL_MASSIMO: REAL;

END_VAR

 Variabili di uscita, cioè variabili che consentono alle POU di scambiare dati con l’esterno:

VAR_OUTPUT

POSIZIONE_VALVOLA: BOOL;

END_VAR

 Variabili di Input-output: trattasi di tipi particolari di variabili, le quali possono essere utilizzate sia come variabili di ingresso che, successivamente all’elaborazione, come variabili d’uscita:

VAR_IN_OUT

STATO: REAL;

END_VAR

 Variabili temporanee: trattasi di variabili che vengono impiegate temporaneamente; a livello hardware, esse sono generalmente poste in un area temporanea della memoria, in genere in uno stack:

VAR_TEMP

RESULT : REAL

END_VAR

A tutti i tipi di variabile è anche associabile uno dei seguenti attributi:

 Retain : tale attributo impone che il valore della relativa variabile venga mantenuto anche in mancanza di alimentazione del PLC:

VAR_OUT RETAIN

Speed_profile: ARRAY[1..4] OF REAL;

END_VAR

 Constant: tale attributo impone che il valore della relativa variabile non possa essere modificato una volta che è stato dichiarato:

VAR CONSTANT

Gear_ratio : SINT := 12;

END_VAR

 AT: serve ad allocare la variabile ad un preciso indirizzo

VAR

SCAN_DATA AT %IW10: ARRAY[1..8] OF SINT;

END_VAR

Le allocazioni in memoria avvengono attraverso le seguenti sintassi:

%I100 (* Input memory bit 100 *)

%IW122 (* Input memory word 122 *)

%MW150 (* Memory location word 150 *)

I → Allocazione in memoria di input

Q → Allocazione in memoria di output

M → Allocazione in memoria interna

X →Bit

B → Byte (8bit)

W → Word (16 bit)

D →Double Word (32 bit)

L →Long Word (64 bit)

[Vince73PLC]

Mario, scusa ma non riesco a capire.

in risposta a mfantina ti dico solo leggi il manuale "programmazione con step7" 6ES7810-4CA08-8EW0, scaricabile da internet in formato PDF.

L'appendice A2 spiega la memoria della CPU e A.2.3.3 lo stack dei dati locali.

Spero di esserti stato utile.

Ciao

Vincenzo

[Ecup]

Se un interrupt interviene le variabili temporanee vengono sovrascritte: ad esempio mi è capitato che

su un pannello siemens dove per gestione della produzione utilizzavo un blocco con

puntatore di variabili temporanee, all'intervento di un OB dovuto ad un allarme sulla rete.... mi si sono

sovrascritte le variabili relative a produzione e conteggi vari

Mi pare strano... se così fosse non bisognerebbe mai usare le variabili temporanee, perché non puoi mai sapere quando interviene un OB...

AFAIK (andrò a verificare) le variabili temporanee di una FC rimangono tali fintanto che l'esecuzione della FC non viene terminata.

Ovvio che se poi dentro l'FC ti metti a leggere le varibaili temporanee prima di scriverle (ho visto fare anche questo) ci sarà "qualcosa" che non funziona...

ciao

[mario_lato]

Dati locali

I dati locali memorizzano quanto segue:

• Le variabili temporanee dei blocchi di codice

• L'informazione di start dei blocchi organizzativi

• Parametri di trasferimento

• Risultati intermedi

Variabili temporanee

Al momento della creazione di blocchi, è possibile dichiarare variabili temporanee (TEMP)

che siano disponibili solo durante l'elaborazione del blocco e che quindi vengano

sovrascritte. Questi dati locali hanno una lunghezza fissa per ciascun OB. Prima del primo

accesso in lettura, i dati locali devono essere inizializzati. Ogni blocco organizzativo, inoltre,

ha bisogno di 20 byte di dati locali per la sua informazione di start. L'accesso ai dati locali è

più rapido di quello ai dati nei DB.

La CPU è dotata di memoria per le variabili temporali (dati locali) dei blocchi appena

elaborati. Le dimensioni di questa area di memoria dipendono dalla CPU. Essa viene

suddivisa in parti uguali tra le classi di priorità. Ogni classe di priorità ha una propria area dei

dati locali.

Cautela

Tutte le variabili temporanee (TEMP) di un OB e i blocchi subordinati vengono memorizzati

nei dati locali. L'impiego di molti livelli di annidamento nell'elaborazione del blocco può

causare un overflow dell'area dei dati locali.

Se si superano le dimensioni consentite per i dati locali di una classe di priorità, le CPU

entrano in stato di funzionamento STOP.

In questo caso, tenere in considerazione i dati locali richiesti dagli OB di errore sincrono,

che vengono sempre assegnati alla rispettiva classe di priorità che ha causato l'errore.

Vedere anche

[mfantina]

Finalmente ho trovato una risposta che mi soddisfa.

Come disse Vincenzo, sono andato a vedere il manuale (installato con STEP7) "Programmazione con STEP7" all'appendice 2.

Al paragrafo A.2.3.3 è spiegato bene come viene gestito lo stack dei dati locali. Ogni classe di priorità ha una sua area di dati locali dedicata.

Questo significa che il mio FC parametrizzato, richiamato in OB1, o comunque in sottoprogrammi in OB1, non verrà mai disturbato dal richiamo di un OB di errore o a tempo perchè hanno altre classi di priorità!

L'unica avvertenza è che l'area di stack non sia sufficiente in caso di eccessivo annidamento, ma in questo caso la CPU va in STOP (non è sicuramente il mio caso!).

Inoltre sulle CPU400 e CPU318 è possibile assegnare un'area di dati locali per ogni classe di priorità.

Grazie per l'aiuto!

[mario_lato]

ciao Marcello,

sono contento di averti risolto il problema.

Se dovessi ancora necessitare aiuto sarò lieto supportarti.

Mi raccomando, i manuali non andrebbero mai sottovalutati

ciao alla prossima

[batta]

Bene, dubbio chiarito.

Quindi le tue affermazioni

post #6:

mi sono documentato, l'area delle variabili temporanee viene sicuramente sporcata....mi sembra un modo

molto poco ortodosso di gestire i blocchi. Fatti consigliare da qualche esperto

post #10:

Se un interrupt interviene le variabili temporanee vengono sovrascritte...

sono errate.

Del resto, come già detto, se così non fosse le variabili locali sarebbero inutilizabili.

Mi raccomando, i manuali non andrebbero mai sottovalutati

e soprattutto vanno correttamente interpretati.

Saltare a conclusioni affrettate, come quelle sopraccitate, può portare fuori strada te e anche gli altri.

Quando dici (cito nuovamente)

mi sono documentato, l'area delle variabili temporanee viene sicuramente sporcata....

qualcuno ci potrebbe credere.

[Ecup]

sono contento di averti risolto il problema.

Scusa eh... nulla contro di te ma, con tutto rispetto, la soluzione ritenuta "soddisfacente" è quella arrivata da Vincenzo :

Come disse Vincenzo, sono andato a vedere il manuale (installato con STEP7) "Programmazione con STEP7" all'appendice 2.

Al paragrafo A.2.3.3 è spiegato bene come viene gestito lo stack dei dati locali. Ogni classe di priorità ha una sua area di dati locali dedicata.

Questo significa che il mio FC parametrizzato, richiamato in OB1, o comunque in sottoprogrammi in OB1, non verrà mai disturbato dal richiamo di un OB di errore o a tempo perchè hanno altre classi di priorità!

Tantopiù che tu (probabilmente intendendo qualcos'altro) avevi detto il contrario :

l'area delle variabili temporanee viene sicuramente sporcata

oltre a pasticciare un po' su altre cose che non c'entravano niente

non è possibile usare variabili tipo ANY dentro blocchi parametrizzati

mi correggo... è possibile usare variabile tipo any ma solo con alcuni tipi di blocchi

alla prossima

[mario_lato]

ciao ragazzi,

in ogni caso ho dato il mio parere, inizialmente ho risposto secondo memoria o comunque

impulsivamente..... Marcello mi sembra nuovo del mestiere e quindi ho cercato di spingerlo

verso la consultazione dei manuali (talvolta i novelli pensano di non averne bisogno).

Anche oggi ho imparato qualcosa di nuovo.

grazie dei suggerimenti

buon lavoro a tutti

[Zulio]

Ciao a tutti, vorrei riprendere questa discussione perchè mi è recentemente capitato qualcosa di simile.

Ho un sw che automatizza una impastatrice con 100 ricette. Si identificano con un numero e richiamo i dati cosi':

L ricetta_selezionata

T [#numero_ricetta]

AUF DB [#numero_ricetta]

L DBB23

T MB56

L DBB56

T MB12

ecc

prima di usare OB a tempo tutto funzionava.

Improvvisamente, quando ho aggiunto OB a tempo per gestire PID, un disastro!!!!!!1!

i dati scritti sulle ricette non venivano più trasferiti. Mi trovavo sempre 0

Ho risolto richiamando ogni volta il blocco DB:

L ricetta_selezionata

T [#numero_ricetta]

AUF DB [#numero_ricetta]

L DBB23

T MB56

AUF DB [#numero_ricetta]

L DBB56

T MB12

AUF DB [#numero_ricetta]

L MW100

T DBW 64

Ritengo quindi che dati locali non vengano toccati ma il DB aperto ..... si!!!!! eccome!

Suggerimenti?

Buona Domenica

[TravelMen]

Ciao Zulio se non ricordo male, una S7-300 può gestire due DB aperte simultanemente, ovvero una globale ed una di istanza.

Mi spiego meglio:

quando fai una un istruzione del tipo L DBxx.DBxxxx.x

la CPU, chiude se ha una vecchia DB globale aperta, in seguito apre la DB della tua istruzione.

Forse il tuo problema deriva dal fatto che nella tua OB richiamata a tempo apri una DB globale, se così fosse puoi provare a fare così:

nel OB invece di scrivere OPN DB xxx

apri una DB come DB di istanza ovvero OPN DI xxx (attento ai richiami di FB)

Spero di essere stato abbastanza chiaro.

[nick.kelevra]

Ciao Zullio,

sinceramente non vorrei dire nulla di scorretto ma mi pareva di aver letto su qualche manuale che anche per i DB aperti esiste un salvataggio durante il richiamo degli OB. Ho fatto una rapida prova prova comunque, ho aperto due DB nell'OB1, il DB1 come DB normale e il DB 2 come DB di istanza. Ho quindi richiamato l'FC1, il quale apre il DB 1 come di istanza e il DB 2 come normale. Quindi l'FC1 termina e l'OB1 scrive 1 nella prima parola del DB normale e 2 nella prima parola del DB aperto come d'istanza. Il risultato della scrittura è stato quello che avrei ottenuto senza il richiamo dell'FC1, qunidi deduco che quello che fai in un blocco richiamato non ha influenza sui registri dei DB del blocco chiamante. Ora non so dirti se lo stesso comportamento avviene anche se i blocchi intervengono a tempo senza la chiamata.

Per il tuo problema non so darti una soluzione. Mi dispiace

[TravelMen]

Caro nick.kelevra toglimi dei dubbi, nel FC1 vai a scrivere o fare qualcosa sulle DB??

In ogni caso 6 hai possibilità, la stessa prova, la dovresti fare aprendo 2 DB differenti una in OB1 ed un'altra nell' FC1 del tipo

nel OB1 scrivere:

OPN DB 1

L 5

CALL FC1

T DBW0

e nel FC1 scrivere

OPN DB 2

L 3

T DBW0

E poi vedere se trovi scritto 5 in DB1.DBW0, sicuramente troverai 3 in DB2.DBW0.

Questo assomiglia gia di + al caso di Zulio

Modificato: 23 aprile 2007 da TravelMen