Documentazione

Per prima cosa desideriamo ringraziare alcuni di Voi, che ci hanno segnalato questo argomento come articolo da pubblicare sul nostro Blog. Naturalmente Vi incoraggiamo a scriverci anche solo per esprimere le vostre opinioni.
Come avete letto dal titolo, in questo articolo cercheremo di confrontare il C-script e VB-Script per le versioni di WinCC 6.x in poi, compresa la nuova e tanto attesa versione 7.

Cominciamo con il precisare la differenza tra “azioni” e “funzioni”; in quanto ad alcuni non è ancora ben chiara…

Innanzitutto le azioni vengono utilizzate per attività di background, quali p. es. stampe giornaliere di protocolli, il monitoraggio di variabili o l’esecuzione di calcoli.

Le funzioni sono porzioni di codice che possono venire utilizzate in più punti, la cui definizione però si effettua in un punto solo. WinCC mette a disposizione numerose funzioni, liberamente utilizzabili e visibili direttamente nel riquadro a sinistra dell’editor della funzione. Inoltre è possibile scrivere funzioni ed azioni proprie, utilizzando l’ambiente Global Script e selezionando uno dei 2 ambienti che WinCC mette a disposizione: C-Script e VB-Sscript.

In WinCC è possibile utilizzare parallelamente VBScript e C-Script, ma non intersecare i due tipi di script:

• all’interno di una pagina e di un progetto si possono progettare sia script VBS che script C: cioè posso associare ad un specifico evento un’azione C mentre per un altro tipo di evento un’altra funzione VBS
• gli script C non si possono richiamare negli script VBS e viceversa.
• in VBS sono a disposizione interfacce interne per variabili e oggetti di pagina, mentre nell’ambiente C è anche possibile accedere ad altri sottosistemi di WinCC (per es. i protocolli).

Inoltre da tenere presente che il tipo di dati delle variabili VBS è sempre VARIANT, mentre in C-Script si possono decidere il tipo di dati opportuno (char, double,ecc…)

In VBS di WinCC, contrariamente a C, non viene fatta alcuna differenziazione fra azioni locali (valide per tutto il progetto) e azioni globali (valide per tutto il computer). Un’azione progettata è sempre valida globalmente. Tenere presente che le lunghezze dei nomi degli oggetti dinamizzati in Graphics Designer  è spesso fonte di errori!!! Infatti tali lunghezze sono limitate a circa 200 caratteri, e che nei file script ogni carattere speciale utilizzato nel nome di un oggetto viene trasformato in 5 caratteri.

Dietro un X iniziale, il carattere speciale viene rappresentato in codice esadecimale a 4 cifre.

Se con un’azione VBS si dinamizza una proprietà dell’oggetto attraverso il valore di ritorno di uno script, il valore della proprietà dell’oggetto viene scritto soltanto se è cambiato rispetto all’ultima esecuzione script. In tal caso, non viene considerato se il valore è stato modificato da un’altra posizione.

Fate quindi attenzione quando dinamizzate una proprietà tramite valore di ritorno, in quanto non dovranno essere modificate in altri punti da C-Script o VB-Script

Per quanto rigurada le funzioni e le variabili globali in C, c’è solo da dire che la capacità di memoria massima disponibile di 64 KByte.
Inoltre tenere a mente che non è ammesso definire una variabile C in più posizioni. Per maggior chiarezza e per evitare definizioni doppie, è opportuno quindi definire le variabili C globali solo
in una posizione. Per definirla in una sola posizione basta fare così:

extern int a; //La variabile a viene dichiarata esterna

Oltretutto, con C-Script, a differenza di VBS, ho la possibilità di usare delle DLL proprie (Dynamic Link Libraries). Le funzioni comprese in DLL esistenti possono essere rese utilizzabili per funzioni ed azioni integrando la funzione o l’azione interessata.

Per utilizzare una DLL basta inserire all’inizio della funzione o dell’azione il seguente codice:

#pragma code(“<Nome>.dll”)
<Tipo di valore di retorno> <Nome di funzione 1>(…);
<Tipo di valore di ritorno> <Nome di funzione 2>(…);
.
.
.
<Tipo di valore di ritorno> <Nome di funzione n>(…);
#pragma code()

Per chi vuole sviluppare DLL ad hoc, ricordiamo che la struttura della DLL deve essere creata con allineamento a 1 byte. Inoltre la DLL deve trovarsi in una directory bin o in un percorso definito nelle variabili del sistema PATH.

Tale variabile viene definita tramite le proprietà di sistema del sistema operativo.

Un’ ultimo confronto possiamo farlo in termini di prestazioni tra VB-Script e C-Script: tale confronto viene anche riportato nella guida in linea di WinCC e sono test fatti direttemente da Siemens.

Nella guida in linea di WinCC è dedicato un capitolo “Prestazioni” dove sono comparati i tempi di esecuzione per ogni singola azione nei due ambienti.

Quello che subito salta all’occhio è che C-Script è preferibile in buona parte dei casi. Ma un attento programmatore potrebbe ottimizzare il tempo di esecuzione dei script scegliendo di volta in volta l’ambiente più appropriato.

Per adesso, mi fermo qui con questa carrellata su questi ambienti Script. Purtroppo l’argomento è molto vasto e il tempo per scrivere poco.

(MB)