Perchè Normalizzare? - Trattamento segnali analogici da S7 300

[varlux]

Che emozione! Appena ho ricevuto il mio modulo di ingressi analogici (SM331 8AI-12bit) ho subito scaricato manuali e tutorial ed ho collegato una Pt100 ed una termocoppia (spero di trovare un trasduttore di tensione e\o di corrente nei prox giorni per poterli trovare).

Qualche dubbio, però, è rimasto:

- Non riesco a capire perchè, quando si parla di segnali analogici da catturare o spedire ad una scheda analogica, gli indirizzi vengono sempre preceduti dal prefisso "P" (PEW10; PAW12 ecc.). Che significato ha questo prefisso? Perchè viene utilizzato?

- Se devo emettere un segnale analogico, utilizzo la funzione RND per arrotondare il reale all'intero successivo in 32 bit......ma le schede analogiche non riconoscono soltanto gli interi a 16 bit? Cosa devo trasferire alla scheda, una word oppure una DW?

- Mi è sembrato di capire (e sono daccordo) che gli interi provenienti dalle schede analogiche devono essere convertiti in numeri reali a 32 bit. Non riesco però a capire l'esigenza della "normalizzazione", cioè quella operazione matematica (tanto sponsorizzata dal tutoria siemens), che permette la trsformazione proporzionale del REAL in un dominio compreso tra 100 e 1000: a cosa serve questa normalizzazione? Il REAL ottenuto dalla prima conversione non è abbastanza sicuro?

[ken]

PEW o PAW perchè di Periferia.

Le schede analogiche siemens danno come valore digitale per 10Vcc all'ingresso W#16#6C00 (che è 27648 in decimale). Valori a 32 bit non sono perciò accettati visto che il massimo che puoi scrivere per aavere 10Vcc è 27648.

Nonm serve affatto convertire in real un valore digitale proveniente da scheda analogica.

Normalizzarlo serve per avere dei valori sicuri. Se leggi w#16#3600 vuol dire che hai 5Vcc in ingresso. 5vcc cosa mi rappresentano? per valori da 0 a 10Vcc rappresenta il 50%. molto più comodo.

Modificato: 14 giugno 2006 da ken

[batta]

- Se devo emettere un segnale analogico, utilizzo la funzione RND per arrotondare il reale all'intero successivo in 32 bit......ma le schede analogiche non riconoscono soltanto gli interi a 16 bit? Cosa devo trasferire alla scheda, una word oppure una DW?

Per prima cosa lavorare con variabili REAL non è un obbligo, ma una scelta. Personalmente utilizzo le real solo quando sono indispensabili.

Secondo: la funzione RND arrotonda un valore REAL e lo trasforma in DINT. Se questo valore dovrà essere inviato ad una uscita analogica i limiti ammessi sono da 0 a 27648 (0000-6C00 in esadecimale), oppure da -27648 a +27648 se hai un'uscita, per esempio, ±10V. Il valore può quindi essere trasferito in una variabile INT.

Esempio:

Corretto

L 5000.2 carica valore REAL (32 bit) in accumulatore 1

RND arrotonda e converti in DINT. Il risultato (5000) viene messo in accumulatore 1

T PAW256 trasferisci la word bassa di accumulatore 1 all'uscita analogica

Se la tua uscita analogica è 0-10V dovresti leggere una tensione di 10*5000/27648 = 1,81 V.

Sbagliato

L 100000.2 carica valore REAL (32 bit) in accumulatore 1

RND arrotonda e converti in DINT. Il risultato (100000) viene messo in accumulatore 1

T PAW256 trasferisci la word bassa di accumulatore 1 all'uscita analogica

Questa operazione è sbagliata. Infatti se trasformiamo il valore decimale 100000 in esadecimale otteniamo 186A0. Con l'istruzione "T PAW256" andremo a trasferire in PAW256 solo la word bassa, ovvero 86A0 esadecimale, che corrisponde a -31072. Valore questo che, oltre ad essere fuori dal range permesso, è completamente sbagliato.

[varlux]

Grazie per le risposte ragazzi.

Adesso però, l'unica certezza che avevo (la necessità di utilizzare REAL) viene messa in discussione.

Mi sento comunque in dovere di difendere questa scelta, perchè condivido l'opinione secondo cui, convertendo in REAL i valori interi provenienti da una PEW, si diminuiscono gli errori di arrotondamento durante la loro elaborazione, o durante delle operazioni di calcolo che li interessano.

Ciò che, invece, non riesco ancora a comprendere, riguarda la "necessità" di una normalizzazione: perchè un dato normalizzato (100-1000) è più sicuro?

Mah......

[Livio Orsini]

Mi sento comunque in dovere di difendere questa scelta, perchè condivido l'opinione secondo cui, convertendo in REAL i valori interi provenienti da una PEW, si diminuiscono gli errori di arrotondamento durante la loro elaborazione, o durante delle operazioni di calcolo che li interessano.

Questo è sicuramente vero, però c'è da pagare un dazio: le operazioni aritmetiche in real sono risolte dalla CPU in tempi più lunghi rispetto a quelle in interi semplici. Basta leggere i tempi tipici per una moltiplicazione in interi e per una real, per la divisione il divario è ancora maggiore. Quindi è sempre necessario valutare bene costi (tempo di CPU) e benefici (precisione). Per esempio nei miei algoritmi di regolazione, generalmente, converto tutto in real e solo prima di "buttar fuori" il risultato lo riconverto in intero. Però ci sono casi in cui la velocità di esecuzione è esapserata; in questi casi lavoro solo in ionteri, magari moltiplicando per 10 o per 100 per aumentare la precisione dove serve.

Ciò che, invece, non riesco ancora a comprendere, riguarda la "necessità" di una normalizzazione: perchè un dato normalizzato (100-1000) è più sicuro?

Diciamo che può essere più pratico perchè siamo abituati a lavorare in decimale. Personalmente preferisco usare i dati degliA/D e D/A con la parola binaria del convertitore.

[varlux]

A questo scopo, cosa mi dite delle seguenti funzioni presenti nella libreria standard di STEP 7?

- FC 105 "SCALE"

- FC 106 "UNSCALE"

Ciao

[batta]

Dipende da cosa devi fare.

Io mi sono costruito delle funzioni scale ed unscale un pò diverse, adattate alle mie necessità, ma la sostanza rimane quella.

Poi, torno a ripetere, devi decidere se lavorare col valore binario richiesto dal modulo, o con unità ingegneristiche.

Il primo caso fa forse risparmiare qualche calcolo, ma devi avere sempre la calcolatrice in mano durante il debug per capire se i valori sono corretti o meno. Devi anche fare le scalature per la corretta visualizzazione sul tuo pannello operatore (problema minore, dato che ogni pannello operatore o supervisore è in grado di farlo senza difficoltà alcuna).

Nel secondo caso potresti decidere di lavorare con interi. Se, per esempio, devi scrivere il riferimento per un inverter, potresti far corrispondere il valore intero 1000 al 100.0% oppure il valore intero 10000 al 100.00%.

In questo caso usare la funzione unscale mi pare uno spreco. Il calcolo potrebbe semplicemente essere questo:

L INT_ING (valore ingegneristico intero ±10000)

ITD (trasforma in DINT)

L L#27648 (costante DINT 27648)

*D (moltiplicazione DINT)

L L#10000 (costante DINT 10000)

/D (divisione DINT)

T PAW256 (trasferimento all'uscita)

I valori L#27648 e L#10000, essendo positivi ed inferiori a 32767, possono anche essere scritti semlicemente 27648 e 10000. Specificare che si tratta di DINT è però più corretto.

La perdita di precisione, anche lavorando con valore ingegneristico massimo 1000, è sicuramente inferiore alla classe del modulo analogico.

Se hai fatto tutti i tuoi calcoli in REAL, puoi crearti una semplicissima scalatura nel seguente modo:

esempio per valore ingegneristico compreso tra ±10000.0

L REAL_ING

L 2.7648

*R

RND

T PAW256

N.B.: queste scalature semplificate sono corrette solo se lo zero del valore da scalare coincide con lo zero del valore scalato.

Le funzioni SCALE ed UNSCALE effettuano anche un controllo sul superamento dei limiti e permettono la scalatura anche nel caso lo zero da scalare non corrisponda allo zero scalato. Se i tuoi valori ingegneristici sono "sicuri" puoi evitare di usare SCALE ed UNSCALE, che sono un pò pesanti.

Molto dipende poi da quanti I/O analogici hai. Se sono pochi, chissenefrega se richiamo funzioni pesanti. Se sull'impianto hai qualche centinaio di I/O analogici, risparamiare risorse (anche se ci sarà sicuramente una cpu adeguata) semplificando qualche calcolo potrebbe tornare utile.

[varlux]

Dalle vostre affermazioni estrapolo quanto segue:

- La trasformazione degli INT provenienti da una scheda analogica possono tranquillamente rimanere degli INT ( ). Nella fattispecie, la loro trasformazione in REAL si rende necessaria qualora sia richiesta una loro elaborazione (ossia quando questi valori devono "partecipare" a dei calcoli aritmetici).

- Se ho la necessità di "leggere", ad esempio, la pressione rilevata da un trasduttore che, tramite il suo convertitore "linearizza" il segnale elettrico nel dominio bipolare +10V/-10V, posso anche usare la FC 105 (SCALE) impostanto dei limiti "proporzionali" al mio sensore (Cioè, se il trasduttore rileva pressioni nel dominio 0-15 bar, allora imposto il limite inferiore a 0 ed il limite superiore a 15)

- Dopo una conversione dell' INT proveniente da una scheda analogica in un REAL, uso la funzione RND per arrotondare questo valore in DINT. Successivamente posso inviare alla scheda la word bassa, senza rischiare errori. Se, ad esempio, nella Dword25 ho un valore di -10000 (ovviamente non superiore a +/- 32768), posso inviare alla scheda la word25: qui infatti si trova il valore.

E' tutto corretto?

Grazie

[batta]

Non ho capito molto bene.

Comunque, se tu devi trasformare una REAL in INT non è necessario appoggiare il risultato in una DINT.

Esempio:

L DB10.DBD0 (REAL)

RND (DINT)

T DB10.DBW4 (INT)

Potresti anche fare

L DB10.DBD0 (REAL)

RND (DINT)

T DB10.DBD4 (DINT)

e poi prendere il valore INT da DB10.DBW6, ma è solo un passaggio in più.

Con la funzione RND ti trovi nell'accumulatore il valore arrotondato in formato DINT, ma se tu trasferisci in una variabile in formato INT verrà trasferita solo la parte bassa del contenuto dell'accumulatore.

Attenzione che devi sempre controllare che il valore originale in REAL sia compreso tra -32768.0 e +32767.0, altrimenti il dato finale trasferito in variabile INT non avrà nessun senso.

[Faust]

Concordo con Livio quando dice che trasformare tutto in REAL comporta una perdita di tempo maggiore nella gestione dei segnali (normalizzazione, comparazioni, calcoli vari). Chiaro che se non hai problemi di questo tipo puoi infischiartene della velocità di elaborazione (stiamo sempre parlando di millisecondi o centesimi di secondo).

Anch'io, come Livio, quando ho problemi di velocità di elaborazione preferisco moltiplicare la lettura fatta x10 o x100 e poi lavorare con interi, poi alla fine divido tutto x il fattore per cui ho moltiplicato prima (se serve).

P.S. io non uso prevalentemente SIEMENS, ma il discorso è uguale x tutti i plc.

[ken]

Dopo una conversione dell' INT proveniente da una scheda analogica in un REAL, uso la funzione RND per arrotondare questo valore in DINT. Successivamente posso inviare alla scheda la word bassa, senza rischiare errori. Se, ad esempio, nella Dword25 ho un valore di -10000 (ovviamente non superiore a +/- 32768), posso inviare alla scheda la word25: qui infatti si trova il valore.

no, 27648 (w#16#6c00) per avere 10Vcc, 32768 è di certo superiore a 10Vcc.

Se passi la word bassa non hai la certezza matematica che il valore sia nei limiti.

dice poi benissimo Livio.

Normalizzare perchè?

Se hai diverse misure di lunghezza espresse in millimetri, metri, pollici, piedi, yard, etc etc come fai a sommare tutti i tuoi valori?

prima li metti tutti nella stessa unità di misura e poi, se serve, trasformi tutto in ciò che ti serve come unità di misura finale.

Nel PLc è lo stesso