Zuviel Werbung? - > Hier kostenlos beim SPS-Forum registrieren

Seite 1 von 2 12 LetzteLetzte
Ergebnis 1 bis 10 von 11

Thema: Probleme mit Realwertdarstellung

  1. #1
    Registriert seit
    21.05.2005
    Beiträge
    7
    Danke
    0
    Erhielt 0 Danke für 0 Beiträge

    Unglücklich


    Zuviel Werbung?
    -> Hier kostenlos registrieren
    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)
    Zitieren Zitieren Probleme mit Realwertdarstellung  

  2. #2
    Registriert seit
    30.08.2006
    Beiträge
    18
    Danke
    0
    Erhielt 0 Danke für 0 Beiträge

    Standard

    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
    Zitieren Zitieren Das Problem liegt wahrscheinlich im DINT  

  3. #3
    wireboy ist offline Neuer Benutzer
    Themenstarter
    Registriert seit
    21.05.2005
    Beiträge
    7
    Danke
    0
    Erhielt 0 Danke für 0 Beiträge

    Standard

    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
    Zitieren Zitieren RE: RE: Realwertprobleme  

  4. #4
    Registriert seit
    30.08.2006
    Beiträge
    18
    Danke
    0
    Erhielt 0 Danke für 0 Beiträge

    Standard

    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"
    Zitieren Zitieren Real Zahl  

  5. #5
    wireboy ist offline Neuer Benutzer
    Themenstarter
    Registriert seit
    21.05.2005
    Beiträge
    7
    Danke
    0
    Erhielt 0 Danke für 0 Beiträge

    Standard

    Hi Eckart,

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

    Michael
    Zitieren Zitieren RE: Realzahl  

  6. #6
    Registriert seit
    15.01.2005
    Ort
    In der Mitte zwischen Bayreuth/Weiden
    Beiträge
    6.732
    Danke
    314
    Erhielt 1.519 Danke für 1.282 Beiträge

    Standard

    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
    Warum denn einfach, wenn man auch Siemens einsetzen kann!

    Wer die grundlegenden Freiheiten aufgibt, um vorübergehend ein wenig Sicherheit zu bekommen, verdient weder Freiheit noch Sicherheit (B. Franklin).

  7. #7
    wireboy ist offline Neuer Benutzer
    Themenstarter
    Registriert seit
    21.05.2005
    Beiträge
    7
    Danke
    0
    Erhielt 0 Danke für 0 Beiträge

    Standard

    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
    Zitieren Zitieren Re: Re: Realzahl  

  8. #8
    wireboy ist offline Neuer Benutzer
    Themenstarter
    Registriert seit
    21.05.2005
    Beiträge
    7
    Danke
    0
    Erhielt 0 Danke für 0 Beiträge

    Standard

    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
    Zitieren Zitieren RE: RE: Realzahl  

  9. #9
    Registriert seit
    30.08.2006
    Beiträge
    18
    Danke
    0
    Erhielt 0 Danke für 0 Beiträge

    Standard

    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
    Zitieren Zitieren vielleicht negativen Weg  

  10. #10
    wireboy ist offline Neuer Benutzer
    Themenstarter
    Registriert seit
    21.05.2005
    Beiträge
    7
    Danke
    0
    Erhielt 0 Danke für 0 Beiträge

    Standard


    Zuviel Werbung?
    -> Hier kostenlos registrieren
    Hallo Eckart,

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

    Michael

Ähnliche Themen

  1. Bus Probleme
    Von KR-TKD im Forum Feldbusse
    Antworten: 7
    Letzter Beitrag: 15.06.2011, 16:37
  2. Probleme AWL
    Von Geminon im Forum CODESYS und IEC61131
    Antworten: 9
    Letzter Beitrag: 14.07.2010, 09:53
  3. Probleme über Probleme!
    Von tom_2802 im Forum Simatic
    Antworten: 25
    Letzter Beitrag: 12.06.2008, 22:19
  4. FI-Probleme
    Von mectron im Forum Schaltschrankbau
    Antworten: 15
    Letzter Beitrag: 11.02.2007, 13:29
  5. Probleme mit CPU 102 S5
    Von lorenz2512 im Forum Simatic
    Antworten: 4
    Letzter Beitrag: 27.01.2006, 04:44

Lesezeichen

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •