Variabili Locali Fc Dopo Interruzione Di Un Ob

[Zulio]

Salve nuovamente, visto che l'argomento ha suscitato la curiosita' di alcuni ecco le ultime novita':

ho telefonato al service Siemens; il tecnico mi ha detto che siccome uso una variabile locale,

al rientro dopo il richiamo di OB a tempo la vecchia DB puo' essere ancora valida oppure no!

A parte il fatto che sul manuale di programmazione con step7 viene dichiarato che sia le variabili locali

sia il numero e la dimensione del DB aperto vengono memorizzate, non si spiega come mai se l'apertura

del DB (sempre con variabile locale) viene eseguita ad ogni segmento il difetto scompare.

Come altra informazione vi posso dire che ho modificato la schedulazione orologio: OB35 e' rimasta,

come in origine, a 100ms con priorita' 12; mentre ho modificato il richiamo di OB32 (priorita' 9) portandolo

da 1000 a 10ms. Secondo voi la priorita' piu' bassa per un richiamo piu' frequente puo' costituire motivo

di malfunzionamento???? Questo ho dimenticato di chiedere perche' subito non rammentavo!

Ciao

[cisio]

Come altra informazione vi posso dire che ho modificato la schedulazione orologio: OB35 e' rimasta,

come in origine, a 100ms con priorita' 12; mentre ho modificato il richiamo di OB32 (priorita' 9) portandolo

da 1000 a 10ms. Secondo voi la priorita' piu' bassa per un richiamo piu' frequente puo' costituire motivo

di malfunzionamento????

sicuramente passare da un ciclo al secondo a 100 cicli al secondo aumenta di molto le probabilità che l'OB vada

a interrompere proprio mentre stai facendo le operazioni con db di istanza

se poi sia vero che esiste il problema non lo so, dovrei approfondire

ciao

[nick.kelevra]

Scusa il ritardo ho letto solo ora. Più o meno il test che ho fatto è simile al tuo, adesso l'ho cancellato ma erano proprio due righe semplici, in particolare ho testato il funzionamento di:

Nel blocco OB1:

OPN DB 1

OPN DI 2

CALL FC 1

L 1

T DBB 0

L 2

T DIB 0

Nel blocco FC1 ho scritto:

OPN DB 2

OPN DI 1

Ed il risultato che ottenevo, come ho detto, è la scrittura del valore 1 nel DB1 e del valore 2 nel DB2, esattamente come se non li avessi invertiti nell'FC1. Però ripeto, questo è un caso, non ho la certezza che se un OB interviene a tempo o in altri modi diversi dal richiamo normale di un blocco i registri possano venire modificati. Infatti non riesco a trovare una risposta per il funzionamento anomalo del programma di Zulio, mi dispiace.

P.S. scusa ma dal #26 se ho capito giusto, ho la certezza che la db aperta rimanga valida solo nel segmento in corso? o dovrebbe essere invece valida in tutto il blocco? Se è valida solo nel segmento in corso significa quindi che un interrupt a tempo non blocca l'esecuzione di un segmento ma solo tra segmenti in un blocco che viene interrotto temporaneamente?

Modificato: 24 aprile 2007 da nick.kelevra

[Zulio]

Ripeto che senza il richiamo OB a tempo: variabili locali, DB aperto, validita' dello stesso nell'intero blocco, tutto valido e testato.

L'inserimento di due OB ha sconvolto questa sequenza. Non ho dubbio sul funzionamento della CPU, quindi non mi rimane che pensare

ad un overflow dell'L-Stack. Uso una 317-2 PN/DP e l'area dello stack (destinata ad ogni classe di priorita') e' fissa. Non posso provare a modificarla per verifica. Di sicuro mi e' andata in stop la CPU più volte, ma non ho mai controllato il contenuto dei registri dopo l'interruzione.

Ci sono tutti i presupposti perche' il guaio risieda proprio in quello!

[TravelMen]

Ripeto che senza il richiamo OB a tempo: variabili locali, DB aperto, validita' dello stesso nell'intero blocco, tutto valido e testato.

Non avevo dubbi su cio, io volevo sapere cosa c'è di preciso negli OB che vengono richiamati a tempo!!

Ci sono percaso dei puntatori tipo AR1 o AR2??

Ci sono dei richiami a DB diverse da quella aperta nella tua FC/FB che sia??

Modificato: 24 aprile 2007 da TravelMen

[Zulio]

Allora OB32 richiama vari FB41 con relativa DB istanza (una <> per ogni richiamo).

Inoltre viene richiamata una funzione (contalitri) che a sua volta richiama una sola DB dichiarata come INPUT_VAR.

Voi avete capito? Io sto ancora meditando su quanto ho scritto!

Dopo cio' OB32 si interrrompe; OB35 richiama una funzione che a sua volta ne richiama altre 3. Anche queste richiamano 3 DB come INPUT_VAR.

Complicato? da descrivere si; da vedere un po meno!

[TravelMen]

Ok, per caso in uno qualunque fai uso dei puntatori AR??

Se percaso li usi, ricordati di sempre di salvare il contenuto di essi prima di usarli e poi ripristinarli, xchè tali puntatori vengono usati anche dal PLC per i fatti suoi.

Ovvero nel blocco devi avere una cosa simile:

TAR1 #SAVE_AR1

TAR2 #SAVE_AR2

istruzioni

istruzioni

LAR1 #SAVE_AR1

LAR2 #SAVE_AR2

Dove SAVE_AR1 e SAVE_AR2 sono dichiarate come dword locali

Per ora è l'unica possibilità che mi viene in testa.

PS ma la DB che ti da problemi e richiamata come istanza o globale?

Modificato: 24 aprile 2007 da TravelMen

[TravelMen]

Sempre io, rileggendo quanto da te scritto mi sorge un dubbio, il PLC ti va in stop??

Non è che il PLC non riesce a finire il richiamo del OB prima di avere un'altra chiamata??

[Zulio]

Allora: la CPU non va in stop, ha un tempo di ciclo di 30-35ms.

In OB 32 richiamo FC che contiene un AUF #DB_local e pure un: LAR1 P#0.0; esegue un loop 160 volte ed esce.

Quindi viene richiamata nuovamente la stessa FC con parametri formali <>; e lo stesso ancora una volta.

Poi torna in normale esecuzione.

[TravelMen]

LAR1 P#0.0;

Allaro fai uso dei puntatori AR.

Hai cio che ti ho scritto nel mesaggio di qui sopra ovvero

TAR1 #SAVE_AR1

TAR2 #SAVE_AR2

istruzioni

istruzioni

LAR1 #SAVE_AR1

LAR2 #SAVE_AR2

Dove SAVE_AR1 e SAVE_AR2 sono dichiarate come dword locali

Prova ad aggiungere queste riche e vedi cosa succede

[Zulio]

Ti ringrazio per il tempo dedicato, spero in futuro di ricambiare a mia volta. Appena possibile provo con le indicazioni che mi hai dato.

Alla prossima...