Dubbio Timer

[Gapo]

Ciao a tutti,

sto debuggando un software, e mi è venuto un dubbio...

Quando interrogo lo stato di un Timer, mi viene dato il suo stato nel momento preciso in cui lo interrogo, oppure lo stato è definito a inizio ciclo e rimane invariato fino a fine ciclo? (mi pare di notare comportamenti diversi tra un 315 e una 318...)

Grazie

ciao

[Gapo]

Come non detto... mi sono risposto da solo facendo qualche test mirato a forzare il comportamento dubbio.

Per la cronaca, lo stato è quello del momento preciso in cui faccio l'interrogazione, quindi (per chi ancora non lo sapeva) fate attenzione se interrogate uno stesso timer in punti diversi del codice, soprattutto se lo utilizzate per segnali impulsivi...

...ora vado a sistemare il sw

PS: sempre per cronaca... questo comportamento vale sia per la 315 che per la 318 solo che, essendo la 318 molto più potente, statisticamente vedevo il problema apparire più spesso sulla 315

Modificato: 30 settembre 2010 da Gapo

[mubeta]

Non ho ben capito, ma, ammesso che per interrogazione tu intenda lo stato dell'uscita durante il ciclo OB1, questa non cambia all'interno del ciclo di scansione. Per tutto il ciclo lo stato del timer è sempre lo stesso, anche se durante lo stesso è teoricamente scaduto il tempo di conteggio.

[amed]

Quando è messo ON il bit di attivazione di in timer (rit. ecc.) immagina che un dispositivo (ororlogio) cominci a contare il tempo e che ogni tanto, il tempo dall'orologio, sia scritto nel registro del tempo che scorre che ogni timer ha. Quando nel registro del tempo che scorre è scritto "tempo scaduto" ("0" se il timer conta ll'indietro, la costante di tempo se il timer conta in avanti) immediatamente il bit ritardato (d'uscita) del timer commuta. Le istruzioni del programma vanno a leggere lo stato di questo bit. Il programma può anche andare a leggere il contenuto del registro co il tempo che scorre ed usare delle comparazioni di ">=" o "<=". Il tempo nel registro con il che scorre può essere scritto in BCD o BIN. S7-300 ha 2 rigistri con il tempo nei 2 codici.

Nei PLC, in generale, il "refresh" del registro con il tempo che scorre può avvenire in 3 modi:

1) all'inizio di ogni scansione, quindi, lo stato del bit di "uscita" non cambia durante la scansione (S7-300);

2) all'esecuzione dell'istruzione di BOX, quindi, può succedere che il bit di uscita sia nello stato "0" quando è letto prima del BOX, e sia nello stato "1" dopo le

istruzione di BOX (significa che nel registro è stato scritto "tempo scaduto";

3) ad interrupt, cioè ogni 1 csec. o ogni 1msec, quindi, lo stato del bit di uscita può commutare in qualsiasi istante della scansione.

S7-200 ha tutti e 3 questi tipi di timer. In S7-1200 il refresh credo che avvenga ogni 1 msec.

ciao a tutti.

[Gapo]

Non ho ben capito, ma, ammesso che per interrogazione tu intenda lo stato dell'uscita durante il ciclo OB1, questa non cambia all'interno del ciclo di scansione. Per tutto il ciclo lo stato del timer è sempre lo stesso, anche se durante lo stesso è teoricamente scaduto il tempo di conteggio.

Ti posso assicurare che non è così... perlomeno sulle 315 e 318 dove ho fatto i test

[Gapo]

Quando è messo ON il bit di attivazione di in timer (rit. ecc.) immagina che un dispositivo (ororlogio) cominci a contare il tempo[...]

Lo so come funziona un Timer... la mia domanda (semplificando la questione) era:

"se interrogo a inizio di OB1 un Timer che sa contando, e lo interrogo anche alla fine di OB1, ottengo lo stesso risultato?"

Chi ha fatto il sw che stavo esaminando ha dato per scontato che fosse così, e infatti saltuariamente, in maniera del tutto casuale, succedevano delle cose strane sull'impianto...

Dopo aver verificato che non è così, ho fatto le dovute modifiche, e sembra andare tutto per il meglio.

ciao

PS: personalmente non mi ero mai posto il problema, forse perché ho l'abitudine di usare i timer in modo differente da com'erano usati in quel sw e non mi era mai capitato di scontrarmi con tale problematica

[amed]

Come hai fatto a fare il test? Grazie. Ciao

[Gapo]

-primo segmento di OB1: faccio partire il timer, interrogo lo stato, e lo memorizzo su un merket

-ultimo segmento di OB1: interrogo nuovamente lo stato e setto un bit se è diverso dal merker di prima

[amed]

Tra primo e ultimo segmento ci sono anche richiami di subroutine (FC, FB)? Perchè potrebbe essere che il Refresh del registro con il tempo che scorre lo fa anche prima di iniziare l'esecuzione delle subroutine come in S5. Ciao

[Gapo]

Tra primo e ultimo segmento ci sono anche richiami di subroutine (FC, FB)?

ovviamente si: c'è tutto il programma... un'ottantina di FC e una decina di FB...

Perchè potrebbe essere che il Refresh del registro con il tempo che scorre lo fa anche prima di iniziare l'esecuzione delle subroutine come in S5. Ciao

No: ho provato anche a mettere il check del timer nello stesso segmento, senza richiami di FC o FB di mezzo, ma aggiungendo un banale loop che allungansse il tempo tra le due interrogazioni (così da "esaperare" il problema, visto che nelle realtà dell'impianto càpita, statisticamente, ogni 150 cicli di lavorazione, grossomodo una volta ogni due giorni)

Il risultato è lo stesso...

[amed]

Hai ragione. Io provato con S7 314C-2DP con solo OB1 in cui ho messo un timer (SE) che comanda un bit nel primo segmento e un altro bit dopo una istruzione LOOP per allungare il tempo di scansione. Ho confrontato lo stato dei due bit con una istruazione di OR Esclusivo e si nota che dopo un po di tempo lo stato dei due bit è diverso nella stassa scansione. Se non ho commesso errori, che spero vengano eventualmente segnalati, sembra proprio che tu abbia veramente ragione. Si può ipotizzare che il refresch avvenga ad interrupt, forse ogni 1 cent. di sec. Ciao

UN T 0

L S5T#200MS

SE T 0

U T 0

S M 0.0

L 10 in Accumulatore 1 è caricata la costante 10 che dopo è tresferita in MW20

pipo: T MW 20 ad ogni salto all’indietro all’etichetta “pipo” il contenuto di MW 20

U A 124.0 decrementa di 1. Quando il contenuto di MW 20 scende a “0” il salto non

= A 124.0 è più eseguito.

= A 124.0 sono state messe delle istruzioni inutili sotto all’istruzione i salto allo

= A 124.0 indietro “LOOP”

L MW 20

LOOP pipo salto indietro a pipo”

U T 0

S M 0.1

X M 0.0

X M 0.1 quando M0.0 e M0.1 sono diversi

S M 0.2 è settato m0.2

U M 0.2

= A 124.0

U E 124.0

R M 0.2

R M 0.1

R M 0.0

[mubeta]

Non me ne ero mai accorto. Buono a sapersi.

Grazie anche a chi ha speso tempo per verificare.

[Gapo]

Hai ragione [...]

Senza mettere in dubbio l'efficacia del tuo codice, mi permetto di segnalare una variante a mio avviso un po' più semplice (che poi è quella che ho usato io):

UN T 100

L S5T#1S

SE T 100

U T 100

= M 100.0 //Risultato interrogazione prima del loop di ritardo

L 0

T MW 200

loop: NOP 0

L MW 200

+ 1

T MW 200

L 5000

<I

SPB loop

UN M 100.0 //Risultato interrogazione prima del loop di ritardo

U T 100 //Interrogazione dopo loop di ritardo

S M 100.1 //Bit che si setta se prima del loop il timer non era scaduto, ma adesso sì

Volendo si può aggiungere anche l'appoggio del valore di conteggio su due word (sempre prima e dopo il lopp) ed osservare che c'è sempre una differenza tra i due valori

ciao

Modificato: 5 ottobre 2010 da Gapo