Vai al contenuto
PLC Forum


Conversione Di Un Float Da Siemems


salsi

Messaggi consigliati

Buonasera,

Sto cercando di registrare i dati da un sentronpack 4200 su un controllogix, i dati che arrivano dallo strumento sono dei Float a 32 bit mentre vengono passati tramite scheda appostita a Rockwell in 2 word da 16 bit (int). come fare ad avere lo stesso valore che vedo sul pannello del Sentron? Ho provato a swappare i byte e a copiarli su dint ma nulla. Penso che il problema sia il bit di segno ? qualcuno ha idee?

Link al commento
Condividi su altri siti


Ma in Rockwell come lo leggi il valore?

Il formato float a 32 bit è standard. Non dipende dalla marca del PLC.

Al massimo si tratta di vedere come riordinare i bytes.

Probabilmente dovrai scambiare tra di loro il byte alto della prima word con il byte basso della seconda word, e il byte basso della prima word con il byte alto della seconda word.

L'ordine Byte 0 - Byte 1 - Byte 2 - Byte 3 dovrà diventare: Byte 3 - Byte 2 - Byte 1 - Byte 0.

Link al commento
Condividi su altri siti

del_user_27683

Il tuo problema penso sia dovuto al fatto che lo strumento fornisce un REAL ma al PLC arrivano 2 INT, anche accoppiandoli in un DINT pur essendo 32 bit non ha nulla a che vedere con un REAL composto da segno+esponente+mantissa. Personalmente ci vedo tre soluzioni:

- se possibile fare in modo che la scheda (che non conosco) scriva sul PLC un REAL, a questo punto la conversione da REAL a DINT non è necessaria perchè il controllogix la fa automaticamente con la MOV

- se possibile scrivere sul PLC il valore già convertito in formato intero

- se non resta altro devi capire dove mette segno-esponente-mantissa (magari scrivento un valore noto) e farti una routine per la conversione

ciao

Link al commento
Condividi su altri siti

Non puo usare la MOV .

Sarebbe bene avere le due word da 16bit in due elementi consecutivi in un array di INT (Esempio Valore[0] e Valore[1])

poi esegui la COP in un variabile Real (Esempio VarReal)

----COP -----

Source : Valore [0]

Dest : VarReal

Lenght :1

-------------------------

Oppure se come dici lo hai messo già in un DINT rispettando l'ordine dei Byte usi sempre la COP dal DINT al REAL.

P.S. : La COP copia da sorgente a destinazione byte per byte senza effettuare alcuna conversione, la lunghezza (Lenght) si riferisce alla destinazione , ovvero se scriverai in un Real la COP prenderà 4 Byte partendo dalla Sorgente specificata.

Un Esempio preso dalla Knowledgebase Rockwell potrebbe aiutarti.

https://rockwellautomation.custhelp.com/app/answers/detail/a_id/279306

CIAO.

Link al commento
Condividi su altri siti

Il tuo problema penso sia dovuto al fatto che lo strumento fornisce un REAL ma al PLC arrivano 2 INT, anche accoppiandoli in un DINT pur essendo 32 bit non ha nulla a che vedere con un REAL composto da segno+esponente+mantissa.

Non sono d'accordo.

32 bit sono sempre 32 bit. Non importa se li leggi tutti insieme, uno alla volta, suddivisi in 4 byte o in due word.

Si devono solo riordinare i 4 byte nel modo corretto, e poi ti ritrovi ancora con una variabile in virgola mobile a 32 bit.

Link al commento
Condividi su altri siti

  • 2 weeks later...

Penso abbia ragione Batta.

si deve usare uno SWAP dei singoli Bytes

Prendendo la DWord come somma della DW0 e DW1 o meglio in Byte DB0,DB1,DB2,DB3

Supponiamo di Chiamare questa DWord con una Tag di nome "SourceDw"

e di Chiamare "AuxDINT" la Dword di Appoggio che risulta essere Swappata

cosi esegui con un istruzione SWPB(SourceDw,REVERSE,AuxDINT);

Con l'opzione Reverse si invertono i Byte come ha detto appunto Batta da "ABCD" in "DCBA"

Bene dopo di ciò esegui una Castomizzazione del Dato da DINT in REAL

con un Istruzione CPS oppure COP

in Questa Maniera CPS(AuxDINT,DestReal,1);

Dove la tag "DestReal" sarà il Valore finale in Real

Viceversa quando devi inviare un dato dal ControlLogix verso altri dispositivi che usano il Formato Litle-Indian o Intel

ControlLogix usa il Formato Big-Indian o Motorola, mentre Siemens ad esempio usa Litle-Indial o Motorola.

Perciò i Real devo essere sempre convertiti.

Link al commento
Condividi su altri siti

Bene dopo di ciò esegui una Castomizzazione del Dato da DINT in REAL

Non sono d'accordo.

Una volta riordinati i bytes nel modo corretto, il dato è già in formato REAL, e non ha bisogno di alcuna conversione.

Prendiamo una variabile REAL con valore 1234.5

Se leggo (partendo dal byte più significativo verso quello meno significativo) in esadecimale i 4 byte che compongono questa variabile mi trovo:

Byte 0: 44

Byte 1: 9A

Byte 2: 50

Byte 3: 00

Non importa poi come io effettui la lettura di questi 4 byte, perché la lettura non comporta nessuna conversione.

L'unica cosa che dovrò cambiare sarà l'ordine di questi 4 byte. In Rockwell, sempre dal byte più significativo verso quello meno significativo, dovrò trovare la seguente situazione:

Byte 3: 44

Byte 2: 9A

Byte 1: 50

Byte 0: 00

Se visualizzo questa variabile in formato REAL, devo trovare ancora il valore 1234.5, senza bisogno di conversioni.

Interessante sarebbe poi avere notizie da "salsi", ma la cattiva abitudine di porre le domande e non rilasciare un feedback è purtroppo molto diffusa.

Ed è un vero peccato perché, oltre ad una questione di semplice buona educazione, sapere se le risposte sono state risolutive sarebbe di grande interesse per tutti gli utenti del forum.

Link al commento
Condividi su altri siti

Viceversa quando devi inviare un dato dal ControlLogix verso altri dispositivi che usano il Formato Litle-Indian o Intel

ControlLogix usa il Formato Big-Indian o Motorola, mentre Siemens ad esempio usa Litle-Indial o Motorola.

Qui fai un po' di confusione.

Big-endian: il primo byte è quello più significativo (da sx verso dx: Byte 0 - Byte 1 - Byte 2 - Byte 3). È lo standard usato dai processori Motorola, nei protocolli Internet e, purtroppo, nei PLC Siemens.

Little-endian: il primo byte è quello meno significativo (da sx verso dx: Byte 3 - Byte 2 - Byte 1 - Byte 0). È lo standard usato dai processori Intel e dalla stragrande maggioranza dei PLC.

Link al commento
Condividi su altri siti

Ciao Batta quello che qui dici

"Non sono d'accordo.

Una volta riordinati i bytes nel modo corretto, il dato è già in formato REAL, e non ha bisogno di alcuna conversione."

non è corretto.

In quanto bisogna fare per forza una Castomizzazione da DINT in REAL, altrimenti in Ambiente Rockwell non leggi il Valore Reale, ma un Valore DINT, che non ha senso.

Quindi devi per Forza eseguire l'istruzione CPS(AuxDINT,DestReal,1).

Esempio il Valore DINT 1078530011 corrisponde in 3.1415927

ma una TAG in formato DINT non ha il Medesimo significato per una Tag in Formato REAL.

Ti faccio un esempio:

se dallo strumenti leggi un Valore DINT come -619755200

se esegui lo Swap avrai 1078530011

se poi esegui la castomizazione avrai il valore 3.1415927.

un altro Esempio

se dallo strumenti leggi un Valore DINT come 419700801

se esegui lo Swap avrai 1092617241

se poi esegui la castomizazione avrai il valore 10.001

Per il formato hai ragione il Big-Indian è usato da S7

mentre in CLX è usato il Litle-Indian.

Link al commento
Condividi su altri siti

Quando leggo la variabile, non leggo una REAL o una DINT, ma leggo semplicemente 32 bit, così come sono, senza nessuna conversione.

Poi si tratta solo di decidere come interpretare questi 32 bit.

Se la sequenza di bit 0100_0100_1001_1010_0101_0000_0000_0000 la interpreto in virgola mobile, avrò il valore 1234.5. Se la interpreto come esadecimale avrò 449A_5000. Se la interpreto come decimale, avrò 1150963712.

Ma si tratta sempre della stessa identica sequenza di 32 bit.

Quando effettuo una lettura (non importa se via Modbus o in quale altro modo) leggo questi 32 bit senza effettuare conversioni di nessun tipo.

Se la sequenza originale la leggo e poi faccio una conversione da DINT a REAL, mi troverò con quei 32 bit che, interpretati come DINT assumono il valore 1150963712 che, convertito in in virgola mobile diventa 1.150964e+009 (il valore viene approssimato), che in binario diventa 0100_1110_1000_1001_0011_0100_1010_0000.

Invece devo semplicemente leggere quei 32 bit (0100_0100_1001_1010_0101_0000_0000_0000), eventualmente riordinare i byte in modo che non vengano disposti nell'ordine sbagliato (0000_0000_0101_0000_1001_1010_0100_0100) e, visto che quei 32 bit in origine erano di una variabile trattata come REAL, trattarli ancora come REAL.

Modificato: da batta
Link al commento
Condividi su altri siti

Ben Scusa ma quando dichiari un Modulo, per Ethernet o ProfiBus,
devi per forza di cose decidere in quale formato ricevere il Dato.

Se "Salsi" li ha dichiarati come 2 INT, il benedetto controlLogix non sa che è un Dato REAL.

Perciò Bisogna convertirlo in REAL. (Castomizazione)


Questo lo si fa anche nell0 Step7 con l'istruzione DTR.

Altrimenti anche in siemens non si riesce a gestire le operazioni tra Un Elemeto (0100_0100_1001_1010_0101_0000_0000_0000)
e un effettivo valore in Virgola Mobile 1234,5

Infatti una sequenza di Bits come in un DINT non hanno lo stesso valore se espressi in Formato REAL
oppure come una sequenza di bit (0100_0100_1001_1010_0101_0000_0000_0000) vale 1150963712 in Decimale


1150963712 non è uguale a 01000100100110100101000000000000 e neppure a 1234,5


Infatti un Real secondo lo Standard IEEE 754 in singola precisione

sarà:

R = (-1)^S * B^E * M

R= Valore in Reale
S = Segno
M = Mantissa
E = Esponente
B = Base (base Binaria =2)


il Formato il Bit è il seguente
S EEEE EEEE MMM MMMM MMMM MMMM MMMM

Segno = 0
Esponente 10001001 = 137 (togliendo il Bias Cioe 127 si ha 10)
Mantissa = 00110100101000000000000

Se segui lo standard IEEE754 la conversione vine fatta nel seguente modo.

il numero 1234.5 diventa in Binario : 10011010010,1 (base2)
Moltiplico per 2 per 10 volte in questo modo avrò il numero 1,00110100101*2^10
Perciò esponente è 10, ma devo poi sommare 127 come Standard 10001001
La Mantissa è 00110100101

Quindi:
S= 0 (Perchè Positivo)
E= 10001001
M = 00110100101

Cosi "Salsi" devi fare come ti ho detto io che il risultato è sicuro al 100%

Devi prestare attenzione solo al ordine dei 2 INT che trasmetti.

Perciò se sai che dallo Strumento hai un certo valore, puoi capire quale è il giusto ordine dei 2 Integer

Sempre si deve fare lo Swap e la Conversione .

Modificato: da Henon
Link al commento
Condividi su altri siti

Ben Scusa ma quando dichiari un Modulo, per Ethernet o ProfiBus,

devi per forza di cose decidere in quale formato ricevere il Dato.

Se "Salsi" li ha dichiarati come 2 INT, il benedetto controlLogix non sa che è un Dato REAL.

Perciò Bisogna convertirlo in REAL. (Castomizazione)

Dichiarare il tipo di variabile serve per:

1) conoscere la lunghezza del dato

2) sapere come interpretare il dato

Ma con la lettura non viene effettuato nessun tipo di conversione!!!

Nel caso specifico (lettura del dato REAL a 32 bit spezzata in due variabili da 16 bit), sempre per continuare l'esempio del valore in virgola mobile 1234.5, significa che la prima variabile che leggerò sarà:

0100_0100_1001_1010

e la seconda:

0101_0000_0000_0000

Non importa proprio a nessuno quale sia il formato di queste due variabili. Sono, molto semplicemente, due variabili da 16 bit che contengono degli 1 e degli 0.

Poi devo solo ricomporre le due variabili da 16 bit ed eventualmente fare uno swap dei byte, in modo da ottenere una variabile a 32 bit che contenga ancora

0100_0100_1001_1010_0101_0000_0000_0000

Questa variabile, interpretata in virgola mobile, vale 1234.5

Se nel PLC visualizzi il valore di una variabile e poi decidi di cambiare formato di visualizzazione, non viene modificato il contenuto della variabile, ma viene solo visualizzato un valore diverso.

Se prendo la solita variabile

0100_0100_1001_1010_0101_0000_0000_0000

e visualizzo il valore in REAL, vedrò 1234.5.

Se la stessa variabile decido di visualizzarla in DINT vedrò 1150963712

Ma si tratta sempre degli stessi 32 bit. È solo il modo di interpretarli che cambia.

Sempre si deve fare lo Swap e la Conversione .

Quindi si dovrà fare lo swap per cambiare da big-endian a little-endian, ma non si dovrà fare la conversione.

Modificato: da batta
Link al commento
Condividi su altri siti

Ma un Elemento il Real nel PLC Rockwell, non è permesso accedere ai singoli Bits, come

fai tu in Step7.

Perciò una Tag Real è diversa da quella DINT.

Non si può cambiare il modo di rappresentare questa tag in altra maniera, forse puoi cambiare lo Stile

Scientifico oppure Float-Point Normale.

Si in Step7 il tuo Dato a diversi significati, ma quando esegui delle operazioni matematiche

come Somma, moltiplicazione etc, devi convertire il tuo dato, altrimenti

i risultati non tornano.

la DTR in S7 ad esempio serve per passare un dato da formato DINT in REAL.

Cosi in Rslogix usi la CPS.

Non devi essere critico in ogni cosa, ascolta questo mio consiglio.

Link al commento
Condividi su altri siti

Non è questione di essere critico, ma solo di fare le cose nel modo giusto.

Il dato in partenza è già in formato REAL. Il fatto che venga letto spezzato su due word per trasferirlo da un dispositivo all'altro non implica nulla: all'arrivo, una volta ricomposto, sarà ancora un dato in formato REAL.

Se carico delle mele su un camion, non è che quando arrivano a destinazione sono diventate delle pere.

E se le carico su due camion anziché uno solo, a destinazione saranno comunque ancora le stesse mele che erano alla partenza.

Link al commento
Condividi su altri siti

E se le carico su due camion anziché uno solo, a destinazione saranno comunque ancora le stesse mele che erano alla partenza.

E' vero, però se le mele son caricate su 2 autocarri differenti perchè al primo corrisponde la seconda scelta ed al secondo la prima scelta, si pone un problema all'arrivo.

Ammesso che non sia possibile identificarli in altro modo, se il ricevente conosce che il primo autocarro trasporta la seconda scelta saprà come trattare i due carichi, sempre che non ci sia stato un sorpasso durante il tragitto. Se il ricevente è abituato a ricevere sempre la prima scelta come primo carico, sbaglierà ad immagazzinare i due carichi ricevuti.

Modificato: da Livio Orsini
Link al commento
Condividi su altri siti

Se il ricevente è abituato a ricevere sempre la prima scelta come primo carico, sbaglierà ad immagazzinare i due carichi ricevuti.

Ma questo implica solo che devo mettere nell'ordine corretto le due word che leggo e, al limite, che devo riordinare i byte per passare da big-endian a little-endian.

La conversione da DINT A REAL non c'entra assolutamente nulla, perché il dato è già in formato REAL.

Link al commento
Condividi su altri siti

Se carico delle mele su un camion, non è che quando arrivano a destinazione sono diventate delle pere.
Ben per dirla tutta, questo Real / Mela è fatto da Bit / (Molecole/Atomi/Quark etc)
Se prendi le Mele e le mosti le pesti le rovini ci fai quello che ti piace.
Cosa arrivera alla Fine ?
Cosi quando Arrivano non sono più mele, Vero ?
Sono Bits, sono words, sono Bo ?
Se Sapevi che all' inizio erano mele, devi, se sei bravo ricomporle, Vero ?
Come le Ricomponi ?
Le Lasci cosi come Mosto ? (Cioè sono la stessa Cosa, Sono si di Materia)
Bene cosi se le ricompongo Male potrei anche ottenere Pere (Cioè DINT)
e no Mele (Cioè REAL), oppure Banane(Cioè Nibble), o Fragole (cioè INT)
Chiaro vero ?
L'operazione di Ricomposizione non è il Mosto (cioè DINT o INT, Bits o Nibble)
Ma ricompore significa (Convertire o assemblare il Mosto in Mele)
in Soldoni con la procedura Dint_to_Real si va questo.
In Rockwell si usa per fare questo, l'istruzione COP o CPS.
Non mi dire che dal mosto, non posso più ritornare ad avere le Mele iniziali !
Noi ricomponiamo tutto anche dai Quark le Mele, basta sapere come si fa.
Come ti ho già detto un Elemento REAL nel Modo Logix, è un elemento non scomponibile in bits o words o altro.
Almeno se non si usa la tecnica di Fonderlo o scompore con l'istruzione COP/CPS.
In Siemens puoi farlo, ma QUI NO.
Anche in Matematica se ho una fragola e ne aggiungo un altra, ottengo
solamente 2 Fragole,
Non ottengo sicuramente una Mela.
Questo è il motivo !
come avevano già detto MrCtnJ
"Il tuo problema penso sia dovuto al fatto che lo strumento fornisce un REAL ma al PLC arrivano 2 INT, anche accoppiandoli in un DINT pur essendo 32 bit non ha nulla a che vedere con un REAL composto da segno+esponente+mantissa"
Oppure come aveva già detto Mamic
"Sarebbe bene avere le due word da 16bit in due elementi consecutivi in un array di INT (Esempio Valore[0] e Valore[1])
poi esegui la COP in un variabile Real (Esempio VarReal)"
Io ho voluto Aiutare semplicemente Salsi, e se conosco come si fa,
non penso aver commesso un peccato.
l 'ambiente Rockwell lo conosco da molti anni e
Ma sembra che si debba trovare la pulce in .....
Link al commento
Condividi su altri siti

La conversione da DINT A REAL non c'entra assolutamente nulla, perché il dato è già in formato REAL.

Invece ti ho già detto che un Elemento DINT (anche se hai la medesima disposizione dei Bits o sequenza),

non è la stessa cosa di un Elemento REAL

Infatti il Dato DINT Rappresentato in Formato Big-Indian vale 1150963712

lo Stesso DINT dovrà essere convertito con lo SWPB in Formato Litle-Indian nel valore 5282372

Cosi a Casa Mia il valore 5282372 sarebbe per te 1234.5 ?

Una Variabile a 32Bits DINT in Ambiente Logix non è un REAL !
Anche in Siemens quando usi l'aritmetica in formato float-point o Real, devi
Specificare di usare elementi Real, per far questo se hai un elemento DINT
e vuoi mantenere il Significato in esso contenuto, devi usare una Castomizzazione
con l'istruzione DTR (AWL) Dint_to_Real (SCL)
Se invece prendi la tua Variabile e ti dimentichi di eseguire l'istruzione DTR,
ottieni un errore, oppure un risultato non voluto.
A Casa Mia, e in molti linguaggi software.
Quando faccio ad esempio una Moltiplicazione tra due elementi si deve specificare che tipo di elementi sono.
Ti faccio l'esempio in Siemens
1° Esempio
Elemento A : Real; // Dato trasmesso dallo strumento 1234.5 Watts (Esempio DB100.DBD 200)
Elemento B: Real; // Dato Coefficiente 0.234 Tariffa (Esempio DB100.DBD 204)
Risultato C: Real; // Risultato della Moltiplicazione A*B
L DB100.DBD 200 // Dato A
L DB100.DBD 204 // Dato B
*R
T DB100.DBD 208 // Moltiplicazione A*B
C := A*B; // Risultato := 288.873 (Risultato Corretto)
2° Esempio
Elemento A : DINT; // Dato trasmesso dallo strumento 1150963712
Elemento B: Real; // Dato Coefficiente 0.234 Tariffa
Risultato C: Real; // Risultato della Moltiplicazione A*B
L DB100.DBD 200 // Dato A
L DB100.DBD 204 // Dato B
*R
T DB100.DBD 208 // Moltiplicazione A*B
C := A*B; // Risultato := 269325508.608 (Risultato non Corretto)
il Modo corretto nel secondo caso sarà di trasformare il Tuo valore da 1150963712 in 1234.5
con un istruzione di Trasferimento da un Elemento DINT in un Elemento REAL
In Ambiente Logix ti allego un Immagine che di mostra cosa significa.
Modificato: da Henon
Link al commento
Condividi su altri siti

Allego immagine di esempio:post-10180-0-62333900-1370733298_thumb.j.JPG]

1st Rung (Emulo il trasferimento attraverso ModBus TCP del dato inviato dallo Strumento)

2nd Rung (Eseguo la corretta Trasformazione SWPB, ed in seguito eseguo la Castomizzazione CPS) Successivamente di Mostro un Esempio di Moltiplicazione

3rd Rung (Operazione non Corretta di Uso del DINT "Data_Recive_TR" e usato nudo è crudo, e trasferito nel Real "Element_A1"

Come vedi nel Rung 3, il risultato finale non è quello corretto.

Perciò ti sembra che il Valore di "Element_A" sia lo stesso di "Element_A1" ?

Modificato: da Henon
Link al commento
Condividi su altri siti

Una REAL a 32 bit è composta da 32 bit. Come fai, quindi, ad affermare che una REAL non può essere scomposta in 32 bit?

Devo solo trasportare i 32 bit, mantenendo lo stesso ordine, dal punto A al punto B, e interpretarli nello stesso modo in cui erano interpretati all'origine.

Link al commento
Condividi su altri siti

Ciao,

concordo con Batta dal punto di vista logico.

In ogni caso per risolvere ecco una semplice add-on:

immagineap.jpg

Input1 e Input2 sono i due interi in arrivo dal ModbusTCP, INTERI è un INT[2], DINT è un DINT e il risultato OUTPUT è un REAL. Io l'ho fatto su Modbus TCP per i Float (IEEE754 Single precision 32-bit) e una logica diversa per i double a 64 bit.

Ciao

Modificato: da unicleid
Link al commento
Condividi su altri siti

Vedi che anche tu alla fine hai usato l' istruzione COP, per customizzare il Dato !

Perchè non hai fatto un MOV DINT to REAL ?

Poi ti sei dimenticato di Invertire anche i Bytes delle 2 INT, hai fatto giusto solo l'inversione delle 2 INT per formare la DINT.

Link al commento
Condividi su altri siti

in Soldoni con la procedura Dint_to_Real si va questo.
In Rockwell si usa per fare questo, l'istruzione COP o CPS.

Sono andato a controllare sul manuale del Logix5000 cosa fanno le istruzioni COP e CPS e, se non ho capito male, fanno solo una copia delle variabili, ma non fanno conversioni.

Se è così, l'istruzione COP (o CPS) viene usata solo per copiare una variabile dichiarata come DINT in una dichiarata come REAL.

E, se è così, l'istruzione è corretta proprio perché non fa quello che dici, ovvero non fa la conversione da DINT a REAL, ma prende i 32 bit di una variabile dichiarata come DINT e li copia pari pari in una variabile dichiarata come REAL.

Ripeto: questa è una copia, non una conversione!!!

Come ti ho già detto un Elemento REAL nel Modo Logix, è un elemento non scomponibile in bits o words o altro.

Il fatto che nel mondo Logix non sia (e permettimi di aggiungere un purtroppo) facile accedere direttamente ai singoli bit di una variabile dichiarata come REAL, non significa che questa variabile non sia composta da 32 bit.

Anche in Siemens quando usi l'aritmetica in formato float-point o Real, devi
Specificare di usare elementi Real, per far questo se hai un elemento DINT
e vuoi mantenere il Significato in esso contenuto, devi usare una Castomizzazione
con l'istruzione DTR (AWL) Dint_to_Real (SCL)
Se invece prendi la tua Variabile e ti dimentichi di eseguire l'istruzione DTR,
ottieni un errore, oppure un risultato non voluto.

Continui a confondere quello che è la conversione di un dato (indispensabile per sommare mele con mele e pere con pere) da quello che è il semplice trasferimento di un dato.

In questo caso io devo solo trasportare un dato. Come lo faccio, non importa a nessuno. L'unica cosa che conta è che non devo alterare il dato. E, per non alterare il dato, devo tassativamente non fare conversioni.

Ripeto: il tuo esempio probabilmente funziona perché con l'istruzione COP fai solo una copia pura da un'area di memoria ad un'altra, ma non fai conversioni.

Anche nel tup post #9 scrivi:

CPS(AuxDINT,DestReal,1)

che è diverso dallo scrivere:

DestReal := AuxDINT ;

Infatti, nel primo caso copi ma non converti, nel secondo caso faresti anche una conversione (che nel Logix5000 è implicita).

Per sempio, uno dei modi nei quali potrei fare la stessa cosa in Siemens, è il seguente:

      L     #VarInt1               // 0000_449A Hex
      SLD   16                     // 449A_0000 Hex
      L     #VarInt2               // 0000_5000 Hex
      OD                           // 449A_5000 Hex
//      TAD                        // Da fare solo per conversione little-endian/big-endian
      T     #VarReal               // 449A_5000 Hex, che corrisponde a 1234.5 Real

(E, per fortuna, che Rockwell è semplice e Siemens è complicato ;)).

Se dopo l'istruzione OD mettessi anche l'istruzione DTR, commetterei un grave errore.

Modificato: da batta
Link al commento
Condividi su altri siti

Crea un account o accedi per commentare

Devi essere un utente per poter lasciare un commento

Crea un account

Registrati per un nuovo account nella nostra comunità. è facile!

Registra un nuovo account

Accedi

Hai già un account? Accedi qui.

Accedi ora
×
×
  • Crea nuovo/a...