comunicazioni s7/opcua e velocità ciclo cpu

[vergalabs]

ciao a tutti

per implementare il salvataggio dati tramite opc ua da plc 300 a un portale esterno ho utilizzato una cpu 1500 già presente su un'impianto come tramite.

Il 1500 comunica con 5 plc 300 tramite comunicazione s7 legge i dati da varie db e il portale ,tramite opc ua, li va a leggere dalla cpu e li storicizza.

Mi sono accorto però che il tempo di ciclo della cpu (1511-1 pn) è 38ms ,non ricordo prima delle modifiche quanto fosse, è possibile che le comunicazione che ho aggiunto abbiano allungato il tempo di ciclo?

 

[drn5]

Beh...varrebbe la pena di rimuovere la lettura delle DB dai 300 per vedere quanto si prende il resto. 38msec possono essere tanti ma anche no. Se non disturbano hanno poca importanza. Al limite se opcua è solo monitoraggio di facciata puoi intervallare le letture dai 300 facendone 1 alla volta per ciclo...

[vergalabs]

grazie drn5, la velocità non impatta se non per una leggera lentezza nell'hmi sull'impianto, era solo una mia curiosità posta a chi magari ci aveva già sbattuto la testa 

[vergalabs]

Ho provato a non richiamare gli fc con all'interno le comunicazioni ma la velocità ciclo non cambia 

[84paolo]

Infatti mi sembrava che non cambiasse nulla. Se tu guardi nell'hardware dovresti trovare di default "Carico del tempo ciclo a causa della comunicazione" 50%. Quindi quei pochi message non ti fanno cambiare nulla. Se ti serve andare più veloce e hai poca comunicazione potresti provare ad abbassare quel valore. Poi non ho neanche capito il fatto che il tempo ciclo a 38ms ti possa impattare sulla lentezza dell'HMI. Se avessi tempo ciclo 500ms e tags da leggere veloce ok, ma così mi pare strano. Hai verificato il tempo di scansione delle tags nell'HMI?

[vergalabs]

grazie Paolo, sono a conoscenza di quella impostazione hardware, il tempo di ciclo non mi crea nessun problema e Nell hmi ci sono tutte variabili a 1 sec. ci sto guardando perché gli operatori hanno notato un rallentamento Dell hmi e quando mi connetto al plc tia 14 impiega circa 20 30 sec. a connettersi e stessa cosa. per caricare delle modifiche, a questo punto però ho idea che sia un problema di rete. 

[ghismo1974]

@vergalabs ciao. una domanda : il 1500 comunica con tutti i 300 in profinet ? io devo fare la stessa cosa ma 2 cpu_300PN e 2 cpu_300dp. come potrei fare ? grazie.

 

[vergalabs]

ghismo, le mie sono tutte in profinet, forse per i tuo caso sarebbe utili un convertitore profibus/profinet/iodevice tipo anybus o altre merche 

[ghismo1974]

4 ore fa, vergalabs ha scritto:

ghismo, le mie sono tutte in profinet, forse per i tuo caso sarebbe utili un convertitore profibus/profinet/iodevice tipo anybus o altre merche 

ottimo, grazie.

[vergalabs]

4 ore fa, Yiogo ha scritto:

se il ciclo del plc è attestato sui 40 ms ed il ciclo di scansione dello hmi è di 1.000 ms fissi la discussione cade

riguarda a quanto dicono gli "operatori" potresti scrivere su un forum di psicanalisti

si si potremmo aprire un forum di psicanalisi approfondita sulle castronerie che alcuni operatori si inventano.

comunque grazie a tutti per il supporto

 

[vergalabs]

riapro la discussione perchè ho potuto fare delle prove ed è proprio il server opc ua che mi rallenta la comunicazione e il tempo di ciclo, ho provato a disabilitare la lettura opc dal portale di acquisizione dei dati e sia la velocità di connessione dal pc e il tempo di ciclo sono tornati a valori normali.

anche cambiando il valore del parametro "carico di comunicazione" (con opc abilitato) la situazione non cambia.

è la prima volta che utilizzo opc ua nelle configurazione sia lato portale che plc non è che ci siano delle gran impostazioni da poter cambiare.

avete qualche suggerimento ?

 

grazie

[forna]

Tieni presente che la comunicazione con opc ua ti "ruba" tempo ciclo, intanto una cosa che puoi fare è togliere da tutte le db da ui non leggi in opc ua l'accesso da esterno (anche se di default è disattivata).

 

Una prova che ti potresti fare è impostare un tempo ciclo fisso della cpu a 50ms, in questo modo dai tempo alla cpu di gestire la comunicazione (gli operatori avranno il pannello reattivo, l'opc ua e con tia portal più veloce), oppure montare una cpu più performante.

Se c'è un portale esterno, c'è un pc acceso, sul quale potresti implementare un software (usando snap7) che legge tramite s7 e generare un opc ua server che il portale possa leggere.

Certo, tra il dire e il fare c'è di mezzo il mare

Modificato: 28 aprile 2023 da forna

[vergalabs]

non posso togliere l'accesso alle db da opc perchè altrimenti toglierei anche l'accesso della variabile all'hmi, impostare il tempo di ciclo fisso a 50ms sinceramente non so come si fa.

il portale esterno purtroppo è installato su macchina virtuale in un server aziendale a cui non ho accesso 

[cagliostro]

21 minuti fa, vergalabs ha scritto:

non posso togliere l'accesso alle db da opc perchè altrimenti toglierei anche l'accesso della variabile all'hmi, impostare il tempo di ciclo fisso a 50ms sinceramente non so come si fa.

il portale esterno purtroppo è installato su macchina virtuale in un server aziendale a cui non ho accesso 

come da screenshot a seguire

[vergalabs]

Grazie forna ,non sapevo di quella impostazione, l'ho cambiata ma non ho riscontrato nessun cambiamento nell'accesso al plc.

ho provato però a disabilitare il portale e accedere al plc tramite opc ua con il programma opcua expert e con questo non ho nessun rallentamento del ciclo.

a questo punto mi sorge il dubbio che sia qualche impostazione del portale

 

[drn5]

Comunque sei in buona compagnia.

Qualche giorno fa ero in una grossa azienda dove mi dicevano di avere problemi simili al tuo sia lato plc sia lato server in termini di lentezza.

Alla fine mi hanno fatto togliere l'ottimizzazione ai db per poter puntare direttamente quello che gli interessava senza più passare da opcua.

[vergalabs]

grazie a tutti,

Le mie db non sono ottimizzate e  il portale va a leggere solo i valori che interessano in db di "scambio" dedicate.

Settimana prossima proverò a sentire il fornitore del portale per vedere se c'è qualche impostazione, magari dal lato polling, del portale che può risolvere il mio problema 

[ETR]

Ciao vergalabs alcune piccole anomalie le le ho colte anche io con Siemens e OpcUa , dato che provenendo da B&R (dove OpcUa è nativo e integrato come sistema di interscambio) te lo trovi comunque, mentre in Siemens no e quindi dovendolo usare spesso, mi sono accorto anche io alcune volte di un aumento di alcune latenze.

 

A titolo indicativo (avevo scritto anche un post) con una 1212 avevo addirittura un blocco della comunicazione PC CPU, dopo un download, cosa che si è risolta semplicemente disattivando l'OpcUa. Ma anche con sistemi B&R mi è capitato di avere problemi, ma solitamente perché la predisposizione di default della comunicazione è molto spinta. Se non c'è necessità di tempi molto stretti, allora basta rallentare il tutto per riottenere sostanzialmente comportamenti "normali".

 

Di base con Siemens, preferisco adottare dei gateway dedicati che facciano loro la trasposizione ISOTCP/OpcUa. Per il costo e prestazioni, uso Weintek, il cmt-g04, dove puoi direttamente associare le variabili in assoluto o referenziato alle dichiarazioni (devi solo abilitare PUT e GET nelle CPU).

In altri casi lo faccio fare direttamente al pannello operatore Siemens (preferibilmente con TIA superiore o uguale a 16, con versioni "ante", abbiamo avuto problemi). 

 

Solo in particolari casi e con poche, molto poche variabili ho lasciato fare tutto alla CPU (1500 o 1200), premunendomi però di disabilitare tutto quello che non mi fosse utile in ogni DB (che fosse utile o meno, non ho poi verificato) anche solo come pubblicazione.

 

Buon weekend

 

Ennio

 

[vergalabs]

grazie ennio

ai gateway avevo pensato anch'io ma visto che doveva essere solo un controllo temporaneo di alcune variabili, per non spendere soldi, abbiamo optato per la soluzioni che ho scritto nel primo post poi come al solito, aggiungi qua e aggiungi la, è diventata permanente con 4 plc e circa 100 variabili a plc. i plc gestiscono delle utility quindi il tempo di ciclo no è che sia così importante il vero fastidio è l'hmi che non è più reattivo, chiamo la pagina e dopo 1,5/2 sec. i campi si popolano con le variabili e andare online o caricare modifiche nel plc. 

47 minuti fa, ETR ha scritto:

in altri casi lo faccio fare direttamente al pannello operatore Siemens (preferibilmente con TIA superiore o uguale a 16, con versioni "ante", abbiamo avuto problemi). 

a questo non avevo pensato, quindi mi suggerisci di far acquisire le variabili al pannello e farle leggere dal portale nel pannello? non rallento lo stesso il pannello? 

un'altra cosa che non capisco è perché acquisendo i dati dal mio pc utilizzando opc ua Expert non ho rallentamenti ma con il portale si 

[forna]

Anche secondo me Siemens ed opc ua non se la dicono bene. 

 

Soprattutto in ambiente simotion ho avuto moltissimi problemi, il server web che va offline e devo riavviare la macchina (fw precedente) , nell'ultimo firmware se fai un cambio ip il server web non è più raggiungibile da opc ua ad esempio. 

 

Per quanto riguarda i rallentamenti con opc ua Expert non succedono per il semplice fatto che leggo una volta e basta, bisognerebbe capire cosa è come comunica il portale tipo, ogni quanto legge le variabili? Siamo sicuro che comunque li legga ogni tanto e non cobtinuamente? 

 

Quando ti dicevo di disattivare l'accesso tramite opc ua alle db, intendevo ovviamente a quelle che non ti interessa leggere. 

 

In un progetto recente abbiamo utilizzato il server web come se fosse una API, si interroga l'url ed il server web genera una stringa json. 

 

Molto molto più veloce di opc ua (300ms contro 1,5sec) 

[vergalabs]

ho contattato il fornitore del portale e mi dice che non ci sono opzioni configurabili riguardo alla comunicazione opc.

Ho provato come suggerito da ETR a puntare con il portale al pannello e tutto sembra funzionare correttamente senza rallentamenti ne di ciclo cpu ne di lag sul pannello, ho però lasciato la versione 14 del tia, 

Il 29/4/2023 alle 09:50 , ETR ha scritto:

(preferibilmente con TIA superiore o uguale a 16, con versioni "ante", abbiamo avuto problemi).

ETR che problemi hai avuto?

14 ore fa, forna ha scritto:

In un progetto recente abbiamo utilizzato il server web come se fosse una API, si interroga l'url ed il server web genera una stringa json. 

purtroppo il portale è limitato alle licenze acquistate a saperlo prima magari si optava per un'altra soluzione ma ormai è fatta

[vergalabs]

vi espongo la mia esperienza che magari può tornare utile a qualcuno.

Come già esposto nei post precedenti la comunicazione opc ua ,almeno nel mio caso e con il mio portale di storicizzazione dati, diretta al plc crea dei rallentamenti che danno veramente fastidio mentre si fa il debug del programma o qualche modifica portando alle volte alla disconnessione del tia.

Allora ho migrato l'opc ,come suggerito da ETR, sui relativi hmi e la situazione è migliorata ma ho dovuto effettuare un downgrade da tia 16 a tia 14.1 di un hmi perchè sia con la versione 15.1 che con la 16 si avevano dei rallentamenti sul pannello che ne pregiudicano l'utilizzo, tipo dati nelle pagine che si visualizzano 2/3 sec. dopo aver caricato la pagina e comandi tramite pulsanti o campi numerici che vengono inviati al plc anche qui 2/3 sec. dopo, problemi che con la versione 14.1 del firmware non si presentano.

Probabilmente il firmware introducendo nuove funzioni diventa più "pesante" per la cpu del pannello. 

[ETR]

Ciao vergalabs , grazie del tuo riscontro, perché la problematica che avevamo trovato nel fare quello che ti ho suggerito, era stata quella di avere un pannello con TIA 13 (che non dava molte aspettative sul buon esito dell'operazione che ci eravamo prefissati, essendo precedentemente documentati) che avevamo aggiornato alla 16 per avere una comunicazione almeno funzionante.

 

A dire il vero, poi non eravamo noi stessi ad avere bisogno di questa lettura, per cui, quando con UA Expert abbiamo avuto la conferma di accedere alla mappatura e di poterla leggere sporadicamente, abbiamo dato che assodato che fosse anche affidabile come funzionalità.

 

Ma date le tue prove, nel caso dovessimo replicare la medesima soluzione, darò meglio un occhiata.

 

Buona giornata, Ennio

[acquaman]

Probabilmente il problema sulla comunicazione con le ultime versioni di cpu dovrebbe essere migliorato perchè hanno adottato un hardware dual core uno per le funzioni standard e uno per le comunicazioni.

[acquaman]