spostamento dati

[Crystal1995]

Buongiorno,

avrei bisogno di una soluzione ovviamente se siemens ne permette l'utilizzo.

ho una DB contenente una seria di bit, devo creare un FC che scorra tutti questi bit controllando che tutti siano a FALSE.

Ho provato a farlo utilizzando strutture e tipi di dato ma mi sono accorto che il tempo che il PLC impiega ad eseguire questa operazione è molto alto. Con i vecchi puntatori invece, eseguendo il controllo 32 bit alla volta il tempo per eseguire l'operazione è molto ma molto più ridotto.

la domanda è: esiste un metodo per controllare 32 bit di una db alla volta composta da tutti bool senza utilizzare i vecchi puntatori?

 

Cordiali saluti

[drn5]

Se non è ottimizzato puoi leggerli come una dword=0

[batta]

Di quanti bit si tratta? Sono tutti in una unica struttura?

Se sono in una sola struttura puoi usare l'istruzione Gather (o Gather_blk) per trasferire tutti i bit in un array di Byte, Word, DWord o LWord.
Se sono suddivisi in strutture diverse, puoi fare la stessa cosa usando Serialize.
Attenzione che se ci sono strutture con dimensione che non è multiplo di 8 bit (o di 16 bit? Mi viene il dubbio), verranno aggiunti bit di riempimento. Ma questo, più che un problema, è una comodità. Si tratta solo di tenerne conto nel dimensionare l'area dati che dovrà contenere tutti i bit.
Con Serialize però, l'array di uscita può essere solo di byte (o char). Del resto, questa istruzione è nata per uno scopo diverso.

[Crystal1995]

Utilizzando serialize in ogni caso il PLC prende i bit uno ad uno e li sposta in una sua struttura interna, questo porta via comunque tempo.

Con i puntatori questa cosa non succede.

Ti faccio un altro esempio:

se devo azzerare una struttura le soluzioni sono due: creare una struttura vuota e trasferire la struttura vuota in quella da azzerare oppure azzerare tramite i puntatori.

Con il secondo metodo, è più complicato il software ma a livello di tempi ci mette meno della metà.

 

[batta]

2 ore fa, Crystal1995 ha scritto:

Con il secondo metodo, è più complicato il software ma a livello di tempi ci mette meno della metà.

Oggi si è orientati verso una programmazione il più possibile svincolata dagli indirizzi assoluti e, di conseguenza, ad un uso dei puntatori relegato oramai a pochissimi casi.
Poter modificare una struttura, inserire o togliere variabili, senza dover "rimettere a posto" gli indirizzi, è impagabile.
Pesonalmente sto adottando tutte le strategie possibili per evitare l'uso dei puntatori. E, devo dire, da almeno due anni (o forse più) non ho fatto nulla di nuovo con i puntatori.
Per quanto riguarda la velocità, inoltre, non dimentichiamo che per usare i puntatori devi appoggiarti a strutture di dati "non ottimizzati", e l'accesso ai dati non ottimizzati richiede un tempo fino a sei volte superiore rispetto all'accesso ai dati ottimizzati.
L'istruzione Serialize so che esiste ma non mi è mai capitato di utilizzarla, e non so quanto pesante sia in termini di tempo di esecuzione. C'è da dire che si tratta di un'istruzione nata fondamentelmente per creare pacchetti di dati da trasferire ad altri sistemi o ad altri plc che, tramite "Deserilize", ricreano le strutture originali.
Faccio invece largo uso delle istruzioni Gather e Scatter.
Per esempio, la mia gestione degli allarmi funziona più o meno così:
- una struttura (o più strutture) con la dichiarazione dei singoli allarmi a bit, con tanto di nome che aiuta non poco nella programmazione
- tramite Gather (o Gather_blk) trasferisco queste strutture di bit in un array di word

- questo array di word, preso così com'è, senza swap di byte od altro, si usa direttamente per gli allarmi su HMI Siemens

- lo stesso array viene dato in pasto ad una funzione (che va sempre bene, indipendentemente dalla dimensione dell'array) che rileva la presenza di allarmi e l'entrata di un nuovo allarme.

- inoltre, la struttura (o le strutture) dei bit di allarme è dichiarata come "tipo di dati", e lo stesso "tipo di dati" è usato anche per creare una struttura, con tutti i bit a zero, che può servire per un reset globale degli allarmi con una sola riga di istruzioni.

Il tutto lavorando con DB ottimizzati.

 

[Crystal1995]

Che i puntatori siano ormai obsoleti sono d'accordo ma purtroppo quando si hanno problemi di tempo ciclo della CPU, pur usando le DB non ottimizzate e i puntatori, il tempo è nettamente sotto rispetto all'utilizzo delle struttute (ho testato il tutto). 

Che poi sia molto più comodo, veloce e facile usare le strutture su questo non c'è dubbio.

Con serialize non ho provato ma, immagino che per copiare dei bit e trasformarli in una Dword faccia gli stessi passaggi che potrei fare io tramite software quindi, occuperà sicuramente del tempo.

 

[batta]

2 ore fa, Crystal1995 ha scritto:

pur usando le DB non ottimizzate e i puntatori, il tempo è nettamente sotto rispetto all'utilizzo delle struttute (ho testato il tutto). 

Al momento non dispongo di una CPU, ed ho effettuato il test con il simulatore. Il risultato, comunque, dovrebbe essere attendibile.

 

Spostamento di 8192 bit in un array di 512 word:

- con Gather_blk, tempo esecuzione 7..10 microsecondi
- con puntatori (lavorando su Word), tempo di esecuzione 90..100 microsecondi

- con puntatori (lavorando su DWord), tempo di esecuzione 50..55 microsecondi

[acquaman]

Con le cpu nuove così veloci, il fattore tempo non lo trovo così fondamentale, secondo me dobbiamo semplicemente abbandonare la vecchia mentalità dell'indirizzo sempre più a favore dell'utilizzo del simbolico.

[leleviola]

è ovvio che ciò che si avvicina di più al linguaggio macchina (assoluto) sia più veloce di ciò che viene interpretato (simbolico), è alttrettanto ovvio che con CPU più veloci si riesce ad ovviare a tali problematiche, bisogna vedere dove si vuole arrivare, comunque con le nuove serie Siemens anche questa situazione dovrebbe essere superata, penso...

[batta]

4 ore fa, leleviola ha scritto:

è ovvio che ciò che si avvicina di più al linguaggio macchina (assoluto) sia più veloce di ciò che viene interpretato (simbolico)

Dai test che ho fatto, non è così ovvio, anzi.
La stessa operazione fatta con puntatori ed indirizzi assoluti richiede un tempo 10 volte maggiore.

[Crystal1995]

 

14 ore fa, batta ha scritto:

Dai test che ho fatto, non è così ovvio, anzi.
La stessa operazione fatta con puntatori ed indirizzi assoluti richiede un tempo 10 volte maggiore.

 

Non capisco perchè ma io trovo un risultato differente 🤔. Sarà la CPU 1515?

 

19 ore fa, acquaman ha scritto:

Con le cpu nuove così veloci, il fattore tempo non lo trovo così fondamentale

Io lavoro per un'azienda che produce macchine, queste macchina hanno tutte la stessa base software ma cambia solamente il ciclo stazioni. 

Capisci che sa già la base senza nessun ciclo stazione mi porta via 8ms di tempo ciclo della CPU questo potrebbe diventare un problema quando è necessario utilizzare per esempio assi ecc.

Questa base deve essere il più performante possibile perchè non sappiamo che automazioni dobbiamo realizzare in futuro.

[batta]

Ho condotto qualche altro test.
Diciamo che si dovrebbe chiarire cosa si intende per "lavorare con i puntatori".
Nel test precedente, io ho inteso questo come un loop in AWL con i puntatori.
Ma si potrebbe ricorrere all'istruzione POKE_BLK.
L'istruzione POKE_BLK, sul simulatore, si è rivelata circa 5-6 volte più veloce del GATHER_BLK.

 

Ho provato POKE_BLK su una vecchissima CPU S7-1200 "6ES7 212-1BD30-0XB0" con FW 2.2 (rimasuglio del kit con TIA Portal V10.5).
Su questa CPU la copia di 8192 bit in un array di 512 word impiega circa 30 microsecondi. Diciamo che è circa 20 volte più lenta del test con CPU 1511 su simulatore.

Su questa vecchia CPU non è possibile testare l'istruzione GATHER_BLK, perché non è supportata.

 

Quote

Questa base deve essere il più performante possibile perchè non sappiamo che automazioni dobbiamo realizzare in futuro.

Io sono un "programmatore della vecchia guardia", di quando l'ottimizzazione del codice era un obbligo. Ora le CPU sono molto più performanti (sia in termini di velocità che di memoria) e un po' mi lascio andare. Ma un occhio alla gestione delle risorse ce lo metto sempre. Però se la differenza tra un POKE_BLK, che mi costringe a lavorare con indirizzi assoluti (e quindi non fai nemmeno il cross reference) e GATHER_BLK è di una manciata di microsecondi, a questo punto ritengo che la comodità di svincolarsi dagli indirizzi assoluti sia prevalente. Inoltre, con il POKE_BLK la copia viene effettuata byte per byte, quindi quando copio una struttura (o un array) di bit in un array di word, il primo bit mi va a finire nel byte di sinistra della word. Cosa che, invece, non succede con GATHER_BLK che, immagino, effettua la copia bit per bit (da cui un tempo di esecuzione superiore).

 

In alcuni casi, una valida alternativa potrebbe essere la "sovrapposizione con AT".
 

[MaxT1978]

Riapro questo vecchio topic per una considerazione.

Io francamente uso parecchio i puntatori, in ambito Siemens con le serie 300, ma anche in ambito non Siemens, come Beckhoff o B&R. Vi chiedo, ******

Vi ringrazio fin d'ora delle vostre opinioni.

 

******

Leggi i messaggi seguenti

 

Modificato: 28 gennaio 2022 da Livio Orsini

[acquaman]

@MaxT1978 A parte che non è un vecchio topic ma ancora vivo, la tua domanda credo meriti una discussione propria, anche per non creare confusione con l'argomento trattato.

Apri una nuova discussione descrivendo meglio il tuo quesito.

[Livio Orsini]

41 minuti fa, acquaman ha scritto:

Apri una nuova discussione descrivendo meglio il tuo quesito

 

Giusto consiglio.

Comunque gli accodamenti ad altre discussioni, anche se l'argomento è simile, sono vietati dal regolamento perchè causa di disguidi e confusione.

[MaxT1978]

On 1/28/2022 at 5:12 PM, Livio Orsini said:

 

Giusto consiglio.

Comunque gli accodamenti ad altre discussioni, anche se l'argomento è simile, sono vietati dal regolamento perchè causa di disguidi e confusione.

Ok!

Ho aperto il seguente topic: Ricerca di un allarme attivo sotto la parte Siemens/1500

Grazie

MaxT1978