Lentezza Protocollo Opc

[giuseppe74]

Ciao a tutti,

io ho su un pc un programma che attraverso il protocollo OPC và a leggere e a scrivere su aree di memoria di un PLC Siemens su una comunicazione profibus a 12Mb. Quando sono in lettura lo scambio dati è abbastanza veloce (mezzo secondo per leggere una DB).

Quando invece vado a scrivere, il dato (anche solo un byte) ci mette circa 5 secondi per essere aggiornato...

Qualcuno sà dirmi perchè???

C'è forse da settare una velocità di comunicazione sull'opc server???

Le ho provate un pò tutte... aiuto...

Giuseppe

[IMM-Domenico]

C'è forse da settare una velocità di comunicazione sull'opc server???

Si, molto probabilmente c'è qualcosa da settare. Che OPC Server utilizzi?

Ad esempio il mio (KepServerEx) ha delle opzioni per privilegiare la lettura piuttosto che la scrittura. Di default viene eseguita una scrittura ogni N letture. Probabilmente c'è qualche parametro nascosto da qualche parte.

[walterword]

non mi risulta

ho scritto diverse applicazioni client , basate su opc server somatic net e ti posso

garantire che le scritture , di aree di memoria contigue ma comunque tante , si aggiornavano

in meno di 1 sec , i 5 secondi non li capisco e nemmeno il settaggio per privilegiare

la scrittura piuttosto che la lettura

L'unica spiegazione potrebbe essere se leggi un intero da un db , salti ad un altro db e leggi un altro dato e

salti ad un altro db .

ciao

walter

[Henon]

Anch' io ho visto questo problema in una mia applicazione, in cui molti dati

venivano richiesti in Lettura. SimaticNet versione 6.3

Poi per scrivere 12 Real ci metteva circa 8-9secondi. mentre per leggere era abbastanza veloce.

(La rete Ethernet-WireLess Viaggiava a 11mb).

Però devo aggiungere che c'erano molti dipositivi che richiedevano il servizio al PLC

(Non superiori al numero massimo configurato nel Hardware-configure )

N°1 PLC S7 315-2DP + CP341 ethernet (Il PLC dove bisognava scrivere i 12 Real)

N°1 PC di Supervisione e Controllo con SimaticNet (Quello che impiegava 8-9 secondi a scrivere i 12 Real)

N°1 PC di Manutenzione con S7 che con impegava, per scrivere gli stessi Real meno di 0.5 secondi.

(Scrivendoli direttamente in On-Line con S7)

N°1 Panello di Controllo

N°1 PLC S7 315-2DP + CP341 che era il Collegamento con il PLC sopra descritto.

In Pratica 2PLC 315-2DP in Rete Ethernet con scambio dati tra loro + PC di Supervisione con SimaticNet.

La stessa Applicazione usando invece KepServerEx anzichè il SimaticNet impiega solamente 0.145 secondi.

Secondo me il Servizio SimaticNet ha qualche serio problema, che nessun tecnico specialmente della

Siemens ti sa spiegare e risolvere.

Io Ultimamente non uso più il SimaticNet perchè c'è sempre qualche problema, specialmente nel configurarlo.

Magari al altre persone gli funziona perfettamente, ma a me questo problema è già emmerso in 3 Applicazioni.

Mi Piacerebbe sapere se qualche persona ha già incontrato questo problema e lo ha già risolto.

Grazie.

[Henon]

PS: il tempo che impiega a scrivere 1 Real e lo stesso che impiega per scriverne 100 real.

Questo indica che ci sono dei tempi ben precisi per scrivere,

perciò se questi interrupt sono legati al numero di pacchetti in Lettura,

e se questi sono elevati, bisogna aspettare molto tempo.

Infatti preferisco scrivere un array molto grande di dati e spedirli in una sola volta.

Cosi risulta più rapido.

Però se per questioni diverse devo spedire dati non contigui, emergono

i problemi.

[dthsp]

Un problema potrebbe essere quello che ha accennato Henon che riguarda i dispositivi collegati alla CPU. E' capitato ad un mio collega che con una 315-2DP con 4 ET200 (gli I/O non erano molti, c.a 200) e 3 TP270 tutti in Profibus, accendendo il supervisore (sviluppato con InTouch) la comunicazione diventava lentissima (ovviamente solo gli HMI e non gli I/O). Mettere InTouch in MPI o in Profibus o cambiare la velocità di comunicazione non dava nessun effetto visibile. La soluzione è stata cambiare la CPU con una 317-PN /DP (probabilmente sarebbe stato sufficiente montare una CP342-5) e far comunicare il supervisore in Ethernet. Il problema è che la 315 (come tante altre CPU) hanno un processore unico che si occupa di tutto e, perciò, lascia per ultima la gestione dello scambio dati verso apparecchi HMI, mentre la 317, come l'utilizzo di una CP, hanno un processore che si occupa della sola comunicazione.

Ciao,

Daniele

Modificato: 10 settembre 2006 da dthsp

[Henon]

Forse hai raggione tu "Dthsp", però non mi spiego perchè tramite S7 scrivo questi dati in un Lampo e cosi pure, se uso un PC con un Applicativo ProTool-RT.

Forse è il Pacchetto SimaticNet che ha qualche problema.

Però quando ho l'occasione provo a verificare se è una questione di

PLC.

Grazie

[walterword]

ragazzi , siete sicuri di quello che dite ?

dovrei basare un progetto su questa tecnologia e

sinceramente da quanto sento non ho proprio voglia di prendermi la testa .

Io avevo gia utilizzato opc server , ma in rete non c'erano molti devices , e di conseguenza

la cosa non era male , visualizzavo con tempi di refresh tipo win CC o protool , ma se mi dite

che ci vogliono 5 secondi inizio a preoccuparmi

Avete avuto modo di sentire quelli del '2000 del hot line siemens?

Se si , vi andrebbe di far sapere qua nel post cosa vi hanno risposto

ciao

walter

Modificato: 11 settembre 2006 da walterword

[IMM-Domenico]

Walter, se vuoi andare sul sicuro, vai su KepServerEx... non mi risulta che se ne sia lamentato qualcuno. Mi sembra ben fatto, professionale, e anche completo come numero di devices supportati (l'elenco è sterminato).

Non è una pubblicità (vi garantisco che non me ne entra niente in tasca), ma il semplice risultato della mia esperienza personale.

Penso che altri saranno d'accordo.

[Savino]

Ciao,

vai su KepServerEx...

Dunque, KEPServerEX OPC Server e' senzaltro un eccelente oggetto ma non centra nulla col fatto di che l'OPC e gli I/O Server ( DDE, Factory Suit ) di SIMATIC NET ci impiegano 8 sec. a scrivere 12 Real... Secondo la mia esperienza con queste interfaccie, dovreti essere entro 1 sec.

°1 PLC S7 315-2DP + CP341 ethernet (Il PLC dove bisognava scrivere i 12 Real)

CP341 ethernet non esiste.

Piuttosto CP343 ....

Henon, tuo problema potrebbe essere localizzato nel codice CLIENT. Se l'hardware e' stato ben costruito allora da qualche parte pende un delay. Anche nel codice PLC, la routine di aggiornamento AG<->CP potrebbe girare non ergregiamente.

Che ci metta 8 sec. e' impensabile. Pensa te allora la Siemens dovrebbe mandare a casa i loro progettisti e contrattarne a quelli della Kepware

Poi, avete utilizzato un SCADA, quale? oppure hai richiamato le interfaccie in un Client VC++ ?

COML S7 ?

[Henon]

Hai Proprio Ragione Savino, mi sono sbagliato è la CP 343-1, forse mi sto perdendo ho mille

problemi per la testa.

Tra PLC non avevo nessun problema lo scambio dei Messaggi era Corretto e abbastanza Veloce.

L' applicazione per Gestire l' impianto è stato fatto in Visual-Basic utilizzando il Richiamo

DDE/OPC del Servizio SimaticNet.

Probabilmente c'è qualcosa di anomalo, ma non sono stato capace di individuarlo.

Per questo motivo anch'io come "giuseppe74"; "dthsp" mi sono associato alla discussione, per

sentire altri Pareri a tale riguardo.

Grazie Savino proverò ad indagare quando avrò l'occasione.

[walterword]

secondo la mia esperienza , in un impianto c'erano 8 pc con WinCC basato su opc server e

nonostante tutto non era cosi lento

Potreste essere piu specifici , magari un errore di scheda o settaggio dell'opc ?

grazie

ciao

[IMM-Domenico]

Una prova veloce, tanto per vedere cosa succede, la potete fare. Disabilitate tutti gli eventuali firewall nel percorso tra PC e PLC... mi sembra di ricordare di aver risolto un problema simile aggiungendo un'eccezione al firewall.

[ifachsoftware]

Una prova veloce, tanto per vedere cosa succede, la potete fare. Disabilitate tutti gli eventuali firewall nel percorso tra PC e PLC... mi sembra di ricordare di aver risolto un problema simile aggiungendo un'eccezione al firewall.

Per me non ha senso , perche' un firewall o li fa passare o li blocca , non un po' si e un po' no ...

Ciao

[walterword]

O comunque uan qualcosa tipo norton antivirus o controlli che prendono il sporavvento

di questo genere

[Savino]

Tra PLC non avevo nessun problema lo scambio dei Messaggi era Corretto e abbastanza Veloce.

Bene !

L' applicazione per Gestire l' impianto è stato fatto in Visual-Basic utilizzando il Richiamo

DDE/OPC del Servizio SimaticNet.

Dai una guardatina a questo Cliente fatto in Visual Basic... forse ne trovi l'ingippo.....

[IMM-Domenico]

Per me non ha senso , perche' un firewall o li fa passare o li blocca , non un po' si e un po' no ...

Certo... però è possibile che il firewall blocchi, e il software esegua diversi tentativi prima di trovare una strada alternativa non bloccata dal firewall, impiegandoci più tempo del necessario. Ripeto... mi è capitato un problema simile tempo fa, e l'ho risolto proprio aggiungendo un eccezione al firewall.

Quando si ha a che fare con l'informatica non è raro trovarsi di fronte a comportamenti strani e imprevedibili. E' impossibile conoscere approfonditamente tutti i prodotti com i quali si ha a che fare... e capita anche che gli sviluppatori stessi alle volte si sorprendano di comportamenti anomali delle loro creature. Chi non ricorda l'espressione di Bill Gates davanti alla schermata blu durante la presentazione di Windows 98?

Comunque sia è un tentativo semplice e veloce. Tentare non nuoce, no?

In bocca al lupo. Domenico.