Verifica Velocità Programma (fc) - tempi di eleborazione plc 314

[Livio Orsini]

I tempi di elaborazione delle singole funzioni dipendono molto dalle condizioni. In funzione dello stato di una variabile si può o meno eseguire un algoritmo che impegna la CPU per alcuni ms.

Comunque l'unico metodo sicuro per determinare il tempo impiegato da una funzione è il seguente.

Come prima istruzione si esegue una scrittura diretta ad un'uscita analogica (scrivendo p.e. il corrispondente di 10v), come ultima istruzione si ripete la scrittura della medesima uscita analogica caon un valore completamente diverso, se si è scritto 10v si scriverà 0v.

Osservando l'uscita con un buon oscilloscopio si possono misurare i tempi con sufficiente esattezza.

Perchè un'uscita analogica? Perchè è l'uscita più veloce e quella con i tempi di ritardo più costanti, quindi non ci saranno differenze apprezzabili tra il ritardo alla salita e quello alla discesa.

[FattoreDiPotenza]

Il micro processore della CPU , non ha il compito di eseguire solo il programma utente, anzi , deve:

Gestire la diagnostica della CPU , poi gestire le comunicazioni con l'esterno, MPI PROFIBUS ETHENET, poi leggere tutta l'immagine di periferia (più è grande , più tempo ci mette) aggiornare l'immagine IPI IPU, solo dopo esegue il programma , salvo il fatto che non vi siano delle operazioni cicliche su interruzione che si sommano o aggiornamenti IPU-IPI nel bel mazzo del programma.

In secondo luogo , è impossibile determinare in modo assoluto la durata di un blocco OB-FC-FB.

Se nel blocco esegui delle funzioni logiche booleane ad esempio , metti una serie di contatti NO che attivano una bobina , dodici contatti , con accesso alla area ingressi.

Bene , supponiamo che l'istruzione AND I x.x impieghi nella sua elaborazione 0,22 microsecondi e la funzione OUT ne impieghi 16 di microsecondi.

Fai un calcolo (12 x 0,22) + 16 =18,64 microsecondi.

Credi che indipendentemente da quale contatto sia chiuso o aperto il tempo di elaborazione sia uguale?

NO.

I valori , più o meno realistici che ti o riportato , sono solo validi se ogni istruzione è attraversata dal "flusso di corrente" dell'elaborazione , quindi tutti ON.

Se solo il primo contatto fosse aperto , quindi il flusso non prosegue lungo tutta la serie , tutte le altre istruzioni , assumono un tempo di esecuzione arbitrario di circa 1 microsecondo.

Quindi quel banale segmento ha una elaborazione che varia tra 18,64 a 12,22 microsecondi.

Il calcolo esatto del tempo di elaborazione , totale è difficile da determinare , varia in continuazione, verificalo tu stesso nelle opzioni delle proprietà della CPU e vedrai che ti viene visualizzato il tempo MIN , MAX e medio registrato nel momento della visualizzazione di quel momento.

Ogni aggiornamento che esegui della finestra , avrà un tempo diverso , al massimo quasi uguale.

Se vuoi che la tua funzione di "storico" non abbia una influenza inprevedibile sulla normale elaborazione , usala richiamandola in un blocco di schedulazione interrupt a tempo tipo OB 35.

[FattoreDiPotenza]

Il micro processore della CPU , non ha il compito di eseguire solo il programma utente, anzi , deve:

Gestire la diagnostica della CPU , poi gestire le comunicazioni con l'esterno, MPI PROFIBUS ETHENET, poi leggere tutta l'immagine di periferia (più è grande , più tempo ci mette) aggiornare l'immagine IPI IPU, solo dopo esegue il programma , salvo il fatto che non vi siano delle operazioni cicliche su interruzione che si sommano o aggiornamenti IPU-IPI nel bel mazzo del programma.

In secondo luogo , è impossibile determinare in modo assoluto la durata di un blocco OB-FC-FB.

Se nel blocco esegui delle funzioni logiche booleane ad esempio , metti una serie di contatti NO che attivano una bobina , dodici contatti , con accesso alla area ingressi.

Bene , supponiamo che l'istruzione AND I x.x impieghi nella sua elaborazione 0,22 microsecondi e la funzione OUT ne impieghi 16 di microsecondi.

Fai un calcolo (12 x 0,22) + 16 =18,64 microsecondi.

Credi che indipendentemente da quale contatto sia chiuso o aperto il tempo di elaborazione sia uguale?

NO.

I valori , più o meno realistici che ti o riportato , sono solo validi se ogni istruzione è attraversata dal "flusso di corrente" dell'elaborazione , quindi tutti ON.

Se solo il primo contatto fosse aperto , quindi il flusso non prosegue lungo tutta la serie , tutte le altre istruzioni , assumono un tempo di esecuzione arbitrario di circa 1 microsecondo.

Quindi quel banale segmento ha una elaborazione che varia tra 18,64 a 12,22 microsecondi.

Il calcolo esatto del tempo di elaborazione , totale è difficile da determinare , varia in continuazione, verificalo tu stesso nelle opzioni delle proprietà della CPU e vedrai che ti viene visualizzato il tempo MIN , MAX e medio registrato nel momento della visualizzazione di quel momento.

Ogni aggiornamento che esegui della finestra , avrà un tempo diverso , al massimo quasi uguale.

Se vuoi che la tua funzione di "storico" non abbia una influenza inprevedibile sulla normale elaborazione , usala richiamandola in un blocco di schedulazione interrupt a tempo tipo OB 35.

[Michele]

Ciao, ho visto con piacere due versioni differenti, quella teorica e quella pratica.

In effetti ieri stavo sfogliando il libricino delle operazione S7-300 dove per ogni tipo di operazione+operando+lung.parole ecc. con l'abbinamento al tipo di CPU riporta il Tempo Tipico di esecuzione in microsecondi. Questi valori possono darti un idea di quanto il CODICE possa essere pesante, ma in effetti come dice FattoreDiPotenza nel ciclo plc ci sono molte variabili.

La prova con l'oscilloscopio mi piace molto, oggi lo tiro fuori dalla "naftalina", è un po vecchio pero ci provo.

Mi stò procurando una CPU 314ifm con le analogiche integrate , cosi sono piu comodo.

Appena posso provare vi dico come sono andati i test.

Grazie 1000

Michele

[Michele]

Ciao, ho visto con piacere due versioni differenti, quella teorica e quella pratica.

In effetti ieri stavo sfogliando il libricino delle operazione S7-300 dove per ogni tipo di operazione+operando+lung.parole ecc. con l'abbinamento al tipo di CPU riporta il Tempo Tipico di esecuzione in microsecondi. Questi valori possono darti un idea di quanto il CODICE possa essere pesante, ma in effetti come dice FattoreDiPotenza nel ciclo plc ci sono molte variabili.

La prova con l'oscilloscopio mi piace molto, oggi lo tiro fuori dalla "naftalina", è un po vecchio pero ci provo.

Mi stò procurando una CPU 314ifm con le analogiche integrate , cosi sono piu comodo.

Appena posso provare vi dico come sono andati i test.

Grazie 1000

Michele

[Livio Orsini]

Fai attenzione che anche la misura reale del tempo, con l'oscilloscopio, è influenza dalle condizioni di elaborazione.

Cerco di chiarire meglio con un esempio.

La seriale lavora ad interrupt.Se durante le misure non c'è trasmisione seriale leggi il valore reale di elaborazione della tua funzione.

Se invece funziona la seriale, magari in modo pesante, tu leggerai un tempo che è la somma delle interruzioni, più il tempo di elaborazione della funzione.

Se hai necessità di tempi certi come, ad esempio, per una regolazione, devi fare come ti ha suggerito FattorediPotenza: leghi la funzione ad un interrupt a tempo con alta priorità

[Livio Orsini]

Fai attenzione che anche la misura reale del tempo, con l'oscilloscopio, è influenza dalle condizioni di elaborazione.

Cerco di chiarire meglio con un esempio.

La seriale lavora ad interrupt.Se durante le misure non c'è trasmisione seriale leggi il valore reale di elaborazione della tua funzione.

Se invece funziona la seriale, magari in modo pesante, tu leggerai un tempo che è la somma delle interruzioni, più il tempo di elaborazione della funzione.

Se hai necessità di tempi certi come, ad esempio, per una regolazione, devi fare come ti ha suggerito FattorediPotenza: leghi la funzione ad un interrupt a tempo con alta priorità

[Michele]

Molto interessante, con il metodo di Livio Orsini si potrebbe testare "pezzo per pezzo" del programma .

O testato le mie funzioni ed efettivamente creo non pochi problemi a delle parti di programma, percio ho provato ad ottimizzare il codice.

ho notato una leggera differenza (3ms sul tot. di eleborazione della FC di 15ms) tra lo stesso fc inizialmente compilato in KOP e sucessivamente riscritto in AWL. Visto la differenza ho incominciato a "pulire" il listato, ed sono arrivato a 11ms nel funzionamento di richiamo continuo della FC, poi quando schifto i dati dello "storico turno" si arriva a 25ms.

I tempi misurati sono da quando l'elaborazione entra nel FC (L 32000 , T PAW800) a quando esce ( L 0 , T PAW800).

Inserisco una foto del test.

ciao.

Procedo con altri test in serata.

[Michele]

Molto interessante, con il metodo di Livio Orsini si potrebbe testare "pezzo per pezzo" del programma .

O testato le mie funzioni ed efettivamente creo non pochi problemi a delle parti di programma, percio ho provato ad ottimizzare il codice.

ho notato una leggera differenza (3ms sul tot. di eleborazione della FC di 15ms) tra lo stesso fc inizialmente compilato in KOP e sucessivamente riscritto in AWL. Visto la differenza ho incominciato a "pulire" il listato, ed sono arrivato a 11ms nel funzionamento di richiamo continuo della FC, poi quando schifto i dati dello "storico turno" si arriva a 25ms.

I tempi misurati sono da quando l'elaborazione entra nel FC (L 32000 , T PAW800) a quando esce ( L 0 , T PAW800).

Inserisco una foto del test.

ciao.

Procedo con altri test in serata.

[FattoreDiPotenza]

Tu usando l'accesso a periferia analogica prima della chiamata e a fine chiamata blocco , non hai testato propriamente tempo di elaborazione , ma un "tempo di reazione".

L'accesso in "parola" alla periferia, fà si che il programma subisca una sorta di interruzione (non propriamente un interrupt) ed aggiorni l'immagine di processo solo relativa al tipo di area e dimensione specificato istantaneamente, per poi ritornare all'elaborazione.

Come giustamente hai detto tu , l'analisi siffatta del tempo di reazione è relativa solo alle istruzioni contenute tra la lettura e la scrittura della periferia.

Anzi , per essere più precisi è il tempo a partire da dopo avere fatto l'esecuzione di L 32000 , T PAW800 sino a dopo avere terminato L 32000 , T PAW800 , quindi il reale tempo di esecuzione lo ricavi sottraendo il tempo di esecuzione T PAW800 , circa 160 microsecondi più il tempo di acquisizione dell'oscilloscopio.

In realtà hai aggiunto , sebbene a scopo di prova, un ulteriore "appesantimento" al tempo generale di elaborazione, in quanto il caricamento di dati di periferia ha un tempo di esecuzione notevolmente più lungo del normale di 162 microsecondi per singolo accesso.

Per analizzare invece il tempo di elaborazione , globale dovresti basarti sulle informazioni fornite dal processore nella finestra proprietà o nei dati locali di OB1 cycle scan time.

La differenza con e senza la chiamata alla nuova FC, restituisce grossomodo il peso che avrà nell'elaborazione totale del programma.

A parte questa parentesi , hai raggiunto l'obbiettivo che ti eri prefissato , bravo.

Il linguaggio KOP ha una chiarezza espositiva ed una intuitività magiore rispetto alla lista istruzioni AWL , ma è risaputo che occupa più memoria e rallenta l'elaborazione per via delle istruzioni "nascoste" necessarie alla sua trasposizione grafica , tutta quella serie di NOP che ti trovi dopo la conversione AWL , vengono letti ed elaborati anche se perfettamente inutili allo svolgimanto delle funzioni.

Modificato: 5 novembre 2008 da FattoreDiPotenza

[FattoreDiPotenza]

Tu usando l'accesso a periferia analogica prima della chiamata e a fine chiamata blocco , non hai testato propriamente tempo di elaborazione , ma un "tempo di reazione".

L'accesso in "parola" alla periferia, fà si che il programma subisca una sorta di interruzione (non propriamente un interrupt) ed aggiorni l'immagine di processo solo relativa al tipo di area e dimensione specificato istantaneamente, per poi ritornare all'elaborazione.

Come giustamente hai detto tu , l'analisi siffatta del tempo di reazione è relativa solo alle istruzioni contenute tra la lettura e la scrittura della periferia.

Anzi , per essere più precisi è il tempo a partire da dopo avere fatto l'esecuzione di L 32000 , T PAW800 sino a dopo avere terminato L 32000 , T PAW800 , quindi il reale tempo di esecuzione lo ricavi sottraendo il tempo di esecuzione T PAW800 , circa 160 microsecondi più il tempo di acquisizione dell'oscilloscopio.

In realtà hai aggiunto , sebbene a scopo di prova, un ulteriore "appesantimento" al tempo generale di elaborazione, in quanto il caricamento di dati di periferia ha un tempo di esecuzione notevolmente più lungo del normale di 162 microsecondi per singolo accesso.

Per analizzare invece il tempo di elaborazione , globale dovresti basarti sulle informazioni fornite dal processore nella finestra proprietà o nei dati locali di OB1 cycle scan time.

La differenza con e senza la chiamata alla nuova FC, restituisce grossomodo il peso che avrà nell'elaborazione totale del programma.

A parte questa parentesi , hai raggiunto l'obbiettivo che ti eri prefissato , bravo.

Il linguaggio KOP ha una chiarezza espositiva ed una intuitività magiore rispetto alla lista istruzioni AWL , ma è risaputo che occupa più memoria e rallenta l'elaborazione per via delle istruzioni "nascoste" necessarie alla sua trasposizione grafica , tutta quella serie di NOP che ti trovi dopo la conversione AWL , vengono letti ed elaborati anche se perfettamente inutili allo svolgimanto delle funzioni.

Modificato: 5 novembre 2008 da FattoreDiPotenza

[Livio Orsini]

Tu usando l'accesso a periferia analogica prima della chiamata e a fine chiamata blocco , non hai testato propriamente tempo di elaborazione , ma un "tempo di reazione".

Non è del tutto corretta neanche questa affermazione.

I tempi che riporti mi sembrano un tantino lunghi, anche considerando il caso pessimo. Ma anche prendendo quel dato siamo nell'ordine di un errore di circa 1%, errore che è più che accettabile per lo scopo prefissato. Lo sarebbe anche per misurare il tempo di esecuzione di una funzione di regolazione. Sarebbe, più o meno, il tempo equivalente alla variabilità di elaborazione della funzione.

Certo che questo metodo non è adatto, per esempio, a misurare, se non in modo molto indicativo, il ritardo di rispossta ad un interrupts.

Però i PLC non sono dispositivi previsti per lavorare con temporizzazioni estremamente precise. Quando si hanno di queste necessità bisogna ricorrere ad Hw dedicato.

Io non mi fido molto delle info relative allo scan time, prima di tutto perchè non è chiaramente indicato come sono ottenute, secondariamente perchè ritengo siano influenzate dai tempi di comunicazione PLC-PC.

Però questa è una mia convinzione personale.

Modificato: 5 novembre 2008 da Livio Orsini

[Livio Orsini]

Tu usando l'accesso a periferia analogica prima della chiamata e a fine chiamata blocco , non hai testato propriamente tempo di elaborazione , ma un "tempo di reazione".

Non è del tutto corretta neanche questa affermazione.

I tempi che riporti mi sembrano un tantino lunghi, anche considerando il caso pessimo. Ma anche prendendo quel dato siamo nell'ordine di un errore di circa 1%, errore che è più che accettabile per lo scopo prefissato. Lo sarebbe anche per misurare il tempo di esecuzione di una funzione di regolazione. Sarebbe, più o meno, il tempo equivalente alla variabilità di elaborazione della funzione.

Certo che questo metodo non è adatto, per esempio, a misurare, se non in modo molto indicativo, il ritardo di rispossta ad un interrupts.

Però i PLC non sono dispositivi previsti per lavorare con temporizzazioni estremamente precise. Quando si hanno di queste necessità bisogna ricorrere ad Hw dedicato.

Io non mi fido molto delle info relative allo scan time, prima di tutto perchè non è chiaramente indicato come sono ottenute, secondariamente perchè ritengo siano influenzate dai tempi di comunicazione PLC-PC.

Però questa è una mia convinzione personale.

Modificato: 5 novembre 2008 da Livio Orsini

[FattoreDiPotenza]

Io non mi fido molto delle info relative allo scan time, prima di tutto perchè non è chiaramente indicato come sono ottenute, secondariamente perchè ritengo siano influenzate dai tempi di comunicazione PLC-PC.

Si è sempre bene non fidarsi.

Comunque si ottiene , o meglio la ottiene il PLC misurando il tempo intercorso tra l'avvio di ZPK e la successiva rielaborazione a fine processi.

Per i processi si intendono tutti , quindi aggiornamento IPI IPU ed esecuzione di diagnosi e sovrascrittura blocchi (se presente).

Non è influenzata dalla velocità di comunicazione PG->AG in quanto è un informazione inviata dal processore su interrogazione singola , ovviamente arriva con un lasso temporale dipendente dalla comunicazione seriale ma è realmente ciò che "accadde".

Meglio a questo punto precisare una cosa , la comunicazione con un dispositivo di programmazione introduce SI' un ritardo della elaborazione ma esso è già nel "computo" eseguito dalla lettura di ZPK.

Come caparbiamente dico , il valore del tempo di elaborazione di una porzione di programma non è molto indicativo al fine della determinazione o meglio dell'influenza su tutto il resto del programma completo di tutte le funzioni che deve svolgere la CPU.

Per questo mi ostino a definirlo un test del tempo di reazione e non del tempo di elaborazione.

Modificato: 5 novembre 2008 da FattoreDiPotenza

[FattoreDiPotenza]

Io non mi fido molto delle info relative allo scan time, prima di tutto perchè non è chiaramente indicato come sono ottenute, secondariamente perchè ritengo siano influenzate dai tempi di comunicazione PLC-PC.

Si è sempre bene non fidarsi.

Comunque si ottiene , o meglio la ottiene il PLC misurando il tempo intercorso tra l'avvio di ZPK e la successiva rielaborazione a fine processi.

Per i processi si intendono tutti , quindi aggiornamento IPI IPU ed esecuzione di diagnosi e sovrascrittura blocchi (se presente).

Non è influenzata dalla velocità di comunicazione PG->AG in quanto è un informazione inviata dal processore su interrogazione singola , ovviamente arriva con un lasso temporale dipendente dalla comunicazione seriale ma è realmente ciò che "accadde".

Meglio a questo punto precisare una cosa , la comunicazione con un dispositivo di programmazione introduce SI' un ritardo della elaborazione ma esso è già nel "computo" eseguito dalla lettura di ZPK.

Come caparbiamente dico , il valore del tempo di elaborazione di una porzione di programma non è molto indicativo al fine della determinazione o meglio dell'influenza su tutto il resto del programma completo di tutte le funzioni che deve svolgere la CPU.

Per questo mi ostino a definirlo un test del tempo di reazione e non del tempo di elaborazione.

Modificato: 5 novembre 2008 da FattoreDiPotenza

[Livio Orsini]

Per questo mi ostino a definirlo un test del tempo di reazione e non del tempo di elaborazione.

E' una questione di semantica. Una volta chiarita la semantica puoi definirlo come preferisci, entro certi, limiti.

Anch'io sono un poco caparbio ed ostinato e ripeto che la misura che ho descritto serve per determinare il tempo di elaborazione di una singola funzione. Anche se questo tempo può essere o meno determinante sul totale del tempo di elaborazione. Solitamente serve per pettere a punto una funzione critica.

Ti ringrazio per la chiara ed esaustiva spiegazione sul computo dello scan time del PLC, ha aggiunto informazioni che non conoscevo.

[Livio Orsini]

Per questo mi ostino a definirlo un test del tempo di reazione e non del tempo di elaborazione.

E' una questione di semantica. Una volta chiarita la semantica puoi definirlo come preferisci, entro certi, limiti.

Anch'io sono un poco caparbio ed ostinato e ripeto che la misura che ho descritto serve per determinare il tempo di elaborazione di una singola funzione. Anche se questo tempo può essere o meno determinante sul totale del tempo di elaborazione. Solitamente serve per pettere a punto una funzione critica.

Ti ringrazio per la chiara ed esaustiva spiegazione sul computo dello scan time del PLC, ha aggiunto informazioni che non conoscevo.

[Michele]

Ciao a tutti,

Il Test mi ha permesso di ottimizzare l'FC creato, ieri sera ne ho controllati altri già fatti, anche se ho utilizzato una cpu di Test senza OP, ethernet ecc. comunque il problema risolto ieri era casualmente L'UNICA FC che ho creato in KOP perchè ci sono un sacco di confronti e conversioni ITD DTR .

Concludo dicendo che pensavo che l'oscilloscopio non mi sarebbe più servito invece.... ottimo metodo, veloce e risolutivo, anche perche a volte si rischia di prendere una 318 per supportare delle funzioni fatte "male".

Dal mio punto di vista non si avranno dei riferimenti di tempo "ultra" precisi, però la misurazione fatta è riferimento oltre al tempo ciclo estratto da ob1.

Grazie a tutti e grazie al Forum

Michele (Trento)

[Michele]

Ciao a tutti,

Il Test mi ha permesso di ottimizzare l'FC creato, ieri sera ne ho controllati altri già fatti, anche se ho utilizzato una cpu di Test senza OP, ethernet ecc. comunque il problema risolto ieri era casualmente L'UNICA FC che ho creato in KOP perchè ci sono un sacco di confronti e conversioni ITD DTR .

Concludo dicendo che pensavo che l'oscilloscopio non mi sarebbe più servito invece.... ottimo metodo, veloce e risolutivo, anche perche a volte si rischia di prendere una 318 per supportare delle funzioni fatte "male".

Dal mio punto di vista non si avranno dei riferimenti di tempo "ultra" precisi, però la misurazione fatta è riferimento oltre al tempo ciclo estratto da ob1.

Grazie a tutti e grazie al Forum

Michele (Trento)

[TRC]

Non so quanto possa essere preciso come test, io quando devo ottimizzare una FC o un FB li metto in un programma vuoto con solo quella FC o FB, li provo utilizzando tutte le funzioni contenute all'interno e poi guardo il tempo di ciclo massimo e lo attribuisco alla funzione come commento, poi non so la precisione, pero' a spanne vedo se facendo le cose in un modo piuttosto che in un altro riesco a ridurre il tempo massimo di ciclo. Ciao

[TRC]

Non so quanto possa essere preciso come test, io quando devo ottimizzare una FC o un FB li metto in un programma vuoto con solo quella FC o FB, li provo utilizzando tutte le funzioni contenute all'interno e poi guardo il tempo di ciclo massimo e lo attribuisco alla funzione come commento, poi non so la precisione, pero' a spanne vedo se facendo le cose in un modo piuttosto che in un altro riesco a ridurre il tempo massimo di ciclo. Ciao