TIA CPU-Bearbeitungszeiten 1516T Lreal oder lieber Real

[Michael Müller]

Zuviel Werbung?
-> Hier kostenlos registrieren

CPU-Bearbeitungszeiten 1516T
für Bitoperationen, typ. 10 ns
für Wortoperationen, typ. 12 ns
für Festpunktarithmetik, typ. 16 ns
für Gleitpunktarithmetik, typ. 64 ns

Die Motionbefehle können Lreal und Real.
Lieber in der CPU mit Real oder Lreal rechnen?
(6 Nachkommastellen reichen mir aus)
Danke,
Michael

 

[Ralle]

Eine Real kann nur 7 Ziffern darstellen, also hättest du bei 6 Nachkommastellen nur noch eine Vorkommastelle. (der Rest würde dann gerundet) Das ist sicher zu wenig, also rechne mit LReal.

Zusatz: Wenn du bei Real 3 Vorkammastellen hast, kannst du noch 4 Nachkommastellen nutzen, der Rest wäre 0, also fehlten dir dann Stelle 5+6 an der Genauigkeit. Wie genau das Ganze in der T-CPU und vom Geber her ist, wäre auch noch eine Frage. Löst der Geber wirklich 6 Nachkommastellen auf?

Wenn du nicht exorbitant viel rechnest, stellt das eher keine Problem für die Zykluszeit der SPS dar.

 

[NBerger]

Zuviel Werbung?
-> Hier kostenlos registrieren

Die 1500'er rechnet von Hause aus (z.B. Motion) intern mit LReal. Wenn du jetzt hier nur mit Real rechnen möchtest, sind immer Formatwandlungen LReal-Real und Real-LReal nötig, was auch zeit benötigt.

Auch werden Konstante Gleitkommawerte im TIA immer als LReal gedeutet, hier müßtest du zusätzlich immer ein Real# voransetzen.
Sowas nerft zum einen einfach, zum anderen würde TIA im LReal rechnen und das Ergebnis wieder in Real wandeln.

Der zeitliche Gewinn dürfte in Summe also recht gering ausfallen.

 

[Michael Müller]

Danke für eure Beiträge.

Da bleibe ich bei LReal.

An den Motion Bausteinen zeigt Tooltip die Möglichkeit der implizierte Datenkonvertierung an....
Die Übertragung von der CPU auf die Sinamic S120 wird im Telegramm Istwert-Geber und Sollwert-Drehzahl in 2x PZD Doppelworten, also 64bit übertragen. Somit ja durchgängig bis unten hin.

 

[Onkel Dagobert]

Die 1500'er rechnet von Hause aus (z.B. Motion) intern mit LReal...

Nur um es nicht falsch zu verstehen, du meinst sicherlich, in den Motion-Bausteinen wird intern mit LReal gerechnet, selbst wenn nur 32-Bit-Real als Parameter übergeben werden? Die 1500er macht das aber hoffentlich nicht generell "von Hause aus"?

 

[hucki]

Zuviel Werbung?
-> Hier kostenlos registrieren

Die 1500er macht das aber hoffentlich nicht generell "von Hause aus"?

Ich meine auch, gelesen zu haben, dass die 1500er das von Haus aus (und nicht nur in Motion) in LREAL macht.

Wäre ja IMHO auch sinnig.
Kann es aber (zumindest momentan) nicht belegen.

 

[Onkel Dagobert]

... Wäre ja IMHO auch sinnig.
Kann es aber (zumindest momentan) nicht belegen.

Das ist in meinen Augen überhaupt nicht sinnig. Da würden auf verschiedenen Maschinen (32Bit und 64Bit) bei gleichen Algorithmus verschiedene Ergebnisse heraus kommen.

 

[NBerger]

auf was für unterschiedlichen Maschienen? Die 1500'er arbeiten alle gleich.

Nach deiner Logik würden wir immernoch auf S5 Niveau arbeiten oder? War ja eh alles besser, oder?

 

[Onkel Dagobert]

Zuviel Werbung?
-> Hier kostenlos registrieren

Ich versuche lediglich, deine Aussage "Die 1500'er rechnet von Hause aus (z.B. Motion) intern mit LReal", richtig zu deuten. Wörtlich genommen, würde die 1500er generell mit LReal rechnen. Die andere Möglichkeit wäre, die Berechnung wird z.Bsp. in den Motion-Funktionen explizit mit LReal ausgeführt. Es können also Real übergeben werden, diese werden in LReal gewandelt, dann erfolgt die Berechnung und anschließend wieder die Wandlung nach Real. So verfahre ich z.Bsp. auch in manch einen Baustein. Das würde auch einen Sinn ergeben. Das ist aber grundsätzlich ein Unterschied zu deiner o.g. Aussage ".. von Hause aus..".