Seltsames Verhalten einer S7-312 bei Real-Addition

Y

yohfreaker

Level-1
Beiträge
5
Reaktionspunkte
0
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo erstmal, bin neu hier.
Zu meiner Person, bin 32 Jahre alt und arbeite seit 7 Jahren aktiv mit S5 und S7, Störungsbehebung.

Mein Problem:
Einfache Auswertung eines Stromzählers, Impulslänge 100ms, Zählen der Impulse und berechnen der Momentanleistung.
Siehe Bild1, ein Teil des Programms und Bild2 das Ergebnis.
Nach den Regeln der Technik sollte nun in DB12.DBD6 und DB12.DBD14 der selbe Wert ankommen.
1. im ersten Wert(DBD6) fehlen 39 Impulse.
2. Wenn ich immer 0,01 addiere, warum sind die letzten Kommastellen nicht Null?
Meine erste Überlegung war, 'hab wieder mist programmiert',
Also CPU ausgebaut, komplettes Programm gelöscht,das eine Netzwerk in einen FC kopiert, den zugehörigen DB kopiert. Testlauf. Nach wenigen Sekunden das Gleiche Ergebnis, Impulse fehlen und die letzten Kommastellen sind nicht Null.

Die CPU ist eine 6ES7 312-1AD10-0AB0 HW 3 FW V2.05

Kann das jemand erklären?

mfg


s7-real1.jpg

s7-real2.jpg
 
Das liegt am Real-Format und lässt sich nicht ändern.
nimm doch einen DINT und zähle damit deine Impulse.
 
Real habe ich nur verwendet weil der Wert fertig für die Visu ist,(mit 2 Kommastelllen) vom Zähler aber 800Imp/Kwh kommen, also muss ich sowiso umrechnen. Der Programmteil sollte eigentlich nur 0,01kWh addieren.

Heisst das nun, wenn man in der 300er mit Real rechnet, kommt immer 'irgendwas' hinten raus?
 
Zuletzt bearbeitet:
REAL ist nur auf 6 Dezimalstellen genau

Aus der Step7-Hilfe (Index: Datentyp - REAL)
Format des Datentyps REAL (Gleitpunktzahlen)

Gleitpunktzahlen in STEP 7 entsprechen dem Grundformat mit einfacher Breite,
wie in der Norm ANSI/IEEE Standard 754-1985 [...] beschrieben. [...]

Genauigkeit beim Rechnen mit Gleitpunktzahlen
---------------------------------------------------------------------------------
Vorsicht

Bei umfangreichen Berechnungen mit Zahlen, die große Größenunterschiede
(mehrere 10-er Potenzen) aufweisen, können Ungenauigkeiten im Rechenergebnis
entstehen.
---------------------------------------------------------------------------------

Die Gleitpunktzahlen in STEP 7 sind auf 6 Dezimalstellen genau. Sie können deshalb
bei der Angabe von Gleitpunktkonstanten nur maximal 6 Nachkommastellen angeben.

---------------------------------------------------------------------------------
Hinweis

Die Rechengenauigkeit von 6 Dezimalstellen bedeutet z. B., dass die Addition von
Zahl1 + Zahl2 = Zahl1 ergibt, wenn Zahl1 größer Zahl2 * 10 hoch y, mit y>6 ist:

100 000 000 + 1 = 100 000 000.
---------------------------------------------------------------------------------
Zum Vergrößern anklicken....
Mit DINT hast Du eine Auflösung von 9,5 Dezimalstellen.
Zähler in DINT kann man auch kaskadieren, wenn man mehr Dezimalstellen braucht.

yohfreaker schrieb:
Real habe ich nur verwendet weil der Wert fertig für die Visu ist,(mit 2 Kommastelllen)
Zum Vergrößern anklicken....
Beim Rechnen keine Rücksicht auf die Visu nehmen, sondern das Verfahren entsprechend
der benötigten Genauigkeit wählen und erst zum Schluß in das Format umwandeln, das
die Visu braucht. Dann wird nur einmal gerundet. Und man kann die Einheit so wählen, daß
6 Dezimalstellen für die Anzeige reichen (Wh, kWh, MWh).
Bei mir bekommt die Visu nie die original-Variable zum Anzeigen, sondern immer eine (ggf.
skalierte) Kopie in einem extra Visu-DB.

Was hast Du für eine Visu?
Kann die nicht bei der Anzeige von Ganzzahlen ein Komma einfügen? Oder skalieren?

Die Rechenoperationen für Ganzzahlen heißen übrigens Festpunkt-Funktionen, weil man
sich da an einer festen Stelle ein Dezimalkomma 'reindenken kann.
Du hast ja Zahlen, wo fest 2 Stellen von hinten das Komma sitzt.

Gruß
PN/DP
 
Zuviel Werbung?
-> Hier kostenlos registrieren
So, nochmal nachgedacht.

So eine Sache wie Verbrauchszähler realisiert man wirklich nicht in REAL, sondern in DINT.
Doch bis jetzt brauchst Du noch gar keine 6 Dezimalstellen.

Die Rechen"un"genauigkeit bei REAL erklärt nur, warum die letzten 4 Nachkommastellen nicht
0000 sind. Es erklärt aber nicht die Differenz von 0.39 zwischen DB12.DBD6 und DB12.DBD14,
wenn beide bei 0.0 zu zählen angefangen haben. Einer oder beide Werte müssen noch woanders
in Deinem Programm oder von außen verändert werden.

Bist Du sicher, daß Du beim Testen/Simulieren bei beiden Werten mit 0.000000 angefangen hast?
Wie zählst Du bzw. simulierst Du die Zählimpulse?
Hast Du mal in der Referenzliste nachgeschaut, ob Du einen der beiden Werte irrtümlich oder
fehlerhaft noch woanders veränderst?
Schreibt vielleicht Deine Visu auf diese Werte?

Check mal alle Stellen, wo Du indirekte Adressierung benutzt oder SFC20 oder SFC21 oder
sonstige Blockoperationen einsetzt.

Bei Deinem Test mit der ausgebauten CPU hast Du ja wohl mehr als nur dieses eine Netzwerk
im Programm gehabt. Sonst hätte sich keiner der beiden Werte verändert.
Wie sieht Dein OB1 aus?

Hast Du vielleicht auch noch einen OB35 oder OB40? Wenn da was mit fehlerhafter indirekter
Adressierung drin ist und Du "erwischst" den Lokaldatenstack, dann kann es schon passieren,
daß die beiden ADD-Boxen unterschiedlich zählen. Oder gar der DB12 direkt "getroffen" wird. :sm9:

Zu Deinem Netzwerk:
Ich hätte das MOVE nicht hinter die obere ADD-Box gesetzt, sondern direkt hinter das CMP,
vor beide ADD-Boxen. Oder unterhalb der beiden ADD-Boxen am Ausgang vom CMP. Einfach so aus
"Gefühl". Bei Dir wird das MOVE im Programmablauf zwischen den beiden ADD-Boxen ausgeführt
und nur dann, wenn bei dem oberen ADD kein Fehler auftritt.
Das spielt hier aber höchstwahrscheinlich keine Rolle.
Aber vielleicht hast Du in anderen Netzwerken Deine Boxen auch so unglücklich angeordnet,
wo es dann doch eine Rolle spielen könnte?

Das sollte jetzt keine Kritik an Deinem Programmierstil sein, sondern Hinweise geben, wonach
Du suchen must, falls es kein einfacher Fehler sein sollte. ;)

Also, ich nehme mal die CPU312 in Schutz und tippe auf einen ordinären Tippfehler irgendwo
in Deinem restlichen Programm.

Gruß
PN/DP
 
Hallo!

Danke für die Ansätze zur Fehlersuche.
Bei meinem 'Trockentest' war nur die CP312 alleine (mit geänderter HW Config), der FC12(das eine betroffene Netzwerk),DB12 und im OB1 ein ''uc fc12", sonst nichts.
Die Impulse hab ich 'simuliert' indem ich den CMP an beiden Eingängen mit 0 belegt hab, dann addiert es bei jedem Programmdurchlauf.

Nun zur Lösung des Problems, mehrere Varianten:
1. wie PN/DP vermutet hat, den MOVE entfernen, beide Zähler laufen dann synchron.
2. einen anderen Wert addieren, z.B 0,02, Problem ist ebenfalls weg.
3. Andere CPU, mit einer 315-2DP funktioniert das Programm immer ohne Probleme.

Das erklärt nun auch wieso in der Anlage die anderen 4 Zähler funktionieren, diese addieren immer 1 bzw. 0,1.
mfg
 
Zuletzt bearbeitet:
Firmware-Problem?

Hallo yohfreaker,

Danke für Deine Informationen zur Problemlösung.

yohfreaker schrieb:
Nun zur Lösung des Problems, mehrere Varianten:
1. wie PN/DP vermutet hat, den MOVE entfernen, beide Zähler laufen dann synchron.
2. einen anderen Wert addieren, z.B 0,02, Problem ist ebenfalls weg.
3. Andere CPU, mit einer 315-2DP funktioniert das Programm immer ohne Probleme.
Zum Vergrößern anklicken....

Das klingt ziemlich mysteriös. Vor allem das mit dem MOVE entfernen.
Nun tendiere ich doch dahin, daß mit der Firmware der CPU was nicht in Ordnung ist.
Du kannst Dich ja mal mit der Testversion Deines Programmes (OB1, FC12, DB12) an den
Siemens A&D Support in Nürnberg wenden.

Oder auf Verdacht ein Firmware-Update auf die neueste Version machen. Die Firmware
der CPU ist schon reichlich oft wegen Fehlerbeseitigungen geändert worden.
Aktuell: V2.0.12 für CPU 312-1AD10-0AB0

Betriebssystem-Updates für CPU 312

Gruß Harald
 
Zurück
Oben