Wincc Flexible 2008 E Refresh Variabili - 100msec non sono 100 msec

[vashello]

Buongiorno a tutti,

stiamo riscontrando un problema un po strano con flexible 2008.

La nostra piattaforma base è un microbox IPC427C, ma abbiamo constatato che avviene anche in runtime su pc di sviluppo.

Le variabili che vengono definite con tempo di acquisizione 100msec non vengono acquisite a 100msec.

Quello che abbiamo constatato che questo tempo di acquisizione è varibile non costante a 100msec ma più verso i 200 msec.

Per effettuare un test abbiamo fatto un semplice esempio da sottoporre a siemens, che quindi a chi è interessato potrebbe facilmente provare.

Un ob a tempo di 10 msec, 2 istruzioni banali, per incrementare una variabile di +1 ad ogni ciclo:

IF (Var_counter <0 or Var_counter>1000) THEN 
     Var_counter := 0;
ELSE
    Var_counter := Var_counter + 1;
END_IF;

in flexible tramite un campo I/O inseriamo la variabile che si aggiorna, e come proprietà, 100msec di tempo acquisizione e a cicli continui. al suo cambio di valore lanciamo uno script di flexible che confornta la variabile di cui sopra con quella della lettura precedente.

SmartTags("VAR_GAP") = SmartTags("VAR_Counter") - SmartTags("VAR_old_value")

SmartTags("VAR_old_value") = SmartTags("VAR_Counter")

Quindi notiamo che la variabile GAP non è quasi mai 10 (corrispondente a 100Msec) ma vediamo spesso 20 (=200msec) e altri valori tipo 17,15,12...etc

se alziamo il tempo di acquisizione a 200msec il gap è più costante a 20, ma ogni tanto vediamo 30, e meno raramente 25..24..21

se alziamo il tempo di acquisizione a 500msec il gap è costante e vediamo sempre 50 e solo ogni tanto 49 e 51

Inoltre abbiamo notato che la situazione non cambia se le variabili SmartTags("VAR_old_value") e SmartTags("VAR_GAP") sono dichiarate come variabile temporanee di Flexible

Siemens fino ad ora non ci ha dato alcuna risposta in merito, ma se qualcuno ha qualche idea

o suggerimenti sono ben accetti.

PS.con flexible 2005 a 100msec il gap è sempre 10, e con flexible 2007 è leggeremnte peggio del flexible 2005 ma meglio del 2008.

Grazie e saluti

[mubeta]

Con che rete e che velocità PLC ed HMI sono collegati?

Quanti altri nodi sono presenti sulla stessa rete e quanti di questi sono dei Master?

E poi: avete provato a verificare l'effettiva capacità del PC di lanciare dei callback a 100ms? In ambiente Windows io non riesco a fare nulla a 100ms, forse 200ms. Avete provato a fare altrettatente prove per verificare che il PC sia in grado di tenere il passo? Due righe in C++, con interfaccia GUI, per verificare i tempi di un TimeCallback ??

[vashello]

Grazie per la risposta,

il PLC è un softPLC winac 4.5 e Flex è in Runtime sullo stesso plc industriale Siemens microbox 427C, con bundle di sW e HW come mamma siemens l'ha fatto.

il pc regge sicuro al 100% perchè con flex 2005 non c'è nessun problema anche su macchine molto più datate (meno ram e processore).

inoltre il "problema" si presenta pari pari anche in simulazione PLCSIM+runtime di flex su un pc normale (compreso FieldPG).

Saluti

[vashello]

Impossibile da credere ma la Siemens tedesca, si è mossa e ha ameesso che il sistema di flex2008 ha un difetto intrenseco che non può essere risolto internamente a flexible, am solo utilizzando un opc dove andare a leggere le variabili.

Giusto per informare ecco la risposta degli sviluppatori della casa madre:

"the tag data is fetched by a component called datacollector, it uses channels to get the data.
It has a cycle thread, which sleeps 100ms and checks then if any data is due to be fetched.
On 2007 rt , the sleep(100) lasts 109 ms mostly. the elapsed time is measured by using windows GetTickCount() call,
which has an inaccuracy of 15.625 ms on 2000/xp/w7 ( this is the clocktick intervall) therefore if as sleep last 109 ms
you will get 110 ms, but if sleep would last exactly 100 ms you would get 94 ms or 110 ms. 2008 runtime comes with a s7dos version
which install s7oiehsx helper service. This service call timeBeginPeriod(1), which enhances timer accury of windows system wide.
Now a sleep exctaly lasts 100 ms for all processes. Now the runtime gets often 95 ms as result how long the cycle thread slept.
the cycle thread checks the data item "left time" and thinks, there is 6 ms left, lets do the item in the next cycle. therefore item with 100ms cycle
are fetched mostly delayed in the next cylce so the cylce is 200ms in fact."

magari a qualcuno servirà!

Saluti