Precisione temporizzatori nel tempo ciclo cpu

[Ale01]

Buongiorno a tutti

Volevo capire quale è la precisione dei temporizzatori tipo IEC Timer rispetto al tempo ciclo della Cpu.

Mi spiego meglio: 

Come si può attivare una uscita digitale con un temporizzatore TON_TIME che sia precisa al millisecondo, ma che venga attivata alla scadenza precisa del temporizzatore senza aspettare il tempo ciclo della Cpu.

Esempio: Tempo ciclo Cpu = 5mS e TON_TIME impostato a 8mS

Immagino che la cpu rinfreschi il tempo trascorso nel temporizzatore ogni volta che elabora l'istruzione stessa

Nell'esempio precedente immagino che se la cpu elabora l'istruzione TON_TIME alla scadenza di 1mS nel primo ciclo, 6mS nel secondo ciclo, 11mS nel terzo ciclo e così via, io debba aspettare il terzo ciclo perchè si attivi l'uscita.

E il tempo trascorso diventa 11mS e non più 8 mS

E corretta questa ipotesi ?

C'è un modo per effettuare conteggi precisi di unità di tempo anche utilizzando OB richiamati ciclicamente ?

 

[acquaman]

Il temporizzatore è esterno al ciclo, non viene aggiornato ad inizio ciclo come gli ingressi, nel momenti che si attiva il il Q del temporizzatore va a 1 e dal punto dove è in esecuzione il programma in poi il bit q è onse il programma al momento dell'attivazione è già passato nel punto dove lo analizzi dovrai aspettare un nuovo ciclo.

Se hai bisogno di una estrema precisione devi usare degli OB Ciclici.

[Ale01]

"nel momento che si attiva il il Q del temporizzatore va a 1 e dal punto dove è in esecuzione il programma in poi il bit q è on"

Era questo che volevo capire.

Per cui in qualsiasi punto del ciclo della Cpu, l'uscita Q del temporizzatore può andare ad 1.

Bisogna poi vedere in quale punto del ciclo della Cpu viene elaborata questa uscita, per capire se viene elaborata nel ciclo attuale o in quello successivo.

Grazie della risposta

[acquaman]

Esatto.

[Marco Fornaciari]

Nei PLC la precisione di un temporizzatore nella migliore delle ipotesi è sempre + 1 il tempo di ciclo di scansione, quindi il tempo di scamsione è influente.

Di fatto non ha importanza quando vengono letti e scritti gli I/O.

Con una task o OB o FB ciclico (dipende dal modello del PLC) si possono ottenere ritardi brevi e quasi ripetitivi.

 

Ma la domanda è obbligatoria: base dei tempi e tempo totale quanto valgono?

 

Se hai bisogno di tempi molto brevi e precisi, ma superiori a 10 mS, l'unico modo è usare una tasck ciclica a 5 mS e incrementare una variabile ogni scanzione, quindi usare una comparazione, in questo caso 1 S diventa 200 scansioni.

Con tasck richiamate con clock inferiore a 5 mS è un attimo mandare in crisi la CPU.

 

Infine con tempi superiori al secondo 5-10 mS di ritardo sono tipicamente ininfluenti per il 99,99% di casi.

Se hai bisogno di tempi precisi e molto brevi e soprattutto ripetitivi il PLC non è proprio l'ideale, salvo faccia poche cose.

Ma poi ai tempi del PLC bisogna aggiungere i tempi di ritardo di tutto il resto delle apparecchiature interessate, che raramente all'atto pratico sono certi e ripetitivi.

Un tempo per risolvere questi problemi esitevano schede specifiche con I/O dedicati, simili a quelle degli encoder.

Modificato: martedì alle 10:44 da Marco Fornaciari

[Ale01]

Faccio impostare i tempi da un dispositivo esterno che comunica in OPC-UA con la Cpu del Plc.

I tempi sono impostati su variabili DInt con unita di misura in mS che associo direttamente all'ingresso PT del TON_TIME.

In questa fase la macchina sta facendo dei test per cui i tempi andranno tutti tarati dall'utilizzatore del dispositivo esterno, comunque sono tutti nell'ordine dei mS.

Per adesso ho visto impostazioni che vanno da 10 a 100 mS

Avevo pensato anch'io ad OB ciclici che però hanno il limite che se troppo brevi causano lo stop della Cpu.

Più che altro volevo capire a quale errore massimo si va incontro nella peggiore delle ipotesi e la risposta dovrebbe essere 1 ciclo di scansione della Cpu che in questo momento è di circa 15mS.

Le uscite del Plc interessate dai temporizzatori. sono di tipo a transistor e su queste uscite sono stati applicati dei relè statici, per cui diciamo che i ritardi esterni sono stati limitati al minimo anche se purtroppo ci sono ma non sono eliminabili.

Il programma all'interno della Cpu non è per niente gravoso, e so che esiste una istruzione per aggiornare l'immagine delle uscite durante il ciclo di scansione prima dell'aggiornamento finale (Credo sia SYNC_PO) ma non so se esiste solo nel S7-1500 o anche nell' S7-1200.

[acquaman]

3 minuti fa, Ale01 ha scritto:

10 a 100 mS

Forse il plc non è lo strumento giusto per fare un sistema del genere.

 

6 minuti fa, Ale01 ha scritto:

Più che altro volevo capire a quale errore massimo si va incontro nella peggiore delle ipotesi

Almeno un ciclo scansione più devi metterci il tempo che se è di 15ms è già il 150%, poi devi aggiungere il tempo di risposta delle schede.

 

Ripeto, Forse il plc non è lo strumento giusto per fare un sistema del genere.

[Alessandro222]

I timer IEC, come TON, vengono elaborati una volta per ciclo insieme al programma principale (di solito in OB1 o OB simili), il che significa che il timer conta il tempo trascorso tra le chiamate e viene aggiornato solo quando viene eseguita l'istruzione TON. Pertanto, l'attivazione effettiva del timer può avvenire con un errore pari al tempo di ciclo.

Per risolvere il problema, ridurre il tempo di ciclo della CPU (OB1) se consentito dalle prestazioni, ridurre il ciclo a 1 ms o anche meno per aumentare la precisione dei timer. Su Tuttotek è stato descritto qualcosa di simile, potete dare un'occhiata lì.

[Livio Orsini]

Il 24/06/2025 alle 08:17 , Ale01 ha scritto:

Come si può attivare una uscita digitale con un temporizzatore TON_TIME che sia precisa al millisecondo, ma che venga attivata alla scadenza precisa del temporizzatore senza aspettare il tempo ciclo della Cpu.

 

Se vuoi questa precisione devi usare l'interrupt su clock di sistema e comandare le uscite con accesso diretto all'uscita, senza passare dal registro immagine.

[acquaman]

Posso chiederti cosa devi comandare, è mica un treno d'impulsi?

 

[Ale01]

2 ore fa, Alessandro222 ha scritto:

I timer IEC, come TON, vengono elaborati una volta per ciclo insieme al programma principale (di solito in OB1 o OB simili), il che significa che il timer conta il tempo trascorso tra le chiamate e viene aggiornato solo quando viene eseguita l'istruzione TON. Pertanto, l'attivazione effettiva del timer può avvenire con un errore pari al tempo di ciclo.

Per risolvere il problema, ridurre il tempo di ciclo della CPU (OB1) se consentito dalle prestazioni, ridurre il ciclo a 1 ms o anche meno per aumentare la precisione dei timer. Su Tuttotek è stato descritto qualcosa di simile, potete dare un'occhiata lì.

 

Il 24/06/2025 alle 08:28 , acquaman ha scritto:

Il temporizzatore è esterno al ciclo, non viene aggiornato ad inizio ciclo come gli ingressi, nel momenti che si attiva il il Q del temporizzatore va a 1 e dal punto dove è in esecuzione il programma in poi il bit q è onse il programma al momento dell'attivazione è già passato nel punto dove lo analizzi dovrai aspettare un nuovo ciclo.

Se hai bisogno di una estrema precisione devi usare degli OB Ciclici.

 

Però la tua risposta è l'esatto opposto di quanto spiegato da acquaman.... e sinceramente credo che la spiegazione fornita da acquaman sia più corretta.

Non penso che i temporizzatori con scala mS siano soggetti al tempo ciclo della Cpu.... altrimenti non avrebbe senso crearli con questa scala.

 

 

1 ora fa, Livio Orsini ha scritto:

 

Se vuoi questa precisione devi usare l'interrupt su clock di sistema e comandare le uscite con accesso diretto all'uscita, senza passare dal registro immagine.

 

Si, come dicevamo il limite è che non si possono impostare tempi troppo brevi di richiamo dell' OB di sistema, altrimenti la Cpu va in stop.

Idealmente ci vorrebbe un interrupt da 1mS

[Ale01]

1 ora fa, acquaman ha scritto:

Posso chiederti cosa devi comandare, è mica un treno d'impulsi?

 

 

No, sono semplicemente dei tempi di ritardo e durata di accensione di particolari flash e telecamere per registrare delle immagini elaborate poi da intelligenza artificiale per selezioni di buono o scarto del prodotto. I tempi devono essere brevi come indicato dal fornitore dei prodotti in particolare le luci...

[acquaman]

Gli illuminatori dovrebbero essere gestiti direttamente dalle telecamere cosi come dovrebbe gestire eventuali fc per che leggono il passaggio del pz da fotografare il plc è troppo lento per sincronizzare il tutto soprattutto ad alte velocità.

[Livio Orsini]

2 ore fa, Ale01 ha scritto:

Si, come dicevamo il limite è che non si possono impostare tempi troppo brevi di richiamo dell' OB di sistema, altrimenti la Cpu va in stop.

Idealmente ci vorrebbe un interrupt da 1mS

 

Allora non si tratta di precisione al ms, ma di risoluzione di 1ms.

[Ale01]

1 ora fa, acquaman ha scritto:

Gli illuminatori dovrebbero essere gestiti direttamente dalle telecamere cosi come dovrebbe gestire eventuali fc per che leggono il passaggio del pz da fotografare il plc è troppo lento per sincronizzare il tutto soprattutto ad alte velocità.

 

Dipende sempre da molte variabili e diciamo che non c'è uno standard.

In questo caso la velocità massima (Teorica) sarà di 1 pz/sec ma è tutto da provare, forse non si riuscirà ad arrivare a quella velocità.

Il Plc riceve il clock da un sensore e poi inizia le temporizzazioni necessarie per attivare luci e telecamere.

Forse non sarà la soluzione tecnicamente migliore, ma credo che adattando i tempi si possa riuscire a trovare una soluzione.

Per me era importante capire come si comportano i temporizzatori rispetto al ciclo della Cpu e vi ringrazio delle informazioni ricevute.

Nel primo pomeriggio ho provato a verificare il tempo trascorso ET dei TON_TIME che attivano le luci nel momento dell'attivazione di quest'ultime e devo dire che il tempo trascorso ET è uguale al tempo impostato PT.

Con l'andare delle prove verificheremo se si trova una soluzione stabile al sistema.