Conversione Di Un Float Da Siemems

[batta]

Riguardando i vari post mi sono accorto che la soluzione l'aveva già data Mamic nel post #4.

Soluzione funzionante e con descrizione corretta. Infatti Mamic specifica quanto segue:

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.

La soluzione di Henon invece è funzionante, ma basata sull'errata convinzione che l'istruzione COP effettui una customizzazione (o conversione) del dato, simile all'istruzione DTR di Siemens.

[Henon]

Ma ti avevo detto che SWPB esegue adattamento, mentre ti hoi sempre detto che la COP/CPS esegue la Castomizzazione.

Non ho detto altre cose.

la SWPB mette in ordine i Bytes,

Premetto che la SWPB non puoi operare su un REAL.

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

Poi la CPS esegue la Castomizzazione. Chiaro oppure no ?

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

Se devi adattare i due mondi devi sempre fare fatica, perciò o lo fai dalla parte Rockwell questo addattamento oppure sul Siemens.

Perciò se devo passarti dal Rockwell dei dati Float-Point, e anche DINT, Tu allora in Siemens devi armarti di tanta

buona pazienza per eseguire adattamento. e anche tanta fatica.

E ti sei anche guardato che un REAL e solamente un Real, e non puoi leggerlo come singoli Bits o Bytes o Words.

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.

Infatti, ma l'elemento Real è un elemento definito in Memoria del PLC in maniera diversa, da quello definito per un elemento DINT.

Per questo motivo devi eseguire la Customizzazione.

Castomizzazione vuol dire in soldoni adattare, un elemento verso un altro.

Questo modo di fare è obbligatorio.

Adesso ci siamo mesi il cuore in pace o no ?

[max.riservo]

In questo periodo sembra che ci sia il problema di convertire DINT in Real un pò in tutti i forum dei PLC ....

Il concetto lo ha ribadito più volte Batta (anche in altri forum) : il trasferimento dell' informazione E' cosa ben diversa dalla sua interpretazione.

Comunque, visto che continua a non sembrare chiaro provo a dirlo anche io :

Una Word è un array (matrice) di 16 bit, una DWord è una matrice di 32 bit. Se trasferico una DWord (ovvero 32 bit), trasferisco semplicemente una sequenza di 32 bit e delego il significato (dei 32 bit) al programma da dove parte l' informazione e al programma che riceve l' informazione. OVVIAMENTE : se partono 32 bit che sono stati codificati come Real, il programma ricevente riceverà 32 Bit che dovrà interpretare come Real ma, questo non vuol dire che bisogna effettuare una conversione di tipo : BISOGNA semplicemente effettuare una copia (MOVE) di 32 bit da un' area nella quale sono intepretati come DWORD ad un' altra area dove sono intepretati come Real !

Facciamo anche chiarezza sui termini inglesi (a volte italianizzati con la licenza 'poetica') :

- quando si effettua la conversione di tipo di una variabile (ovvero si passa da DINT a Real, da DWORD a DINT, da UINT a Word, etc..) si effettua l' operazione di CAST di una variabile ..... Castomizzare suona tanto male come giumpare, sciftare, deletare & so on

- customizzare (to custom - personalizzare) si usa per tutt' altro ... se poi si vogliono inventare dei neologismi oppure inventare delle nuove accezioni di parole 'italianizzate' si rischia di non farsi capire

[Henon]

Mettiamoci un Sasso sopra.

L'importante che funzioni i termini sono diversi, ma speriamo che ora ci siamo.

Grazie anche a te Max Riservo.

Possiamo dire che si siamo riusciti a fare quello che dovevamo

[batta]

Condivido pienamente tutto quanto detto da Max.

Mettiamoci un Sasso sopra.

L'importante che funzioni i termini sono diversi, ma speriamo che ora ci siamo.

Se vuoi, ci mettiamo una pietra sopra, ma mi dispiace che tu non abbia ancora chiaro fino in fondo in concetto.

In qualche occasione ho citato una delle tante "Leggi di Murphy" che dice: "Se una cosa funziona, non chiederti perché".

Ma va bene solo per fare una battuta.

Nella realtà, capire perché funziona è fondamentale almeno quanto l'averlo fatto funzionare.

Ma ti avevo detto che SWPB esegue adattamento, mentre ti hoi sempre detto che la COP/CPS esegue la Castomizzazione.

Non ho detto altre cose.

la SWPB mette in ordine i Bytes,

Premetto che la SWPB non puoi operare su un REAL.

Invece, qui dimostri di non aver ancora capito perché funziona. Infatti continui a parlare di "castomizzazione" (che solo dopo il post di Max ho capito che partivi da CAST per sfornare quel termine che, personalmente, considero orribile), invece tutto funziona proprio perché l'istruzione COP (idem per CPS) effettua una copia, ma non una operazione di CAST. Prende 32 bit appartenenti a un array di due variabili dichiarate come INT(oppure a una DINT, una REAL, a 4 byte. Non importa a chi e a che cosa appartengano quei 32 bit. Sono 32 bit e basta) e li copia pari pari (senza "castomizzazioni") nei 32 bit che compongono la variabile REAL.

Quello che tu chiami "castomizzazione" verrebbe eseguita, nel Logix, se tu al posto di COP utilizzassi MOVE. E il risultato sarebbe sbagliato.

Quindi...

Poi la CPS esegue la Castomizzazione. Chiaro oppure no ?

No, non è per niente chiaro. Anzi, è proprio sbagliato.

Infatti, ma l'elemento Real è un elemento definito in Memoria del PLC in maniera diversa, da quello definito per un elemento DINT.

Per questo motivo devi eseguire la Customizzazione.

Castomizzazione vuol dire in soldoni adattare, un elemento verso un altro.

Questo modo di fare è obbligatorio.

"Castomizzare", per fortuna, è proprio quello che l'istruzione COP non fa.

Eppure mi pare che Max l'abbia spiegato in poche parole ed in modo chiarissimo.

Forse è per il fatto che nel Logix non si "vedono" i 32 bit che compongono una REAL che sei portato a pensare che una REAL sia qualcosa di così misterioso.

[batta]

Quello che segue è come viene visualizzato il valore di una variabile a 32 bit.

Secondo la scelta del formato, vedi apparire valori diversi. Ma sono sempre gli stessi 32 bit, nello stesso identico ordine.

[Henon]

Se i termini customizzare e Convertire li usi in maniera diversa. l' importate che

devi Usare assolutamente entrambe le istruzioni SWPB e poi CPS,

Non puoi usare o solo la SWPB oppure la sola CPS (come invece riteneva MRjctrl)

la sola CPS non fa il lavoro di traslare la codifica da big-indian in Litle-Indian, questa viene fatta dalla SWPB.

e questo lo devi fare perchè il Dato arriva dal Tuo Modo Siemens dallo strumento .

Qui sopra

Mi stai mostrando la rappresentazione di un elemento della telemeccanique forse ?

Qui l'elemento Real ha solamente 2 modi di essere rappresentato (Decimale o Esponenziale(Scentifico))

Se nel ControLogix dichiaro una tag REAL e la Chiamo come nel tuo Caso MD200, la posso usare solo in Real, non la posso usare

in altra maniera.

Quindi MD200 in ambiente Rockwell può essere 1234.5 oppure 1.2345E^+3

Chiaro.

Non puoi accedere al bit 15 oppure alla word1 di questo elemento.

[Henon]

Quello che segue è come viene visualizzato il valore di una variabile a 32 bit.

Secondo la scelta del formato, vedi apparire valori diversi. Ma sono sempre gli stessi 32 bit, nello stesso identico ordine.

Non importa l'ordine ma il significato, quando ho lo stesso ordine di Bits, ho significati diversi.

Si vede benissimo anche nella tua Tabella.

Poi se invece questi DINT li rappresento come caratteri, hanno per te lo stesso significato ?

500 miglioni trecento ventisette milla (500 327 000) gli elevo alla seconda.

in Real posso farlo, invece se lascio lo stesso ordine di Bits che rappresentano questi numeri in un DINT

e faccio la moltiplicazione ottengo sempre lo stesso risultato ?

So che il significato è diverso dalla codifica che uno usa.

ad esempio di stesso significato , ma di codifica diversa

"Acqua" e "Water" entrambi hanno 5 caratteri e hanno lo stesso significato, ma si scrivano in maniera diversa.

Cosi il significato non dipende se tu hai già formato il tuo giusto ordine di Bits, nel formato REAL.

Ma sottintendere che stiamo parlando di usarlo come REAL.

Se ad un Nepalese gli dico "Acqua" penso che ti potrebbe anche sparare, io non lo so, ma per lui non ha

lo stesso significato che tu intendi.

Oppure fai l' Indiano.

Batta sta per Battagliero vero, non cedi mai .

Ti concedo l'onore delle armi. (Cioè lasciamo perdere che altrimenti ci dilunghiamo e usciamo fuori tema)

Non voglio niente di più, Come ti avevo giù detto volevo solo dare un aiuto e una precisazione.

Poi Batta e Battagliando, ci dilunghiamo per niente.

Ciao.

Modificato: 12 giugno 2013 da Henon

[Henon]

- quando si effettua la conversione di tipo di una variabile (ovvero si passa da DINT a Real, da DWORD a DINT, da UINT a Word, etc..) si effettua l' operazione di CAST di una variabile

Appunto con la CPS passo il dato DINT in un elemento REAL.

da custom = personalizzare

Infatti continui a parlare di "castomizzazione" (che solo dopo il post di Max ho capito che partivi da CAST per sfornare quel termine che, personalmente, considero orribile), invece tutto funziona proprio perché l'istruzione COP (idem per CPS) effettua una copia,

No intendevo adattare l'elemento di memoria da DINT verso un altro elemento di Memoria REAL. (Perciò personalizzo il dato per la destinazione che è un REAL)

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, devotassativamente non fare conversioni.

Tu dimentichi che il Dato è una cosa il significato del dato è un altro.

e Dimentichi che è Già tassativo che bisogna Convertirlo da Big-Indian a Litle-Indian, oppure ci siamo dimenticati che il Formato in Origine dallo Strumento è un

Real in Formato Big-Indian, mentre per il Ricevente deve essere un Formato Litle-Indian.

Riguardando i vari post mi sono accorto che la soluzione l'aveva già data Mamic nel post #4.

Soluzione funzionante e con descrizione corretta. Infatti Mamic specifica quanto segu

Mamic non sapeva che il Dato dallo strumento è in Formato Big-Indian, per questo motivo a detto questo.

Ho molta stima di Mamic perché non dice abitualmente delle fesserie.

In pratica non ci posso fare niente se il Siemens lavora in Formato Big-Indian, e la Rockwell lavora in Formato Litle-Indian.

Perciò sta benedetta Conversione da qualche parte si deve fare.

Se ho Capito bene secondo te Batta

devo fare solamente la COP, ma allora bisognava almeno adattare da Big-Indian a Litle-Indian già alla partenza dalla Parte Siemens.

In questo Modo abbiamo suddiviso il compito:

- Chi Trasmette invia il formato corretto per il Ricevente:

- Chi riceve assimila solo il Dato.

Questo mi sembra più corretto, perché se devo parlare Parlare ad un Inglese devo usare l'inglese, questo è la maniera

anche gentile di esprimersi con la Trasmissione dei dati.

Così quando invio il dato dal PLC Siemens per un PLC ControlLogix, mi preoccupo di parlare nella sua Lingua (Converto o Traduco da Big-Indian a Little-Indian)

Bene quando Il PLC Rockwell riceve il dato non deve preoccuparsi di quale lingua sta parlando, altro. Deve solo passare il dato DINT o comporlo in DINT in un Elemento

che comprende (REAL).

Io per Gentilezza quando faccio questi invio di dati, li faccio sempre nella mia Parte (Rockwell),

Ma sarebbe giusto che ognuno faccia la sua Parte.

Penso in Inglese ma parlo in Italiano con chi è Italiano, perché deve essere giusto cosi.

Se adottiamo questo Concetto Ha ragione Batta, Ma bisogna che lo strumento parli in Rockwell-mode (Little-Indian)

Dimenticavo:

ma se lui lo usa come Slave questo strumento e non c'è nessun PLC che fa da intermediario, per tradurre da Big-Indian a Little-Indian.

Le cose devono essere fatte come avevo già detto io.

Modificato: 12 giugno 2013 da Henon

[batta]

Se i termini customizzare e Convertire li usi in maniera diversa. l' importate che

devi Usare assolutamente entrambe le istruzioni SWPB e poi CPS,

L'importante è capire che col le istruzioni COP e CPS si fa solo una copia da un'area ad un'altra, senza modificare l'ordine dei bit.

Sul fatto poi che si deva o meno fare lo swap dei byte, non ho una risposta sicura. L'ordine dei byte ABCD potrebbe dover diventare DCBA, BADC, CDAB. Per dare una risposta dovrei provare.

Dico questo perché un dispositivo dovrebbe sempre preparare i dati nel modo corretto prima di affidarli al Modbus. Nel Modbus sono quasi sicuro che si usi lo standard Little-Endian. Ma quando leggo un valore via Modbus non mi devo preoccupare della codifica usata dal dispositivo dal quale vado a leggere il dato. Per dire, a me non è mai capitato di dover scambiare i byte di un registro.

In questo caso, visto che i 32 bit vengono divisi su due registri da 16 bit, potrebbe essere (uso il condizionale perché, come già detto, dovrei provare) che i byte ABCD vengano letti via Modbus come BA + DC. Se così fosse, per ricomporre il dato partendo con il byte basso a destra, dovrei solo stare attendo all'ordine in cui metto i due registri.

Ma questo è un problema che si risolve molto facilmente. Basta controllare cosa parte e cosa arriva. Analizzando i valori in esadecimale, ci vuole un secondo per capire come devono essere riordinati i byte.

Mi stai mostrando la rappresentazione di un elemento della telemeccanique forse ?

No, è Siemens, TIA Portal V12.

Se nel ControLogix dichiaro una tag REAL e la Chiamo come nel tuo Caso MD200, la posso usare solo in Real, non la posso usare

in altra maniera.

Lavorare dichiarando solo le variabili senza occuparsi degli indirizzi non è sempre un vantaggio. In questo caso MD200 non è il nome della variabile, ma il suo indirizzo.

Il fatto che il ControlLogix una REAL te la faccia vedere solo come REAL non significa che non sia formata da 32 (oppure da 64 o 128 per doppia e quadrupla precisione) bit.

Non importa l'ordine ma il significato, quando ho lo stesso ordine di Bits, ho significati diversi.

Si vede benissimo anche nella tua Tabella.

È proprio qui la questione. Se facciamo l'esempio con i valori degli esempi precedenti, se nel dispositivo A c'è una variabile REAL che contiene 1234.5 significa che quella variabile è formata dalla sequenza di 32 bit 0100_0100_1001_1010_0101_0000_0000_0000 (449A_5000 Hex, che è molto più comodo). E questo vale anche per Rockwell, anche se, purtroppo, non te lo fa vedere. Leggendo questo dato via Modbus spezzato in due registri da 16 bit, leggerò un registro contenente 449A Hex e uno contenente 5000 Hex.

Devo solo riunire (dopo aver eventualmente riordinato i byte, ma senza fare conversioni) i due registri in modo da trovarmi ancora 449A_5000 Hex. Ed è proprio quello che fai usando COP o CPS. Quando poi il ControlLogix si trova ad interpretare la sequenza 449A_5000 Hex in una variabile dichiarata come REAL, ti fa vedere 1234.5

Poi se invece questi DINT li rappresento come caratteri, hanno per te lo stesso significato ?

Sì. Dipende solo da come li interpreto. Il carattere "A" è 65 in decimale, 41 in esadecimale, 101 in ottale, 01000001 in binario.

500 miglioni trecento ventisette milla (500 327 000) gli elevo alla seconda.

in Real posso farlo, invece se lascio lo stesso ordine di Bits che rappresentano questi numeri in un DINT

e faccio la moltiplicazione ottengo sempre lo stesso risultato ?

In REAL lo puoi fare, ma avrai un risultato approssimato. In ogni caso quel risultato approssimato, visto che stiamo sempre parlando di REAL a precisione singola, sarà sempre contenuto in 32 bit. C'è 1 bit per il segno, 8 bit per l'esponente, 23 bit per la mantissa. Ma sono sempre 32 bit. E, se sono 32 bit, li posso portare dove voglio anche usando un protocollo che mi permette di leggere solo registri da 16 bit. Alla fine ricompongo il dato e mi ritrovo ancora quel 32 bit. Visto che sono esattamente uguali ai 32 bit di partenza, se il dato in partenza, in virgola mobile, era 1234.5, all'arrivo non può che essere ancora 1234.5.

Appunto con la CPS passo il dato DINT in un elemento REAL.

Esatto, passi 32 bit da una variabile che non mi importa in che formato sia, in un'altra variabile che, ancora una volta, non mi importa in che formato sia. Non c'è quindi conversione.

Comunque, il mio intento non è quello di vincere una battaglia, ma di fare chiarezza.

Ma su una cosa ti do pienamente ragione: ci siamo dilungati veramente troppo. Quello che c'era da dire è stato detto.

[max.riservo]

Sul fatto poi che si deva o meno fare lo swap dei byte, non ho una risposta sicura. L'ordine dei byte ABCD potrebbe dover diventare DCBA, BADC, CDAB. Per dare una risposta dovrei provare.

Dico questo perché un dispositivo dovrebbe sempre preparare i dati nel modo corretto prima di affidarli al Modbus. Nel Modbus sono quasi sicuro che si usi lo standard Little-Endian. Ma quando leggo un valore via Modbus non mi devo preoccupare della codifica usata dal dispositivo dal quale vado a leggere il dato. Per dire, a me non è mai capitato di dover scambiare i byte di un registro.

In questo caso, visto che i 32 bit vengono divisi su due registri da 16 bit, potrebbe essere (uso il condizionale perché, come già detto, dovrei provare) che i byte ABCD vengano letti via Modbus come BA + DC. Se così fosse, per ricomporre il dato partendo con il byte basso a destra, dovrei solo stare attendo all'ordine in cui metto i due registri.

Ma questo è un problema che si risolve molto facilmente. Basta controllare cosa parte e cosa arriva. Analizzando i valori in esadecimale, ci vuole un secondo per capire come devono essere riordinati i byte.

A questo posso rispondere io che utilizzo spesso il Modbus : l' unità di misura minima dell' informazione del protocollo Modbus è la Word, ed essendo (la word) gestita come insieme di 2 byte entra in gioco il Little-Endian e il Big-Endian !

Quindi è più che possibile che si debba fare lo SWAP dei byte della Word (e in caso di informazione finale su DWord potrebbe anche essere necessario fare lo SWAP tra Word).