TIA HEX-Wert in einem Real Wert darstellen (3 Nachkommastellen)

philipp00

Level-1
Beiträge
250
Reaktionspunkte
0
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo zusammen

Ich hab ein kleines Problem, warscheindlich nicht sehr schwer zu lösen, jedoch komme ich nicht drauf.

Folgende Ausgangslage:
Ich erhalte einen Wert im DWORD format in HEX Schreibweise, dabei hanelt es sich um eine Spannungsangabe (z.B. 5EAB)

Nun sollte dieser Wert in einem Diagramm ausgeben werden, dafür benöige ich die DEZ Schreibweise und einen REAL Wert, da dieser Wert noch mit Nachkommastellen angepasst werden muss, sprich durch 1000 geteilt werden sollte damit der Wert plausibel wird (24.235V).

Hat jemand einen Lösungsansatz?

Gruss

Philipp
 
Aaaaaaargh, nicht schon wieder dieses HEX-Wort in dem Zusammenhang, ich bekomme schon wieder Augenzucken und Schweißausbrüche.
Mann, warum halten sich manche Irrglauben so beständig. Eine Hex-Zahl und eine Dezimalzahl sind ein und das Selbe. Ob Du nun 10, 0A oder X (römische Schreibweise) schreibst ist egal, es ist einfach eine unterschiedliche Art eine Zahl darzustellen, da kann man nichts wandeln.
Allerdings ist wandeln in Deinem Fall dennoch richtig, denn um Nachkommastellen verarbeiten zu können muss der Zahlentyp von Unsigned Double Integer/DWORD in Real gewandelt werden, anschließend kannst Du sie durch 1000.0 (Durch das .0 wird sie als Fließkommazahl "deklariert") teilen, in eine REAL-Variable speichern und im Diagramm anzeigen.
Das Tippen am Handy dauert so lange.

Von irgendwas mit Internetzugang gesendet.
 
Zuletzt bearbeitet:
Danke für eure Hilfe.

Wollte mich nicht falsch ausdrücken, mir ist klar das HEX und DEZ sicht nur von der Schreibweise unterscheided und nicht vom eigentlichen Wert.

Leider bin ich in SCL überhaupt nicht erfahren, kann ich ich nicht den MOVE Baustein dafür nehmen in FUP?
Ich weiss das SCL sinvolller wäre aber momentan fehlt mir etwas die Zeit dafür mich da einzulesen.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
MOVE hilft dir ja nicht wirklich weiter.

Du kannst in FUP den Baustein "CONVERT" nehmen, Eingang ist der aktuelle Variablentyp, Ausgang solltest du REAL wählen. direkt dahinter kannst du dann eine Berechnungsfunktion setzen, also entweder mit 0,001 multiplizieren oder durch 1000 dividieren. Dann hast du deinen Wert.

Den Ausgang des CONVERT-Bausteins und den Eingang des Berechnungsbausteins kannst du mit einer temporären Variable des FCs besetzen.
 
Leider bin ich in SCL überhaupt nicht erfahren, kann ich ich nicht den MOVE Baustein dafür nehmen in FUP?
Nein, MOVE geht nicht und hilft nicht, weil man mit MOVE nur zwischen gleichen Datentypen kopieren kann, Du brauchst hier aber eine Konvertierung von Ganzzahl DINT zu REAL und anschließend die Division durch 1000.0 (oder Multiplikation mit 0.001, ergibt das gleiche Ergebnis)

In FUP/KOP sieht das vermutlich etwa so aus:
Code:
               +--------------+                         +--------+
               |     CONV     |                         |  DIV   |
               | DINT to REAL |                         |  REAL  |
               |              |-------------------------|        |
               |              |                         |        |
"Tag_DINT_In"--|IN         OUT|--#tmp_Real   #tmp_Real--|IN1  OUT|--"Tag_Real_Result"
               +--------------+                 1000.0--|IN2     |
                                                        +--------+


Achtung SCL:
DWORD_TO_REAL ist falsch! weil dabei das Bitmuster 1:1 als REAL übernommen wird, es muß aber eine Konvertierung DINT_TO_REAL sein, weil 16#5EAB = 24235 muß zuerst zu 24235.0 konvertiert werden. In SCL müsste das so aussehen:
Code:
"Tag_Real_Result" := DINT_TO_REAL("Tag_DINT_In") / 1000.0;

Welche CPU und welches TIA hast Du? In neueren TIA soll man in FUP/KOP-Bausteinen einzelne Netzwerke in in SCL einfügen können.

Harald
 
Ich nehme mal an du spielst auf die QUINT4 an.
S7_PowerSupplies_xx Bibliothek

Der Datentyp bei deren DB ist ungünstig gewählt. Der Wert liegt dort mit großer wahrscheinlichket als mV bzw mA vor (nicht bcd codiert). also einfach den Datentyp in DINT ändern.
Das hab ich im post 12 des links auch schon erwähnt.

dann wie pn/dp schrieb
"Tag_Real_Result" := DINT_TO_REAL("Tag_DINT_In") / 1000.0;
 
Zuletzt bearbeitet:
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo zusamme

Danke für eure schnelle Hilfe, hat ganz gut geklappt, habe mich trotzdem mal kurz mit SCL versucht, ist eigentlich noch ganz interessant.
Denke werde dies sobald ich Zeit habe versuchen etwas zu vertiefen.

Umwandlung.JPG
 
Wenn der Eingangswert nicht änderbar als DWORD deklariert ist, obwohl es eigentlich ein DINT ist, dann kann man den Wert zunächst in eine DINT-Variable kopieren und diese Kopie weiterverwenden, oder in SCL so schreiben:
Code:
"Tag_Real_Result" := DINT_TO_REAL( DWORD_TO_DINT("Tag_DWORD_In") ) / 1000.0;

PS: Wenn der Quellcode offen vorliegen würde, dann könnte jeder Fachmann festgestellte Fehler selber korrigieren. Bei mit KNOW_HOW_PROTECT versteckten/geschützten Fehlern kann man das nicht.

Harald
 
Auch wenn der SCL-Compiler Deinen Code nicht anmeckert und "ahnt" und toleriert was Du (und viele andere Programmierer) höchstwahrscheinlich meinen: Gewöhne Dir gleich an, für Gleitkomma-Konstanten auch Gleitkomma-Zahlen hinzuschreiben. In irgendwelchen Konstellationen könnte der Compiler die falsche Schreibweise auch falsch interpretieren.
Also nicht:
Code:
"Resultat" := "Resultat" / [COLOR="#FF0000"]1000[/COLOR];
sondern
Code:
"Resultat" := "Resultat" / 1000.0;

Ganz wichtig! Für Zwischenergebnisse und Mehrfachzuweisungen verwendet man temporäre Variablen. Wenn Du so "variablensparend" Variablen mehrfach Ergebnisse zuweist, dann darf diese für Zwischenergebnisse verwendete Variable keine Variable in der Baustein-IN/OUT-Schnittstelle sein, weil falls die Variable byRef übergeben wird, dann wird dabei schon der externen Variable der Zwischenwert zugewiesen, was bei Multitasking-Prozessen für schwer reproduzierbare und schwer findbare Fehler sorgt. Das gilt auch für mehrfache Direkt-Schreibzugriffe auf Baustein-externe Variablen. Dieser Programmierfehler wird vom SCL-Compiler nicht angemeckert.

Harald
 
Zurück
Oben