TIA REAL vs INT - Was benutzt ihr für Kommazahlen?

[Staubsauger]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo zusammen,

Zu Beginn: Steuerung ->CPU 1512 SP, TIA 19

Wir haben in unseren Programmen viele Werte mit ein oder zwei Nachkommastellen. Selten auch mal ein Korrekturfaktor o.Ä. mit drei Nachkommastellen. Diese sind mal als REAL, mal als INT ausgeführt. Im Faller eines INT dann eben um den Faktor 10 oder 100 größer als der eigentliche Wert um die Kommastelle zu berücksichtigen.
Das kommt wohl teilweise auch noch aus der Zeit als Fließkommazahlen nicht oder nur schwer verwendbar waren. Die Werte sind eigentlich alles Werte von 0...100 und einige wenige vielleicht von 0...5000. Alles was noch größer wäre ist dann sowieso eine Ganzzahl.

Nun gibt es in unseren Grundprogrammen einen wilden Mischmasch aus beiden Möglichkeiten. Das würde ich gerne bei einer Neuentwicklung abstellen und intern durchgängig auf das selbe Datenformat setzten.

Ich bin eigentlich der Meinung, dass man REALs verwenden sollte. Einfach weil sehr flexibel ist und auch schöner zum beobachten ist.
Meine Kollegen sind da teilweise anderer Meinung, weil es da in der Vergangenheit wohl schon zu Problemen aufgrund der Genauigkeit kam. Diese sind aber meiner Meinung nach dadurch entstanden, dass man einfach die begrenzte Genauigkeit missachtet hat und sich daran stört, dass manche Ergebnisse eben in den Nachkommastellen nicht exakt das erwartete Ergebnis bringen.


Jetzt die Frage an euch: Wie handhabt ihr das?


Edit:

Ein Punkt, den ich ganz vergessen habe, ist die Bearbeitungszeit. Was genau kann ich mir denn unter der Festpunktarithmetik vorstellen. Da gibt es auf der 1500er doch gar keinen Datentyp für, oder?

 

[DCDCDC]

Ich würde mal sagen "kommt drauf an". Schnittstellen zu anderen Systemen haben es vermute ich gerne, wenn ihnen eine Ganzzahl übergeben wird, als eine float.. Weswegen ich auch sagen würde, dass du mit Ganzzahlen die höhere Kompatibilität hast, als mit direkten floats.

Floats sind schön zum anschauen, machen sich auch an Hmi Interfaces ganz schön zum nachvollziehen. Kann ja dann in eine float umgerechnet werden, wenn es benötigt wird.

Falls ihr auch Werte habt im Bereich zB wie von dir genannt 0..100, aber keine Nachkommastellen vorhanden sind, würden sich auch Usint eignen. Die laufen nicht über und können Zahlen von 0..255 darstellen, brauchen nicht so viel Speicherplatz wie andere Ganzzahlen Datentypen

 

[ioStart]

Zuviel Werbung?
-> Hier kostenlos registrieren

ich habe schon viel schlechte Erfahrung mit Kommazahlen gemacht. Daher kommen bei mir nur mehr Ganz-zahlen zum Einsatz. Direkt oder indirekt.
Das letzte Problem trat an einem HMI auf. Ein Panel ging kaputt (Scheibe eingeschlagen). Darauf hin lud ich auf ein neues Gerät das Projekt rauf. Alles gut. Bis auf 2 Ausgabefelder. Hier stimmte die Kommastelle der real-Zahl nicht. Und war auch nicht anpassbar.
Erst als das selbe Prozedere mit einem anderen PG durchgeführt wurde, passte das Ergebnis. (!Wohlgemerkt ohne Änderung am Tia-Projekt)

 

[winnman]

ganz vereinfacht:
Zählwerte müüsen INT (DINT, . . .) sein weil durch div. Rundeungen bei REAL hier sonst ganz schnell blödsinn entsteht.
Messwerte, . . . können REAL sein, hier ist es meist einfacher bzw. weniger Aufwand mit den Kommastellen.

Übergabe an HAMI, andere Systeme: Datenschnittstelle definieren und jede Variable definieren (zB INt Wert = Faktor 100 für 2 Nachkommastellen), . . .

 

[PN/DP]

ich habe schon viel schlechte Erfahrung mit Kommazahlen gemacht. Daher kommen bei mir nur mehr Ganz-zahlen zum Einsatz. Direkt oder indirekt.
Das letzte Problem trat an einem HMI auf. Ein Panel ging kaputt (Scheibe eingeschlagen). Darauf hin lud ich auf ein neues Gerät das Projekt rauf. Alles gut. Bis auf 2 Ausgabefelder. Hier stimmte die Kommastelle der real-Zahl nicht. Und war auch nicht anpassbar.
Erst als das selbe Prozedere mit einem anderen PG durchgeführt wurde, passte das Ergebnis. (!Wohlgemerkt ohne Änderung am Tia-Projekt)

Das liegt aber nicht an den "Kommazahlen", sondern ist ein altbekanntes TIA-Problem. Da hast du vermutlich vor dem Tansfer das Projekt nicht "alles komplett übersetzt".

Meine Kollegen sind da teilweise anderer Meinung, weil es da in der Vergangenheit wohl schon zu Problemen aufgrund der Genauigkeit kam. Diese sind aber meiner Meinung nach dadurch entstanden, dass man einfach die begrenzte Genauigkeit missachtet hat und sich daran stört, dass manche Ergebnisse eben in den Nachkommastellen nicht exakt das erwartete Ergebnis bringen.

Tja, das ist oft eine Bildungslücke, die Gleitpunktzahlen zu verstehen. Oft wird auch sinnfrei versucht, Nachkommaziffern abzuschneiden und speichert dann wieder in REAL - da kommen dann meistens Nachkommastellen wieder, weil man nur relativ wenige Zahlenwerte wirklich mit nur z.B. 2 Nachkommastellen als REAL speichern kann. Oder es wird versucht, sehr kleine Beträge zu relativ dazu sehr goßen Zahlen zu addieren, was bei einem Unterschied von > 10^8 nicht mehr geht, also z.B. X + 0.001 ergibt wieder X.

Ein Punkt, den ich ganz vergessen habe, ist die Bearbeitungszeit. Was genau kann ich mir denn unter der Festpunktarithmetik vorstellen. Da gibt es auf der 1500er doch gar keinen Datentyp für, oder?

doch. Festpunkt = Ganzzahlen. Das sind Zahlen die keinen Dezimalpunkt enthalten, wo aber ggf. an einer festen Position ein Dezimalpunkt vereinbart/festgelegt sein kann, die Position aber nicht mit abgespeichert wird, sondern nur dokumentiert. Deshalb heißen die Festpunktzahlen. Bei Ganzzahlen ist der vereinbarte Dezimalpunkt quasi nach der letzten (Einer-)Ziffer.
Gleitpunktzahlen speichern die fast beliebige Position des Dezimalpunkts "gleitend" mit ab, brauchen dafür aber einige Bits Speicherplatz, die für die Wertcodierung (Mantisse) nicht zur Vefügung stehen. Deshalb haben Gleitpunktzahlen eine geringere Ziffernauflösung als Festpunktzahlen.

 

[NBerger]

Zuviel Werbung?
-> Hier kostenlos registrieren

@ioStart: Das kommt von der Spracheinstellung auf dem Panel (Komma/Punkt) bei Deutsch/Englisch.

Hat mich auch schon nerfen gekostet bis ich mal dahinter gekommen bin...

​

 

[mbi]

Wir haben uns nochmals gegen Gleitpunktzahl/Real entschieden.
Hauptsächlich aus Speicherplatz und Performance Gründen.

Hat aber auch klar seine Nachteile, und man muss auch wissen was man tut.

Richtig aufwendig ist Unified aktuell!
https://support.industry.siemens.co...-mit-dezimalstellen-darstellen?dti=0&lc=de-WW

Wenn wir das oft machen müssten, dann würden wir wohl doch Real nehmen.

 

[hucki]

Da Siemens ja für die Zukunft auf die Unified Panels setzt, machen sie zumindest momentan die Nutzung von Ganzzahlen mit virtuellen Kommastellen noch sehr umständlich.

Statt wie bisher einfach dem Feld sagen zu können, wo ein Komma angezeigt werden soll, muss man umständlich mit Scripten hantieren, um in Float umzurechnen. Bei Ein- und Ausgabe auch gleich noch 2 Stück davon.

 

[TP-Inc]

Zuviel Werbung?
-> Hier kostenlos registrieren

Wir haben alles in REAL aufgezogen. Wahrscheinlich der Einfachheit und Unwissenheit halber. Würde ich unseren Standard jetzt nochmal neu aufziehen würde ich alles was „wichtig“ ist in der kleinsten sinnvollen Einheit verarbeiten und nur zum Schluss gegebenenfalls nach REAL wandeln (Datenbank speichern).

 

[Heinileini]

Hat aber auch klar seine Nachteile, und man muss auch wissen was man tut.

Zu wissen, was man tut, ist doch kein Nachteil, sondern ein Vorteil !!!

 

[maxder2te]

Hallo zusammen,

Zu Beginn: Steuerung ->CPU 1512 SP, TIA 19

Wir haben in unseren Programmen viele Werte mit ein oder zwei Nachkommastellen. Selten auch mal ein Korrekturfaktor o.Ä. mit drei Nachkommastellen. Diese sind mal als REAL, mal als INT ausgeführt. Im Faller eines INT dann eben um den Faktor 10 oder 100 größer als der eigentliche Wert um die Kommastelle zu berücksichtigen.
Das kommt wohl teilweise auch noch aus der Zeit als Fließkommazahlen nicht oder nur schwer verwendbar waren. Die Werte sind eigentlich alles Werte von 0...100 und einige wenige vielleicht von 0...5000. Alles was noch größer wäre ist dann sowieso eine Ganzzahl.

Eine generelle Regelung ist immer schwierig. Float (Real) lehnen viele heute noch immer ab weil die Operationen nominell langsamer sind und weil sie keine Lust haben sich mit Darstellungsbereichen auseinanderzusetzen. Faustregel ist dass Real-Zahlen bis 7 Stellen gut funktionieren, auch mit Rundungsfehlern habe ich kaum schlechte Erfahrungen gemacht.
Faktum ist dass sich gewisse schöne Zahlen in Float nicht darstellen lassen, und dass ein Vergleich auf Gleicheit (z.B. == 0) oftmals nicht möglich ist.

Nun gibt es in unseren Grundprogrammen einen wilden Mischmasch aus beiden Möglichkeiten. Das würde ich gerne bei einer Neuentwicklung abstellen und intern durchgängig auf das selbe Datenformat setzten.

Ich bin eigentlich der Meinung, dass man REALs verwenden sollte. Einfach weil sehr flexibel ist und auch schöner zum beobachten ist.
Meine Kollegen sind da teilweise anderer Meinung, weil es da in der Vergangenheit wohl schon zu Problemen aufgrund der Genauigkeit kam. Diese sind aber meiner Meinung nach dadurch entstanden, dass man einfach die begrenzte Genauigkeit missachtet hat und sich daran stört, dass manche Ergebnisse eben in den Nachkommastellen nicht exakt das erwartete Ergebnis bringen.


Jetzt die Frage an euch: Wie handhabt ihr das?

Ich bin in der Vergangenheit mit folgender Regelung nicht schlecht gefahren:
- Soll- und Istwerte von Prozessen, Antrieben usw. immer als Float.
- Zählwerte als Ganzzahl, zumindest 32 Bit. Darunter fallen z.B. auch Zähnezahlen von Getrieben
- Enumerationen (also diskrete Zustände) als Ganzzahl
- Schnittstellen je nach Anforderungen.

Wichtig bei jedem Zahlenfeld ist, dass aus dem Kommentar die physikalische Einheit drinnen steht. Vor allem bei Schnittstellen ist das essentiell (z.B. LSB = 0.2 U/min oder [0.2 U/min] )

Mit der Einführung von Unified nimmt der Anteil an REAL noch zu, z.B. für Zeitwerte, da das Thema "Lineare Umrechnung" hier mit viel Zusatzarbeit und Fehleranfälligkeit verbunden ist.

Edit:
Anhang anzeigen 80798
Ein Punkt, den ich ganz vergessen habe, ist die Bearbeitungszeit. Was genau kann ich mir denn unter der Festpunktarithmetik vorstellen. Da gibt es auf der 1500er doch gar keinen Datentyp für, oder?

"Festpunktarithmetik" sind alle Operationen mit Ganzzahlen, also z.B. INT * INT, "Gleitpunktarithmetik" ist alles wo Gleitpunktzahlen beteiligt sind.
Die Angaben sind als "typisch" markiert, da natürlich Divisionen weniger komplex sind als Additionen, und die Compiler auch Optimierungen im Maschinencode machen.
Teilweise lässt sich das gezielt beeinflussen, z.B. bei Exponentialfunktionen.

 

[de vliegende hollander]

Zuviel Werbung?
-> Hier kostenlos registrieren

Ganzzahl verwende ich nur bei Zähler.
Ich bin da mit Real auch schon auf die Fresse geflogen.
Und auch rechnerei mit INT.. immer DINT verwenden

Also sonnst immer REAL.

Es gibt jetzt das Datentyp LREAL.
Dan dürfte sich einiges mit die Zählerei kommaverschiebung erledigt haben.
Aber schlau habe ich mir da noch nicht gemacht.

und LINT gibst auch

 

[Staubsauger]

Vielen Dank für eure zahlreichen Rückmeldungen.

Ich tendiere jetzt für Messwerte und ähnliches noch mehr zum REAL. Die Genauigkeit des 32-Bit REAL reicht für unsere Anwendung aus. Wenn die Zahlen größer werden, benötige ich die Nachkommastelle nicht und zeige sie auch nirgends an. Wenn mehr als eine Nachkommastelle benötigt wird, dann sind es in der Regel Zahlen < 10.
Von der Performance denke ich, dass ich klar komme. Wirklich zeitkritisch ist nur sehr wenig und das läuft dann in einem extra Interrupt-Baustein. Ob der Main jetzt ein oder zwei ms länger braucht, spielt für mich erst mal keine Rolle.
Dass Festkommazahlen in Unified nicht nativ funktionieren hatte ich bisher tatsächlich auch nicht auf dem Schirm.

Dass Zähler und ähnliches mit Ganzzahlen abgebildet werden ist mir klar.

Für Schnittstellen bleibe ich schon aus Gründen der Abwärtskompatibilität bei Festkommazahlen. Sobald "Fremde" im Spiel sind scheint mir meist die stumpfeste/einfachste Lösung die beste zu sein. Wenn man auf dem Display 125,3°C steht und man auf der Schnittstelle 1253 empfängt ist i.d.R. auch ohne Doku schon klar was zu tun ist.
Bei Feldbusschnittstellen PN <--> EtherCat etc. hatten wir auch schon massiv Probleme, wenn REALS nicht auf 32-Bit Adressen liegen (z.B. Q2.0). Das funktioniert bei Siemens zwar noch, führt aber auf den anderen Seiten zu Schwierigkeiten, da man da oft nicht oder nur über Umwege direkt von dieser Stelle lesen kann.

Zum Thema Wort- Festpunkt und Gleitpunktoperationen:

Wenn ich das jetzt richtig verstanden habe:
Gleitpunkt -> +-*/ von Reals (logisch)
Festpunkt -> +-*/ von Ganzzahlen wie INT
Wort -> sind dann logische Verknüpfungen, Slice-Zugriffe etc. auf binäre Datentypen wie WORD oder wie?

 

[Botimperator]

Falls ihr auch Werte habt im Bereich zB wie von dir genannt 0..100, aber keine Nachkommastellen vorhanden sind, würden sich auch Usint eignen. Die laufen nicht über und können Zahlen von 0..255 darstellen, brauchen nicht so viel Speicherplatz wie andere Ganzzahlen Datentypen

Da bin ich aber schon böse auf die Schnautze gefallen, wenn externe Teilnehmer (andere SPS, SCADA-Rechner, ...) nicht mit 8-Bit Datentypen konnten.
Das mit dem "weniger Speicherplatz" ist zwar theoretisch richtig, führt aber (für meinen Geschmack) zu zuvielen Stolpersteinen.
Und in der Post-S5 Zeit lohnt es sich nicht wegen einzelnen Bytes rumzumachen.

Wichtig bei jedem Zahlenfeld ist, dass aus dem Kommentar die physikalische Einheit drinnen steht. Vor allem bei Schnittstellen ist das essentiell (z.B. LSB = 0.2 U/min oder [0.2 U/min] )

Jep.
Wenn das fehlt hat man richtig Spaß (╯‵□′)╯︵┻━┻

Von der Performance denke ich, dass ich klar komme.

Meistens hilft es schon die Berechnung nur durchzuführen wenn eine Neuberechnung tatsächlich notwendig ist.
Oder den Eingabewert, der z.B. von einem HMI kommt, bausteinintern nur bei Wertänderung von REAL auf Festkommazahl zu casten.
Also Eingabe als REAL, eigentliche Berechnung im Baustein mit Festkomma.
Bei kritischen Sachen muss man mit Runtime-Messungen machmal etwas rumknobeln was unterm Strich die größere Ersparnis bringt.

Wenn ich das jetzt richtig verstanden habe:
Gleitpunkt -> +-*/ von Reals (logisch)
Festpunkt -> +-*/ von Ganzzahlen wie INT

Jep.

Wort -> sind dann logische Verknüpfungen, Slice-Zugriffe etc. auf binäre Datentypen wie WORD oder wie?

Zum Beispiel.
Üblicherweise für alles was kein Zahlenwert im eigentlichen Sinne ist.
z.B. für Statusinformationen. Beispiel siehe DA31/14 im Siemens Programmierstyleguide.

Wir benutzen der Einfachkeit halber bei den "einfacheren" Anwendungen bis 2-3 Kommastellen einfach REAL & feddich.
Bausteine, die für interne Berechnungen höhere Genauigkeiten als mit REAL möglich sind benötigen, verwenden dann bausteinintern LREAL oder LINT.
Das bleibt dann aber zu 99% im Baustein & die Ausgabe des Ergebnisses ist dann wieder in REAL/INT.
Außnahme sind Safety-Programme, da diese kein REAL können.
Da kommt man um Festkommazahlen im "normalen" Programm nicht drumrum.
Brauche ich persönlich z.B. für sichere Temperaturabfragen.