Tempo ciclo "speso" passaggio dati a FB con DB di istanza (PLC ET200SP //CPU 1512SP-1 PN)

[Roby_360]

Ciao a tutti e grazie per il tempo che potrete dedicarmi!

Sto sviluppando un progetto e voglio cercare di organizzarlo nel miglio modo per rispamiare piu tempo ciclo possibile.

Ho cercato sul portale Siemens ma non ho trovato nel dettaglio quello che cerco, spero riusciate ad aiutarmi.

Ho creato un FB con la sua DB di istanza al qiuale passo dei dati di ingresso (Word, INT, Bool) e leggo dei dati in uscita (INT, Bool) che si occupa della gestione di un sensore.

Questo FB è richiamato in OB1, vorei saper quanto tempo impiega a fare la copia dei dati in ingresso e in uscita rispetto a una copia in AWL o SCL.

secondo voi è meglio copiare i dati all'intreno dell'FB in AWL con l'istruzione L a1 e T b1 oppure SCL con b1 := a1; o passare i dati in ingresso e uscità?

Se avete dei Link a qualche manuale ve ne sarò grato! 

Grazie

 

 

[drn5]

Ciao, la domanda è teorica o pratica?

La copia fatta in un modo o nell'altro è cosi pesante da impattare sul tempo ciclo ?

Se non impatta sul tempo ciclo la metterei dove è logico metterla (nel FB se è logico metterla li) e per il linguaggio non vedo la differenza (quello più elegante!)

[Roby_360]

Ciao e Grazie per la risposta.

La domanda è pratica, in quanto, di queste "scatolette" comincio ad averne tante, e vorrei ottimizzare il codice. Crescendo il SW, non vorrei avere problemi di tempo ciclo, cosa avuta in passato su una linea con 13 assi, nonostate usassi una 1515T.

Se ad esempio, passando un dato INT in ingresso all'FB e questa copia impiega 10 volte di più rispetto a una copia in AWL (con instruzione L; T), per la sola copia dei dati ho aumentato di 10 volte il tempo ciclo.

 

Grazie ancora.

 

[Marco Mondin]

Se devi passare tanti dati conviene usare le strutture per raggrupparli in modo che siano allineati, magari disabilitando l'ottimizzazione dei DB che crea solo casini agli allineamenti! Poi usi il BLKMOV che credo poi alla fine chiami il memcpy dell'OS che sta sotto.

Come fai a mettere in crisi un 1515T con 13 assi?????????
Ho anche notato che nel TIA Portal c'è un "REFERENCE TO", in questo caso non ho approfondito, ma potrebbe evitare la copia di dati se è come quello dello standard IEC 61131-3 V3.

Modificato: 4 settembre 2020 da Marco Mondin

[batta]

6 ore fa, Marco Mondin ha scritto:

Se devi passare tanti dati conviene usare le strutture per raggrupparli in modo che siano allineati, magari disabilitando l'ottimizzazione dei DB che crea solo casini agli allineamenti! Poi usi il BLKMOV

No, assolutamente. Lavorare con dati "non ottimizzati" allunga i tempi fino a 5-6 volte.

Il modo più efficiente per passare ad una funzione tanti dati, è passarli come INOUT. In questo modo, non vengono copiati tutti i dati nelle variabili della funzione, ma viene creato un puntatore che, se i dati sono ottimizzati, permette un accesso veloce alle variabili.

 

6 ore fa, Marco Mondin ha scritto:

Come fai a mettere in crisi un 1515T con 13 assi?

Dipende da cosa si chiede di fare a questi assi, e a come si vuol far ciclare l'OB Servo.

La 1515 non è molto performante, ha più memoria di una 1511 ma, a livello velocistico, è uguale. Un buon salto di prestazioni si ha col passaggio alla 1516.

[Marco Mondin]

@batta, Quello che ho notato è che usando i DB ottimizzati (tuttavia uso SIEMENS con il contagocce in quanto se posso evito) si occupa meno memoria, ma si rompono tutti gli allineamenti standard delle strutture. Questo rende difficilissima e molto dispendiosa a livello di risorse di calcolo la ricostruzione dei dati quando la leggo con un gateway IoT il quale lavora di solito con allineamenti standard dei dati. Ho consigliato di disabilitarlo in quanto ho il dubbio che non siano nemmeno più tutti contigui in memoria tenendolo abilitato e questo creerebbe grossi problemi a un BLKMOV se facesse solo da wrapping a un memcpy(...). Non capisco come un ottimizzazione dati possa accelerare un processo, davvero mi sfugge. 
 

Ci sono dispositivi in commercio che costano una terza parte di un 1515 e permettono di interpolare 64 assi facendo cose anche mooooolto complesse. La mia battuta era un po' sarcastica e riferita a questo. Oggi trovo che con HW moderno per mettere in crisi un sistema con 13 assi se le cose sono fatte bene si debba scrivere il mondo come applicativo. Tutto lì!

Beh... Usarli come INOUT certo non fa copie, ma a livello di gestione della privacy dei dati siamo messi maluccio! Lo saremmo comunque anche con puntatori e "REFERENCE TO" che se è implementato secondo IEC 61131-3 V3 (Tuttavia i BIG non rispettano quasi mai questa IEC) è un modo di mascherare un puntatore.
Dipende sempre da cosa deve fare di quei dati... Quindi in questo caso aria fritta potrebbero essere tutte le mie divagazioni...


 

Modificato: 5 settembre 2020 da Marco Mondin

[batta]

9 ore fa, Marco Mondin ha scritto:

Questo rende difficilissima e molto dispendiosa a livello di risorse di calcolo la ricostruzione dei dati quando la leggo con un gateway IoT

Questo è un altro discorso, ma la CPU lavora molto più velocemente con dati ottimizzati.
La faccenda che con dati non ottimizzati il tempo si allunghi di 5-6 volte mi era stata detta ancora molto tempo fa da un tecnico Siemens, e l'ho sperimentata di persona, calcolando il tempo di esecuzione di una funzione con dati ottimizzati e non.
Perché con i dati ottimizzati sia più veloce, non lo so, ma ti garantisco che è così.

 

9 ore fa, Marco Mondin ha scritto:

Usarli come INOUT certo non fa copie, ma a livello di gestione della privacy dei dati siamo messi maluccio!

???

 

9 ore fa, Marco Mondin ha scritto:

Ci sono dispositivi in commercio che costano una terza parte di un 1515 e permettono di interpolare 64 assi facendo cose anche mooooolto complesse.

Sì, certo, ma magari non fanno altre cose.
Qui stiamo parlando di un PLC che integra anche funzioni motion, non di un controllo assi puro.

E poter gestire funzioni motion, anche di un certo livello, tutto nello stesso progetto, è decisamente comodo.
Inoltre, la gestione è anche semplice.
Per esempio, quando qualche tempo fa decisi di guardare come si usava l'oggetto "kinematics", partendo completamente da zero, munito solo di manuale in linea e del simulatore integrato nel TIA, in 2-3 ore realizzai un portale 3D con tanto di raccordi tra le varie curve.

 

[Roby_360]

Intanto Grazie per le risposte e il vostro tempo!!!

 

Il 4/9/2020 alle 14:00 , Marco Mondin ha scritto:

Se devi passare tanti dati conviene usare le strutture per raggrupparli in modo che siano allineati, magari disabilitando l'ottimizzazione dei DB che crea solo casini agli allineamenti! Poi usi il BLKMOV che credo poi alla fine chiami il memcpy dell'OS che sta sotto.

Come fai a mettere in crisi un 1515T con 13 assi?????????
Ho anche notato che nel TIA Portal c'è un "REFERENCE TO", in questo caso non ho approfondito, ma potrebbe evitare la copia di dati se è come quello dello standard IEC 61131-3 V3.

la mettevo in crisi a causa della velocità di linea molto elevata, purtoppo dovevo muovere gli assi in un piano cartesiano e avevo uinfinità di sensori da valutare, pinze, posizioni ecc.

 

Il 4/9/2020 alle 20:31 , batta ha scritto:

No, assolutamente. Lavorare con dati "non ottimizzati" allunga i tempi fino a 5-6 volte.

Il modo più efficiente per passare ad una funzione tanti dati, è passarli come INOUT. In questo modo, non vengono copiati tutti i dati nelle variabili della funzione, ma viene creato un puntatore che, se i dati sono ottimizzati, permette un accesso veloce alle variabili.

 

Dipende da cosa si chiede di fare a questi assi, e a come si vuol far ciclare l'OB Servo.

La 1515 non è molto performante, ha più memoria di una 1511 ma, a livello velocistico, è uguale. Un buon salto di prestazioni si ha col passaggio alla 1516.

Anche io uso DB ottimizzate quando posso, in questo caso la DB di istanza del mio FB è ottimizzata, ma le DB da dove prendo i dati (da mettere in ingresso al'lFB non possono essere tutte ottimizzate), tra laltro i dati che mi servono in questo FB arrivano tutti da strutture differenti. Per fare un blokmove dovrei fare una struttura che raccoglie quetsi dati  apoggiarli ad una DB e poi copiargli i dati dentro. a questo punto avrei un doppio passaggio.

 

VI chiedo gentilemnte, se avevte in giro qualche manuale che riposta i tempi delle copie per i singoli formati...

 

Grazie ancora.

 

[acquaman]

Io quando uso gli Fb, all'esterno uso direttamente dati della DB di istanza, cosi non ho dati doppi e non devo fare spostamenti.

[Roby_360]

Il 7/9/2020 alle 11:07 , acquaman ha scritto:

Io quando uso gli Fb, all'esterno uso direttamente dati della DB di istanza, cosi non ho dati doppi e non devo fare spostamenti.

 

Ciao e grazie per la tua risposta.

se sono dati che nascono dentro FB come statici, allora li uso negli altri blocchi tramite DB di istanza.

Nel mio caso devo fare un'altra cosa, ho bisogno dei dati di altre DB dentro il mio FB, e volevo sapere se la copa di questo dato es DB1DBWxx è meglio farla all'interno dell'FB oppure se passarglielo come dato Input dell'FB.

l'FB in questione verrà richiamato molte, e ad ogni richiamo verrà creata un'istanza diversa.

So che la copia di un dato rispetto al passaggio dello steso dato in ingresso all'FB mi costa meno in tempo ciclo. Vorrei conoscere questi tempi.

Grazie

[acquaman]

Io lo metterei come IN o IN/OUT, ma non ho mai avuto bisogno di controllare i tempi di esecuzione.

Modificato: 8 settembre 2020 da acquaman

[batta]

Come già detto, per l'accesso più veloce: dati ottimizzati e passare struttura come IN/OUT.
Se, come IN/OUT, vengono passati dati semplici (word, dword, ecc.), viene comunque creata una copia del dato. Se si passano dati complessi (array o strutture), viene creato un puntatore. Da quanto dicono i tecnici Siemens, col puntatore l'accesso è più veloce, probabilmente proprio perché non si perde tempo a copiare il dato, ma si punta direttamente al dato.

[Roby_360]

Il 7/9/2020 alle 11:07 , acquaman ha scritto:

Io quando uso gli Fb, all'esterno uso direttamente dati della DB di istanza, cosi non ho dati doppi e non devo fare spostamenti.

 

Grazie a tutti e buon proseguimento.