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

Page 1 of 2 12 LastLast
Results 1 to 10 of 13

Thread: Generierung Dezimalbruch (Zähler / Nenner) (DINT) aus LREAL

  1. #1
    Join Date
    06.08.2010
    Location
    Köln
    Posts
    350
    Danke
    20
    Erhielt 75 Danke für 47 Beiträge

    Default


    Zuviel Werbung?
    -> Hier kostenlos registrieren
    Hallo...,
    Ich brauche aktuell eine Umrechnung einer LReal Zahl in Zähler und Nenner.

    Die Umrechnung wird für die Angabe des Gleichlaufes im Motion-Control gebraucht und muss alle 50-100 ms neu berechnet werden.

    Aus der Trigonometrie erhalte ich einen Übersetzungsfaktor in Lreal...

    Der Bruch muss möglichst genau sein und über einen großen Bereich funktionieren.

    Hat da jemand einen brauchbaren Ansatz?
    Reply With Quote Reply With Quote Generierung Dezimalbruch (Zähler / Nenner) (DINT) aus LREAL  

  2. #2
    Join Date
    22.04.2019
    Posts
    49
    Danke
    28
    Erhielt 1 Danke für 1 Beitrag

    Default

    Hallo!

    Nur als Gedankenanstoß:

    Gruß von Björn
    Mir fällt kein schlauer Spruch ein ...

  3. #3
    Join Date
    22.04.2019
    Posts
    49
    Danke
    28
    Erhielt 1 Danke für 1 Beitrag

    Default

    Ich habe das mal schnell so umgesetzt, also hingepfuscht und es geht auch mit nichtperiodischen Dezimalzahlen:

    "Werte".Wert_links := "Werte".Wert_rechts := "Werte".Eingabe;
    "Werte".Wert_links_9 := "Werte".Eingabe * 9;
    "Werte".Wert_rechts := "Werte".Eingabe * 10;
    "Werte".Wert_rechts := "Werte".Wert_rechts - "Werte".Eingabe;
    "Werte".Teiler_9 := 9; // hier wollte ich eigentlich weiter kürzen, wenn möglich und "Werte".Teiler_9 wird dazu evtl. gebraucht, aber das Suchen nach math. Funktionen in der TIA-Hilfe habe ich noch nicht geschafft.

    So oder so:
    Der Zähler ist dann "Werte".Wert_rechts und der Nenner ist 9. Wenn Dir das ohne das Kürzen etwas nützt, ...

    Dezimalzahl_in_Bruch.jpg
    Mir fällt kein schlauer Spruch ein ...

  4. #4
    Join Date
    29.03.2004
    Posts
    6,623
    Danke
    161
    Erhielt 2,014 Danke für 1,431 Beiträge

    Default

    Bei einer Gleitkommazahl in IEE 754 Darstellung lässt sich der Bruch direkt aus den einzelnen Bits von Exponent und Mantisse ableiten.

    Ich habs grad mal auf einem Blatt Papier für die 32-Bit Gleitkomma durchprobiert. Bei 64 Bit musst du den Biaswert anpassen.


    1. Beispiel: 6.75

    Exponent: B#1#10000001 = 129 -> abzügl. Biaswert 127 = 129-127 = 2
    Mantisse: B#1#10110...

    1 vor die Mantisse weil normalisiert = 1,1011
    Komma um Exponent Stellen nach rechts = 110,11
    Kleinstes gesetztes Bit hinter dem Komma besitzt die Wertigkeit 2^(-2), dementsprechend Nenner = 4
    Gesamtes Bitmuster 11011 = dez 27 ist der Zähler
    Gesamt: 27/4


    2. Beispiel: 27.5

    Exponent: B#1#10000011 = 131 -> abzügl. Biaswert 127 = 131-127 = 4
    Mantisse: B#1#101110...

    1 vor die Mantisse stellen weil normalisiert = 1,10111
    Komma um Exponent Stellen nach rechts = 11011,1
    Kleinstes gesetztes Bit hinter dem Komma besitzt die Wertigkeit 2^(-1), dementsprechend Nenner = 2
    Gesamtes Bitmuster 110111= dez 55 ist der Zähler
    Gesamt: 55/2
    Die Genialität einer Konstruktion liegt in ihrer Einfachheit – Kompliziert bauen kann jeder.

    (Sergei Pawlowitsch Koroljow, sowjetischer Konstrukteur von Raketen und Weltraumpionier)

  5. Folgende 7 Benutzer sagen Danke zu Thomas_v2.1 für den nützlichen Beitrag:

    Blockmove (16.05.2019),DeltaMikeAir (16.05.2019),NBerger (16.05.2019),Ralle (16.05.2019),RONIN (16.05.2019),row-k (15.05.2019),TP-Inc (18.05.2019)

  6. #5
    Join Date
    22.04.2019
    Posts
    49
    Danke
    28
    Erhielt 1 Danke für 1 Beitrag

    Default

    Dieses Forum ist genial.
    Mir fällt kein schlauer Spruch ein ...

  7. #6
    NBerger's Avatar
    NBerger is online now Erfahrener Benutzer
    Themenstarter
    Join Date
    06.08.2010
    Location
    Köln
    Posts
    350
    Danke
    20
    Erhielt 75 Danke für 47 Beiträge

    Default

    Hier mal meine Lösung auf Basis #4...
    Code:
      REGION Dezimalbruch generieren
                        // Synchronfaktor wandeln in Dezimalbruch
                        #SyncWord := LREAL_TO_LWORD(#SyncFaktor);
                        #Mantisse := LWORD_TO_LINT(SHR(IN := #SyncWord AND 16#F_FFFF_FFFF_FFFF, N := 22)); // Mantisse filtern und begrenzen auf 32 Bit
                        #Mantisse.%X30 := true; // Hidden Bit setzen
                        
                        #Exponent := LWORD_TO_INT(SHR(IN := SHL(IN := #SyncWord.%W3, N := 1), N := 5)) - 1023; // Exponent filtern und korrigieren um Offset
                        
                        IF #Exponent > 30 THEN // Grenzen des Exponentes überwachen und ggf. korrigieren
                            #Exponent := 30;
                        ELSIF #Exponent < -30 THEN
                            #Exponent := -30;
                        END_IF;
                        
                        #Einzelbit := 1;
                        IF #Exponent >= 0 THEN
                            #Numerator := LINT_TO_DINT(#Mantisse);
                            #Denominator := SHL(IN := #Einzelbit, N := (INT_TO_ULINT(30 - #Exponent)));
                        ELSE
                            #Numerator := LINT_TO_DINT(SHR(IN := #Mantisse, N := INT_TO_ULINT(- #Exponent)));
                            #Denominator := SHL(IN := #Einzelbit, N := 30);
                        END_IF;
                        
                        IF #SyncWord.%X63 THEN // +/- Korrigieren im Zähler
                            #Numerator *= -1;
                        END_IF;
                    END_REGION

  8. #7
    Join Date
    29.03.2004
    Posts
    6,623
    Danke
    161
    Erhielt 2,014 Danke für 1,431 Beiträge

    Default

    So ist der Bruch aber ungekürzt. Wenn du z.B. in einer Schleife das niederwertigste Bit in der Mantisse suchst und damit rechnest wie oben beschrieben, dann ist er direkt so weit möglich gekürzt.
    Die Genialität einer Konstruktion liegt in ihrer Einfachheit – Kompliziert bauen kann jeder.

    (Sergei Pawlowitsch Koroljow, sowjetischer Konstrukteur von Raketen und Weltraumpionier)

  9. #8
    NBerger's Avatar
    NBerger is online now Erfahrener Benutzer
    Themenstarter
    Join Date
    06.08.2010
    Location
    Köln
    Posts
    350
    Danke
    20
    Erhielt 75 Danke für 47 Beiträge

    Default

    Ja..., gelobt ist was schnell macht.
    Warum soll ich den lange ein Bit suchen? Das Motion Control wird deshalb nicht schneller.

  10. #9
    Join Date
    22.04.2019
    Posts
    49
    Danke
    28
    Erhielt 1 Danke für 1 Beitrag

    Default

    Das Motion Control wird deshalb nicht schneller.
    Interessant. Weil ich Motion Control noch nicht kenne: Wozu braucht man Zähler und Nenner? Ich kann mir zwar etwas vorstellen, wozu, aber wenn beides mit Bewegung zu tun hat, sind dann nicht gekürzte Werte besser?

    Oder sollte man gar erweitern, für bessere Auflösung? Bin gespannt.
    Last edited by row-k; 16.05.2019 at 16:16. Reason: Noch ein Einfall:
    Mir fällt kein schlauer Spruch ein ...

  11. #10
    Join Date
    25.06.2017
    Location
    Oerlinghausen
    Posts
    1,693
    Danke
    143
    Erhielt 311 Danke für 255 Beiträge

    Default


    Zuviel Werbung?
    -> Hier kostenlos registrieren
    Quote Originally Posted by row-k View Post
    Wozu braucht man Zähler und Nenner? Ich kann mir zwar etwas vorstellen, wozu, aber wenn beides mit Bewegung zu tun hat, sind dann nicht gekürzte Werte besser?
    Wenn's um GetriebeÜber-/Untersetzungen geht, also um Zahnräder, dann drängen sich ganzzahlige Variablen einfach auf, weil die Anzahl Zähne eines Zahnrades - oh Wunder - ebenfalls ganzzahlig ist - egal, ob man die abgebrochen (=halben) Zähne mitzählt oder nicht.
    In Hinblick auf eine möglichst gleichmässige Abnutzung der Zähne wählen die Mechaniker am liebsten teilerfremde Anzahlen Zähne bei ZahnradPaaren.
    GleitKommaZahlen sind aber denkbar ungeeignet, um solche Verhältnisse (über viele Umdrehungen hinweg exakt) in Zahlen abzubilden. Kleinste Ungenauigkeiten summieren sich ganz einfach über etliche Umdrehungen.
    Wenn mit dem Quotient Zähler/Nenner nach n Umdrehungen neu berechnet wird, tritt die kleine Ungenauigkeit erneut auf, basiert dann aber auf korrekten (ganzzahligen) Anzahl Umdrehungen und ganzzahligen ZähneAnzahlen, statt auf einem ständig anwachsenden Fehler aufzubauen, der dann auftritt, wenn das Verhältnis der EingangsDrehzahl zur AusgangsDrehzahl als GKZ zwar ziemlich genau, aber eben nicht ganz genau dargestellt werden kann.

    Gekürzte Werte sind zumindest nicht schlechter. Das Verhältnis Zähler zu Nenner ändert sich schliesslich nicht durch das Kürzen. Unnötig grosse Zahlen durch kleinere zu ersetzen, ist nicht nur angenehmer für das Auge des Betrachters, sondern kann/wird/sollte sich auch auf die Rechenzeit positiv auswirken.

    Gruss, Heinileini

    PS:
    Durch das Erweitern ändert sich ebenfalls nichts am Verhältnis Zähler zu Nenner - nicht einmal die Genauigkeit. Nur die Gefahr ist grösser, dass es bei Berechnungen zu Überläufen kommt.
    Last edited by Heinileini; 16.05.2019 at 23:12.

  12. Folgender Benutzer sagt Danke zu Heinileini für den nützlichen Beitrag:

    row-k (16.05.2019)

Similar Threads

  1. Inbetriebnahme Servo Drehzahl Skalierung Zähler Nenner
    By Softi79 in forum Antriebstechnik
    Replies: 1
    Last Post: 15.10.2018, 08:32
  2. DINT aus Array of Byte
    By Licht9885 in forum CODESYS und IEC61131
    Replies: 1
    Last Post: 13.10.2017, 15:45
  3. Typkonvertierung von DINT zu LREAL (TwinCAT/Beckhoff)
    By tammana in forum CODESYS und IEC61131
    Replies: 5
    Last Post: 04.11.2014, 12:16
  4. Generierung Excel aus WinCC-Projekt
    By dbafreak in forum Simatic
    Replies: 4
    Last Post: 08.09.2009, 09:11
  5. Replies: 1
    Last Post: 02.07.2008, 18:14

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •