Step 7 Rechnen mit 32bit UInt

R

roman06

Level-1
Beiträge
151
Reaktionspunkte
17
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo,

versuche verzweifelt in STEP 7 irgendwie eine 32 Bit unsigned integer Berechnung hinzubekommen.
Hintergrund: habe einen fortlaufenden Zähler UInt32 (über Bus). Er läuft leider wirklich bis Max UInt32 (und dann über). Aufgabe ist aus zwei Werten die Differenz berechnen, -> Position/Weg. Gibt es dafür irgendeinen Trick?
In SCL bekomme ich beim Rechnen mit DWORD natürlich immer Mecker, ein cast macht aber dann auch nicht das gewünschte, AWL auch nicht ... Mit Wandlung nach Real bekomme ich für z.B. 0xFFFFFFFF dann auch ne "-1" oder "-1.QNAN". Real wäre wahrscheinlich aber sowieso nicht "breit genug"...
Ich weiß nicht weiter (bin zu doof) :confused:

Hilfe?

Danke,
Roman
 
Ich denke du wirst nicht darum herumkommen das als dword einzulesen. Dann auf zwei DINT zu verteilen. Wenn du rechnen willst musst du dir eine Funktion schreiben die mit je zwei DINT pro Operator rechnet.
Grundsätzlich alles möglich. Man muss sich wohl ein paar Gedanken machen um die Grundrechenarten so abzubilden. Nur schon das wandeln dieser UDINT zahl in zwei DINT wird schon recht kniffliges Bitgeschubse. Hab ich noch nie gemacht aber hätte da ideen wie man das angehen könnte.
Darstellen lässt sich die Zahl dann wohl nur korrekt in einem String.
Aber anders gefragt, was zählt dieser riesige Zähler? Könntest du die Zahl vielleicht etwas runterskalieren?
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Die S7-300/400 unterstützt von Haus aus keine Unsigned-Ganzahlberechnung da es nur die I- und D-Befehle gibt. Bei 1200/1500 geht das mittlerweile.
Ein einfacher Größenvergleich von 2 Werten sollte aber nicht allzu schwer sein.

Bei den beiden Werten zuerst das Bit 31 ausmaskieren und diese Bits im ersten Schritt prüfen.
Ist Bit31 bei einer Zahl gesetzt und bei der anderen nicht, dann ist erstere größer. Sind beide Bits gleich, geht man in den zweiten Schritt.
Dazu vergleichst du dann einfach die beiden Zahlen mit Bit 31 ausmaskiert (Bits 0-30) mit dem Standardbefehl >D.
Das könnte man in schön in einer Funktion umsetzen können.

Man könnte auch mit Real arbeiten. Wäre aber wohl nicht genau genug.
Zum wandeln muss man ebenfalls zuerst Bit 31 ausmaskieren, in Real wandeln und dann je nachdem ob Bit 31 gesetzt war oder nicht, 2147483648.0 aufaddieren.
 
Zuletzt bearbeitet:
Zuviel Werbung?
-> Hier kostenlos registrieren
tz, tz, tz das ist doch hier kein Spaß-Thread :ROFLMAO:

Im Ernst: Hab es jetzt so gemacht wie von RONIN vorgeschlagen, mit REAL. Ob die Ungenauigkeit Probleme macht, muss ich erst sehen.
@van: der Hinweis auf "Binär für Dummies" war wahrscheinlich gut gemeint, aber ... :)
 
Genau, Roman!
roman06 schrieb:
... das ist doch hier kein Spaß-Thread ...
Zum Vergrößern anklicken....
Arbeit macht zwar Spass, aber was können wir schliesslich dafür, dass wir keinen Spass vertragen!?
Also, Spass beiseite und Ernst auf'n Tisch!
roman06 schrieb:
... Aufgabe ist aus zwei Werten die Differenz berechnen, -> Position/Weg ...
Zum Vergrößern anklicken....
Angenommen, Du hast die Einheit "Müh" (ich traue mich nicht, direkt den griechischen KleinBuchstaben ähnlichen Namens einzutippen, weil dieser Editor allergisch darauf reagiert - warum eigentlich?), also Tausendstel mm, dann reichen 31 Bit für über 2 km bzw. bei "DINT mit ohne U" für reichlich -2 km bis + 2 km.
Hatte bei FräsMaschinen mit X-Achsen von bis zu 70 m zu tun. Aber das sind immerhin PeaNuts im Vergleich zu 2 km.
Bin beeindruckt, aber frage mich "wofür brauchst Du?"
Könnte es nicht doch eine Möglichkeit geben, den Hebel viel früher anzusetzen, damit die Zahlen in DINT nicht ausufern? Wenn der Schritt zu REAL kein Thema sein sollte, kann der grosse GenauigkeitsVerlust Dich doch nicht davon abhalten, einen kleinen GenauigkeitsVerlust an einer anderen Stelle hinzunehmen, so dass Du gar nicht erst mit diesen MonsterZahlen hantieren musst.
Was heisst "Ob die Ungenauigkeit Probleme macht, muss ich erst sehen."? Kann man das denn nicht über den Daumen peilen? Was grenzt Dich denn ein?
Gruss, Heinileini
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Heinileini schrieb:
damit die Zahlen in DINT nicht ausufern? Wenn der Schritt zu REAL kein Thema sein sollte, kann der grosse GenauigkeitsVerlust Dich doch nicht davon abhalten, einen kleinen GenauigkeitsVerlust an einer anderen Stelle hinzunehmen
Zum Vergrößern anklicken....
Zumal die Genauigkeit von REAL mit nur 23 Bit nicht nur ein wenig sondern deutlich unter der von DINT mit 31 Bit liegt.
 
hucki schrieb:
Test: µµµµµµµµµµµµµµµµµµµµµµµµµµµµµµµ
Zum Vergrößern anklicken....
Danke hucki, dass Du Dir soviel µ-he gemacht hast!
hucki schrieb:
Meiner nimmt das ganz normal an.
Zum Vergrößern anklicken....
Können wir tauschen? ;o)


Aus der ZwischenAblage kann ich µ hier einfügen - wie ich gerade probiert habe. Aber das Ding in diesem Editor über die Tastatur eingeben geht bei mir nicht.
Das Zeichen erscheint nicht auf dem Bildschirm - das ist die gute Nachricht und jetzt kommt die schlechte: alles andere, µ-sam Eingetippte verschwindet vom Bildschirm!
Sollte es in Wirklichkeit mein edge sein, das beim Anblick von µ ausflippt?
 
Ich hab doch schon Feierabend, aber, hey jetzt wird es doch noch ein Spaß Thread :p
Das gefällt mµr gar nicht, oder doch ¿

Aber jetzt wieder Ernst: :cool: Der Wert kommt einfach so über Bus ich kann daran NICHTS ändern, basta. Oder glaubt jemand, ich hätte mir das so gewünscht? In meinem jugendlichen Leichtsinn dachte ich, 32bit, kein Problem, aber Pustekuchen.

hucki schrieb:
Zumal die Genauigkeit von REAL mit nur 23 Bit nicht nur ein wenig sondern deutlich unter der von DINT mit 31 Bit liegt.
Zum Vergrößern anklicken....

Naja, wir sprechen hier über die Genauigkeit der Wandlung von µ (ich kanns nicht lassen) in REAL. Die sollte da bei max 256 liegen...

Allen ein schönes WE, macht nicht mehr zu lange:)
 
Zuviel Werbung?
-> Hier kostenlos registrieren
roman06 schrieb:
.. Hintergrund: habe einen fortlaufenden Zähler UInt32 (über Bus). Er läuft leider wirklich bis Max UInt32 (und dann über). Aufgabe ist aus zwei Werten die Differenz berechnen, -> Position/Weg. Gibt es dafür irgendeinen Trick? ..
Zum Vergrößern anklicken....
Dazu fällt mir doch tatsächlich noch eine intelligente Frage ein. Wenn das, wie du sagst, ein fortlaufender Zähler ist, dann wird die zu bildende Differenz vermutlich einen vergleichsweise sehr kleinen Wert annehmen? Also, das Ergebnis belegt deutlich weniger als 31 oder 32 Bit? Ist das so?
 
Moin Roman!
roman06 schrieb:
... Der Wert kommt einfach so über Bus ich kann daran NICHTS ändern, basta.
... In meinem jugendlichen Leichtsinn dachte ich, 32bit, kein Problem ...
Zum Vergrößern anklicken....
Aber Du kannst eingreifen, sobald die 32 Bit aus dem Bus ausgestiegen sind, behaupte ich mal in dem, was von meinem jugendlichen Leichtsinn übrig geblieben ist. Das war und ist ja wohl der Gegenstand dieses Thread.
Kannst Du denn davon ausgehen, dass die 32 Bit vor dem Einsteigen in den Bus eine positive Zahl darstellen, die weder am most significant noch am least significant Ende gekappt ist?
Will sagen, dass Deine 32 Bit nicht nur rein formal, sondern auch inhaltlich ein UDINT darstellen?
Dann schieben wir sie doch um eine BitPosition nach rechts, löschen vorsichtshalber das höchstwertige Bit, und beschliessen, dass wir jetzt ein DINT mit halber Genauigkeit vorliegen haben (2 µm Auflösung).
Da kannst Du nach HerzensLust subtrahieren!
Wenn aber der Engpass im 32 Bit BusTransfer besteht, dann musst Du wohl oder übel doch dort etwas ändern lassen, wo Du selbst nichts ändern kannst!
Häwenaissuiikend!
 
Zuviel Werbung?
-> Hier kostenlos registrieren
roman06 schrieb:
Der Wert kommt einfach so über Bus ich kann daran NICHTS ändern,
Zum Vergrößern anklicken....
Wenn Du Deinen UDINT?-Wert um ein Bit nach rechts verschiebst, kannst Du mit DINT rechnen und hast 'ne Genauigkeit von ±2^0=±1 gegenüber der Umwandlung in Real von ±2^7 = ±128, die Du jeweils verlierst.


UINT aus Deiner Überschrift hat übrigens nur 16 Bit nicht 32. Da könnte man einfach WORD in DWORD und dann in DINT wandeln.
Also welche Deiner beiden Angaben ist eigentlich korrekt? UINT oder 32 Bit, sprich UDINT?
 
Zuletzt bearbeitet:
roman06 schrieb:
Ich hab doch schon Feierabend, aber, hey jetzt wird es doch noch ein Spaß Thread :p ..
Zum Vergrößern anklicken....
In der Tat, man kommt aus dem Lachen kaum noch raus :ROFLMAO: . Wenn einem nur nicht immer der Feierabend den Spaß verderben würde :-? .

Einfach nur die Differenz bilden. Man muss man nicht einmal den Überlauf berücksichtigen.
 
Zuletzt bearbeitet:
Ich glaube, der TE hat nur Angst wegen dem 32-Bit-Überlauf, doch den kann er auch mit UDINT-Berechnungen nicht verhindern - und vermutlich ist das auch gar nicht nötig.
Wie groß kann denn die Differenz bzw Wegstrecke maximal werden?

Harald
 
Zurück
Oben