Probleme mit Realwertdarstellung

Hallo Leute,

ich habe mir eine Funktion geschrieben, die kontrolliert, ob eine Achse auf einem Sollwert steht oder nicht. Ich übergebe den Sollwert, den Istwert und einen Toleranzwert (alles Realzahlen) und erhalte einen boolschen wert zurück.
Im Baustein werden aus Sollwert und Toleranzwert die lokalen Werte Min und Max gebildet (auch Realzahlen).
Ist der Istwert größer Min und kleiner Max ist der Rückgabewert true sonst false.
Dies hat bis heute immer geklappt.
Heute ist folgendes aufgetreten:
Der Baustein vergleicht zwei Achspositionen (Soll- und Istwert), die er aus zwei verschiedenen DBs erhält (dort sind die Wert auch als Real definiert und belegen 4Byte) .
Aus unerfindlichen Gründen ist der Istwert der Achse nicht mehr mit 0.005 angezeigt, sondern mit -5.86e-6 angezeigt worden und der Baustein funktionierte nicht mehr. Der Sollwert war 0.0 und die Tolleranz 0.5. Also hätte der Baustein für -0.00000586 (die geläufigere Darstellung) ein True zurückliefern müssen.
Der Baustein ist in Kontakplan programmiert und läuft auf einer S7-317-2 DP und ist mit Step7 V5.2+SP1 programmiert worden.
Warum kann ein COMP <=R oder COMP>=R Baustein nicht mit beiden Formaten rechnen? Oder klappt schon die Parameterübergabe beim Funktionsaufruf nicht?
Wenn ich an einen Vergleicherbaustein als Eingabewert 100.0 dranschreibe wird das von Step7 ja auch sofort in 1e2 umgeschrieben.
Oder kann es sein, daß sich das Format dauerhaft umstellt, wenn einmal der Bereich über oder unterschritten wird. Also wird der Istwert einmal 0.00000000123 dann stellt sich das Format darauf ein und bleibt so. Mit der Folge, daß auch die Auflösung geringer wird und Vergleiche auf 0.5 vieleicht nicht mehr möglich sind, sondern nur noch Vergleiche die der aktuellen Auflösung entsprechen.

Bin ein bisschen ratlos

Michael

PS: auf die Istwert habe ich keinen Einfluß. Die kommen via Profibus von einem SEW-Movidrive als Doubleinteger (Anzahl Geberinkremente) mal Weg pro Motorumdrehung durch 4096 (Geberinkremente pro Geberumdrehung)

Das Problem liegt wahrscheinlich im DINT

Hallo,
das Problem liegt wahrscheinlich im DINT format
DoubleInt ist vorzeichenbehaftet. Wandel doch einmal den
Wert in eine RealZahl dann sollte das Problem erledigt sein

Befehl
L Istwert
DTR
T irgendwohin

gruss
Eckart

RE: RE: Realwertprobleme

Hallo Eckart,

den Doubleinteger von SEW wandle ich als erstes in Real und rechne dann mit Weg pro Motorumdrehung durch 4096 die aktuelle Istposition aus.

Wenn der SEW mir 1 rausgibt und der Weg pro Motorumdrehung ist nur 1.25mm durch 4096 ergibt 0,00030517578125mm als Istposition.
Ist die Stellenzahl hinter dem Komma begrenzt? Oder kann man die Begrenzen?
oder wird die automatisch kleiner wenn die Anzahl der Stellen vor dem Komma größer wird?

Michael

Real Zahl

Hi,
die Zahl ist durch die 4 Byte begrenzt
die Darstellung kann man soweit wie ich weis nicht beeinflussen

evtl kannst Du die Nachkommastellen abschneiden "TRUNC"

RE: Realzahl

Hi Eckart,

Du meinst also Realzahl mal 1000 nach Doubleinteger und mit Trunc wieder zurück?

Michael

Wenn du es jetzt ganz genau wissen willst:
http://de.wikipedia.org/wiki/IEEE754

Step7 seinerseits stellt Real immer so dar, das vor dem Komma sich 1 Zahl > 0 befindet.

Allerdings ist das nur eine Darstellung und hat mit der Funktion eines Vergleichers nichts zu tun,
weil das Format siehe den Link oben bleibt ja immer gleich.
Poste wenn möglich deinen Programmausschnitt, oder versuch eine genauere Beschreibung,
weil ich persönlich kann deine Frage nicht nachvollziehen (und die die vor mir geschrieben haben offensichtlich auch nicht)

@Eckart: Mit TRUNC machst du aus einer REAL-Zahl ein DINT:
Beispiel: aus 0,5 wird 0 , aus 1,72 wird 1

Mfg
Manuel

Re: Re: Realzahl

Hallo Leute,

es könnte doch mal Probleme geben. Dies hier habe ich bei Wikipadia gefunden:

Denormalisierte Zahl Ist eine Zahl zu klein, um in normalisierter Form mit dem kleinsten von Null verschiedenen Exponenten gespeichert zu werden, so werden sie als „denormalisierte Zahl“ gespeichert. Ihre Interpretation ist nicht mehr ±1,mantisse·2exponent sondern ±0,mantisse·2de. de ist dabei der Wert des kleinsten „normalen“ Exponenten. Damit lässt sich die Lücke zwischen der kleinsten normalisierten Zahl und Null verkleinern. Denormalisierte Zahlen haben jedoch eine geringere Genauigkeit als normalisierte Zahlen, die Anzahl der signifikanten Stellen in der Mantisse nimmt zur Null hin ab.
Ist das Ergebnis (oder Zwischenergebnis) einer Rechnung kleiner als die kleinste darstellbare Zahl der verwendeten endlichen Arithmetik, so wird es i.A. auf Null gerundet; das nennt man Unterlauf der Gleitkommaarithmetik, englisch Underflow. Da dabei Information verloren geht, versucht man, Unterlauf nach Möglichkeit zu vermeiden. Die denormalisierten Zahlen in IEEE 754 bewirken einen allmählichen Unterlauf (englisch "gradual underflow"), indem „um die 0 herum“ 224 (für single) bzw. 253 (für double) Werte eingefügt werden, die alle denselben absoluten Abstand voneinander haben und ohne diese denormalisierten Werte nicht darstellbar wären, sondern zu Unterlauf führen müssten.Normalisierte Zahl In allen anderen Fällen berechnet sich der Wert v der Zahl als v = (−1)s · (1, m0, m1, m2, …) · 2e0, e1, e2, … −a. Hierbei ist s das Vorzeichenbit, mi sind die Bits der Mantisse und ej die Bits des Exponenten. Der Wert a ist die Abweichung (engl.: bias), die aus der Tabelle oben entnommen werden kann.
Die Mantisse ist im wesentlichen die ersten n wesentlichen Ziffern der Binärdarstellung der normalisierten Zahl. Die erste wesentliche Ziffer ist die höchstwertige (d.h. am weitesten links stehende) Ziffer, die von 0 verschieden ist. Da eine von 0 verschiedene Ziffer im Binärsystem nur eine 1 sein kann, muss diese erste 1 nicht explizit abgespeichert werden; gemäss der Norm IEEE 754 werden nur die folgenden Ziffern gespeichert, die erste Ziffer ist eine implizite Ziffer oder ein implizites Bit (englisch "hidden bit"). Dadurch wird gewissermaßen 1 Bit Speicherplatz „gespart“. Als darstellbarer Zahlenbereich ergibt sich:

• single: ±1,18·10−38 … ±3,40·10+38
• double: ±2,23·10−308 … ±1,80·10+308

Michael

RE: RE: Realzahl

Hallo Leute,

hier mal mein Programm in AWL übersetzt:

Aufruf der Prüfroutine:


[ U(
CALL "Auf_Position"
IrSollPos :="Stat_3_HMI_Dat".Horiz_Pos
IrIstPos :="HMI_Dat_103_M1x".Istpos
IrToleranz:=2.000000e-001
RET_VAL :="MxDummy"
U BIE
)
SPBNB _073
CALL "Auf_Position"
IrSollPos :="Stat_3_HMI_Dat".Horiz_Pos
IrIstPos :="HMI_Dat_103_M2x".Istpos
IrToleranz:=2.000000e-001
RET_VAL :="MxDummy"
_073: U BIE
= #SxLinealinPos
R #SxKette_inPos ]

und wie der Baustein innen arbeitet:

Netzwerk1:

[ U(
L #IrSollPos
L #IrToleranz
+R
T #max
UN OV
SAVE
CLR
U BIE
)
SPBNB _001
L #IrSollPos
L #IrToleranz
-R
T #min
_001: NOP 0
]

Netzwerk2:

[ U(
L #IrIstPos
L #min
>=R
)
U(
L #IrIstPos
L #max
<=R
)
SAVE
]

Gruß

Michael

vielleicht negativen Weg

Hallo Michael,
hast du das Problem in den Griff bekommen?
ich meine das Problem liegt evtl darin, dass dein Vergleicher bei einem negativen Wegwert anders funktioniert als bei einem positiven
kann das sein ? Solange wie die Achse immer im pos Istwegbereich liegt ist alles Io

gruss
Eckart

Hallo Eckart,

ich werde meine Achswerte alle auf zwei Stellen hinter dem Komma runden.
Dann sollte so etwas nicht mehr passieren.

Michael

wireboy schrieb:

Hallo Leute,

es könnte doch mal Probleme geben. Dies hier habe ich bei Wikipadia gefunden:

Denormalisierte Zahl Ist eine Zahl zu klein, ....

Michael

Zum Vergrößern anklicken....

Hallo

Zum Thema denormalisierte Zahlen:

alle SIEMENS S7 400
S7 318 und
SPEED7 CPUs

Können mit denormalisierten Zahlen umgehen.

alle anderen S7 31x CPUs nicht!!


Aber für das aktuelle Problem kommt man noch lange nicht in diesen Bereich!