Moka7 molte variabili

[t0nin0]

Buonasera a tutti, ad oggi usando Moka7 (grazie Davide Nardella) leggo delle variabili da un plc S7.

 

Per leggere un'area di memoria che sia un bit o una word impiego dai 6 ai 180 ms.

 

Adesso si è reso necessario leggere 300 variabili che variano ogni 20 ms  per poi doverli elaborare.

 

Ma con i tempi misurati dai 6 ai 180 ms non sono nei tempi.

 

Sapreste consigliarmi se c'è qualche modalità per poter leggere una così grande mole di variabili in tempi brevi?

 

Avevo pensato pure di far storare i dati lato pannello bordo macchina per poterli leggere di li, o via ODBC (però aimè non sono un programmatore di PLC).

 

Qual'è la strada migliore da usare?

Grazie

[dan64100]

Fai memorizzare tutte le variabili in una DB e leggi l'intero blocco.

Poi estrai le variabili singolarmente usando la classe helper S7.

Questo è il metodo più veloce.

 

Java non è un fulmine di guerra, poi non conosco la tua architettura. Con Snap7 versione binaria, ogni telegramma viene letto in circa 5 ms (in media di 240 byte per la serie 300) dalla porta integrata PN.

Questo tempo si raddoppia se ti connetti ad una CP 343.

[t0nin0]

Grazie Davide, della tua preziosa risposta.

Stamani ho effettuato la prova come da tuo consiglio e volevo condividere il risultato.

 

Su SIMATIC 400 CPU 414-3

 

La connessione è avvenuta in 45 ms, la lettura di una intera DB in 28 ms, il ciclo di stampa dei singoli bit (304 corrispondenti ai primi 38 byte) è avvenuta in 69ms

 

Grazie ancora

 

 

 

[dan64100]

Non so cosa intendi per "stampa" ma è un operazione onerosa se impiega 69 ms.

A questo punto puoi realizzare un'architettura multithread : un thread gestisce la comunicazione a priorità più alta e mette i dati in un buffer/coda, e un altro thread, a priorità bassa, si occupa della visualizzazione.

[t0nin0]

Si si infatti avevo pensato già a quello sin dall'inizio.

 

Ma secondo la tua grande esperienza, qual'è la strada più corretta per prelevare tanti valori da un PLC?

A tuo parere sarebbe meglio usare una gestione tipo database su un pannello collegato a PLC  dove vengono storate le varie variabili?

 

https://support.industry.siemens.com/cs/document/58112130/what-are-the-functional-differences-between-the-different-log-storage-locations-in-the-simatic-comfort-panels-and-runtime-advanced?dti=0&lc=en-WW

 

Grazie

[dan64100]

La strada migliore è quella che soddisfa le specifiche, possibilmente in modo "sostenibile" cioè senza troppi giri strani.

 

Quote

Adesso si è reso necessario leggere 300 variabili che variano ogni 20 ms  per poi doverli elaborare.

 

Che tempi ha il Log di WinCC ? Considera che prima di creare un item di Log immagino che debba avere tutti i valori collezionati. Secondo me è difficile che scendi sotto il secondo considerato anche l'alto numero delle variabili.

Anche qui a pag.31 si parla di minimo 1 sec.

http://www.luceforum.com/fm/upload/Save09/03_WinCCflexible_traceabillity_it.pdf

E' un documento del 2009 ma non credo che sia cambiato molto nel frattempo.

 

Che tipo di elaborazione devi fare e come pensi di farla, vai ad accedere al file RDB dall'esterno o ti crei degli script in WinCC ? Nel primo caso occhio ai conflitti di accesso contemporaneo.

Conosci il formato file RDB (quello più performante) o sei costretto ad usare il CSV ?

 

[t0nin0]

Devo parlare con il programmatore di Plc per sapere che tempi ha il log di wincc. Io preleva solo i dati per metterli su un database per effettuare uno studio su di essi. 

 

Infatti avevo  pensato ad usare l.'ODBC per avere già i dati già disponibili.  Io non dovrò rappresentare i dati ogni 20 ms.  Ma non devo avere buchi per poter rappresentare e analizzare l'intero periodo.

[batta]

Ma si deve fare un datalogger o un oscilloscopio?

Registrare 300 variabili ogni 20 ms (15000 dati ogni secondo!!!), oltre ai problemi legati alla velocità di acquisizione e archiviazione, significa anche accumulare, in poco tempo, una mole di dati enorme. Quanto è lungo il periodo da analizzare?

Sinceramente, mi sembra un lavoro piuttosto strano da fare con un PLC e un PC.

Se il periodo non è eccessivamente lungo, penso sia meglio registrare i dati in DB nel PLC, e andare poi a leggerli con tutta calma.

Un minuto di registrazioni di variabili di tipo INT ha bisogno di 300*50*60*2 = 1'800'000 byte. Occhio quindi alla memoria del PLC.

[t0nin0]

La necessità è quella di fare un data logger che registra le 300 variabili. Come detto nel post precedente non vi è la necessità di avere in tempo reale il cambiamento del valore della singola variabile, ma anche a distanza di secondi. Pensavo di avere una struttura del genere: 

Il PLC colletta i dati a multipli di 300 variabili in una Db  in maniera  ciclica (arrivato al n-esimo campione la Db si ricomincia da capo). Dall'esterno un server effettua un polling: o si legge l'intera Db o se si sfrutta la memoria del pannello tramite ODBC si legge il database. 

 

Sto ipotizzando qualcosa di impossibile? 

[t0nin0]

Avete qualche consiglio? 

[dan64100]

Quote

Infatti avevo  pensato ad usare l.'ODBC per avere già i dati già disponibili.  Io non dovrò rappresentare i dati ogni 20 ms.  Ma non devo avere buchi per poter rappresentare e analizzare l'intero periodo.

 

Tu puoi rappresentarli anche dopo un anno, rimane il problema che, se non vuoi buchi nell'acquisizione devi campionarli velocemente.

 

Dovessi farlo per me utilizzerei un double buffer lato PLC (quindi due DB) e due thread lato PC :

 

Il PLC colleziona i dati a multipli di 300 variabili nella DB "A", quando è piena alza il flag "A" e passa ad acquisire i dati nella DB "B". Quando anche quest'ultima è piena alza il flag B, ricomincia con la DB "A" e così via.

 

Il PC nel thread di acquisizione effettua solo il polling dei flags, quando ne trova uno alto scarica la DB relativa su disco ed abbassa il flag.

In questo modo il tuo tempo di trasferimento dati va in ombra al campionamento del PLC, in altre parole, per trasferire una DB hai a disposizione il tempo che il PLC impiega per riempire l'altra.

 

Per essere veloce, salverei i dati in formato binario senza alcuna preelaborazione e come nome del file utilizzerei la data e l'ora corrente formattata YYYYMMDDHHNNSSZZZ.

 

Nel secondo thread leggi i files da disco che sono univoci e già ordinati per timestamp, li elabori e poi li cancelli. In questo modo sfrutti come coda il filing system del sistema operativo. Se addirittura fai due programmi separati puoi fare manutenzione sul secondo (quello di postelaborazione) senza fermare l'acquisizione dei campioni e senza perdere i dati intermedi.

 

Ovviamente non esiste la birra gratis  : anche il PC, alla lunga, potrebbe riempirsi se il tempo di postelaborazione e superiore a quello di produzione dei files.

Fatti due conti per dimensionare correttamente le DB e i time rate dei threads.

 

Io per motivi religiosi non uso Python, VB e ODBC, per cui altre soluzioni non riesco a valutarle.

 

[t0nin0]

Grazie mille per il consiglio.

Vi terrò aggiornati