Step 7 OSCAT METER_START FB128 keine funktion

DerPilot

Level-2
Beiträge
7
Reaktionspunkte
0
Zuviel Werbung?
-> Hier kostenlos registrieren
OSCAT METER_STAT FB128 keine funktion

Ich habe einen Stromzähler Impulsausgang der am Eingang IN im Format REAL sauber anliegt.
Das SPS Datum ist auch im Format DATE angeschaltet.
Alle benötigten FCs aus der aktuellen OSCAT Bibiolotek sind in der CPU geladen (siehe Aufrufstruktur) die SCL-Quellen habe ich auch nochmal übersetzt
Trotsdem Zählt der FB128 Baustein nichts, alle Ausgaenge sind NULL
Auch der Baustein meter zeigt nix am Ausgang.
Der Diagnosepuffer der CPU zeigt keine Fehler, auch beim uebersetzen und laden der Objekte in die CPU kommt eine Fehlermeldung.

Ich habe keine Idee mehr :-( hat jemand den Baustein in Benutzung, und ein Lösungsansatz ?


S7 Scenario:
CPU 315-2 PN/DP
STEP7 5.5 SP2
 

Anhänge

  • FCs.PNG
    FCs.PNG
    18,1 KB · Aufrufe: 32
  • Aufrufstruktur.PNG
    Aufrufstruktur.PNG
    3 KB · Aufrufe: 39
  • meter_start.PNG
    meter_start.PNG
    21,1 KB · Aufrufe: 45
  • Variabeln.PNG
    Variabeln.PNG
    11,6 KB · Aufrufe: 36
Zuletzt bearbeitet:
1. Kann es sein, daß RST im IDB True ist?
Beschalte mal den Eingang RST mit einem 0-Merker oder False-Potential.

2. Hat wahrscheinlich nichts mit Deinem Problem zu tun, doch wie kommst Du von Zählerimpuls zu REAL? Wieso ist der REAL-Wert an IN so klein (1.63111e-042)?

Harald
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Hi Harald,

1. hab RST auf mein LOW Merker gelegt, passiert leider immer noch nichts an dem Ausgang Current_Day...

2. Am Eingang liegt der Monatswert (DEZ zur Zeit 1177) eines neuen Unterzaelers in KWh an

Juergen
 
Nochmal zurück zu Deinem komischen REAL: Dein REAL an IN hat einen ungültigen Wert E-042!
Lege mal einen vernünftigen Wert an den IN, z.B. die Konstante 123.45

(warum wundert mich das eigentlich nicht, daß der OSCAT-Baustein solche Fehler nicht signaliert und der ENO trotzdem grün bleibt??? ;))

Harald
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Nochmal zurück zu Deinem komischen REAL: Dein REAL an IN hat einen ungültigen Wert E-042!
Lege mal einen vernünftigen Wert an den IN, z.B. die Konstante 123.45

Was ist an der Zahl denn ungültig? Das ist eine denormalisierte Gleitkommazahl, auch für eine S7 ist das nach Norm gültig

(warum wundert mich das eigentlich nicht, daß der OSCAT-Baustein solche Fehler nicht signaliert und der ENO trotzdem grün bleibt??? ;))

Weil es kein Fehler ist!
 
hallo thomas,

dieser Wert ist schon möglich, aber nur wenn ihn die S7 selbst bildet. Als Steuerwert ist dieser Wert nicht erlaubt.

dein Wert besitzt demnach 42 Nachkommastellen. mir kommt der Wert extrem klein vor.

Vielleicht kannst du mal den Code posten, in dem deine REAL-Zahl gebildet wird.

mfg
Kapo
 
hallo thomas,

dieser Wert ist schon möglich, aber nur wenn ihn die S7 selbst bildet. Als Steuerwert ist dieser Wert nicht erlaubt.
Hi,
ein paar andere Programme aus Step 7 können damit auch nicht umgehen, das ist der eigentliche Fehler. Für die S7 ist das eine gültige Zahl, sie kann auch damit rechnen.
Ich habe Anfang dieses Jahres ein paar Versuche mit denormalisierten Real-Zahlen gemacht, auch mit TIA. Siehe Anhang.
 

Anhänge

  • TIA Denormalisierte Real v2.pdf
    430,6 KB · Aufrufe: 17
Zuviel Werbung?
-> Hier kostenlos registrieren
OK, hab ich mal simuliert:
Der FB 'METER_STAT' V1.3 (aus OSCAT 3.32) verarbeitet auch den eigentlich unzulässigen REAL-Wert 1.6111e-042, er signalisiert die fehlerhafte Verarbeitung auch korrekt am ENO (FUP: der Baustein-Rahmen ist dann nicht mehr grün).

Also ist beim TE noch irgendwas anderes faul. Vielleicht meldet er sich ja nochmal.

Welche Version des 'METER_STAT' wird eingesetzt bzw. ist der noch original?
Welche SCL-Version?
Wird nur Simuliert oder echte CPU? Welche CPU genau? Welche Firmware?

Hat das Neu-Erzeugen des IDB was genützt?

Harald


Hilfe zu S7-SCL schrieb:
Numerische Datentypen

Gleitpunktzahl (IEEE-Gleitpunktzahl)
Wertebereich

-3.402822E+38 bis -1.175495E-38
+/- 0
1.175495E-38 bis 3.402822E+38
Hilfe zu STEP7 schrieb:
Elementare Datentypen

REAL (Gleitpunktzahl)
Bereich und Zahlendarstellung (niedrigster bis höchster Wert)
Obere Grenze: ±3.402823e+38
Untere Grenze: ±1.175 495e-38
Hilfe zu STEP7 schrieb:
Format des Datentyps REAL (Gleitpunktzahlen)

Bereich
-3,402 823E+38 bis -1,175 495E-38
und 0 und
+1,175 495E-38 bis +3,402 823E+38

Ungültiger Bereich für ein Ergebnis
-1,175494E-38 < Ergebnis < -1,401298E-45 (negative Zahl) Unterschreitung --> A1=0 A0=0 OV=1 OS=1
+1,401298E-45 < Ergebnis < +1,175494E-38 (positive Zahl) Unterschreitung --> A1=0 A0=0 OV=1 OS=1
Ergebnis < -3,402823E+38 (negative Zahl) Überlauf --> A1=0 A0=1 OV=1 OS=1
Ergebnis > 3,402823E+38 (positive Zahl) Überlauf --> A1=1 A0=0 OV=1 OS=1
keine gültige Gleitpunktzahl oder unzulässige Operation (Eingangswert außerhalb des gültigen Wertebereichs) --> A1=1 A0=1 OV=1 OS=1
 
OK, hab ich mal simuliert:
Der FB 'METER_STAT' V1.3 (aus OSCAT 3.32) verarbeitet auch den eigentlich unzulässigen REAL-Wert 1.6111e-042, er signalisiert die fehlerhafte Verarbeitung auch korrekt am ENO (FUP: der Baustein-Rahmen ist dann nicht mehr grün).

Mit Plcsim simuliert, oder an einer realen SPS?

Ich hatte meine Versuche ja an einer 416 (womöglich unterscheiden sich 300er und die 400er/318 noch bei dem Verhalten) gemacht, hab' leider nicht das Statusregister mit auf dem Screenshot, weil mir es hauptsächlich auf den Vergleich auf Null ankam.
Wenn eine SPS damit rechnen kann, wäre es ja womöglich fatal wenn man in FUP/KOP programmiert und über ENO Bausteine aneinanderhängt die dann nicht mehr aufgerufen werden. Und obwohl richtig gerechnet wird das Bit auf false geht.

Nach Norm ANSI/IEEE Standard 754-1985 die Siemens in der Hilfe erwähnt sind die Zahlen ja auch zulässig.

Was machst du denn in deinen Programmen wenn du feststellst dass eine denormalisierte Zahl vorliegt? Hört sich ja an als ob du das selbst in deinen AWL Programmen vor jeder Rechenoperation überprüfst (SCL macht das Durchleiten wenn die Option aktiviert automatisch, wobei ich gerade überlege ob das überhaupt sinnvoll ist).
 
Was ist an der Zahl denn ungültig? Das ist eine denormalisierte Gleitkommazahl, auch für eine S7 ist das nach Norm gültig
Nein, für die S7 ist sie nicht gültig.
Die Siemens-Implementation der REAL-Zahlen in S7 ist nicht 100% konform zur Norm ANSI/IEEE Standard 754-1985. Denormalisierte Gleitkommazahlen sind für die S7 nicht zulässig, was Siemens dadurch dokumentiert, daß es den für REAL zulässigen Wertebereich auf Gleitkommazahlen mit Exponent -38...+38 beschränkt.

Das mag vielleicht damit zu tun haben, daß Siemens als "Feature" auch positive Ganzzahlen (!) als Operanden für Gleitkommazahl-Operationen zulässt (womöglich als Zugeständnis an dilettantische SPS-Programmierer, welche sonst zu oft die CPU in Stop crashen würden ;) ).
Code:
L  1234
L   100
/R       //ergibt doch tatsächlich 12.34 ! Ohne irgendeinen Fehler anzuzeigen.
T  MD20


Weil es kein Fehler ist!
Doch, in S7 ist es ein Fehler und er wird auch durch Setzen des Statusflag OV (Überlauf) signalisiert.

Daß der ENO vom OSCAT-Baustein beim TE trotz dieses Fehlers grün bleibt kann an den Einstellungen des SCL-Compilers beim TE liegen. Läßt man den Compiler das OK-Flag setzen, dann signalisiert der Baustein auch den unzulässigen Wertebereich durch deaktivieren des ENO. (eigene Parameter-/Ergebnis-Prüfungen hat der Baustein keine)


Was machst du denn in deinen Programmen wenn du feststellst dass eine denormalisierte Zahl vorliegt? Hört sich ja an als ob du das selbst in deinen AWL Programmen vor jeder Rechenoperation überprüfst
Ich überprüfe es nicht extra. Bei meinen Berechnungen können keine denormalisierten Werte oder NaN als Ergebnis herauskommen. Erstens brauchte ich noch nie so kleine/große Zahlen. Zweitens prüfe ich die Eingangsparameter, ob sie innerhalb festgelegter Grenzen liegen. Ich teste meine Programme mit dem festgelegten Wertebereich aus, zumindest mit dem kleinsten und dem größten Grenzwert und etwas darunter und etwas darüber und ein paar markante Werte im Wertebereich.

Harald
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Ich habe einen Stromzähler Impulsausgang der am Eingang IN im Format REAL sauber anliegt.
wie kommst Du von Zählerimpuls zu REAL? Wieso ist der REAL-Wert an IN so klein (1.63111e-042)?
Am Eingang liegt der Monatswert (DEZ zur Zeit 1177) eines neuen Unterzaelers in KWh an
Hallo Juergen,

falls es Dich noch interessiert:

1.63111e-042 = DW#16#0000048C = L#1164

Kann es sein, daß zum Zeitpunkt Deines Screenshots der Zählerwert 1164 kWh betrug?!
Soviel zum "sauber" anliegenden Stromzähler-Ausgang ...
Der Zählerwert muß erst noch korrekt in REAL konvertiert werden.

Harald
 
Ich überprüfe es nicht extra. Bei meinen Berechnungen können keine denormalisierten Werte oder NaN als Ergebnis herauskommen. Erstens brauchte ich noch nie so kleine/große Zahlen. Zweitens prüfe ich die Eingangsparameter, ob sie innerhalb festgelegter Grenzen liegen. Ich teste meine Programme mit dem festgelegten Wertebereich aus, zumindest mit dem kleinsten und dem größten Grenzwert und etwas darunter und etwas darüber und ein paar markante Werte im Wertebereich.

Dann bist du in der glücklichen Lage, dass du keine Programme schreiben musst in denen rückgekoppelte Algorithmen wie IIR-Filter oder Reglerstrukturen vorkommen. Denn dort muss man mit so etwas theoretisch immer rechnen.
Das unschöne an der Sache ist ja, dass die S7 diese nach eigener Festlegung "ungültigen" Zahlen selber erzeugt. Also muss mein Programm auch immer damit rechnen dass so eine Zahl vorkommt.
Bei einer SPS ist das nicht so wild, aber es gibt Prozessoren bei denen die Gleitkommaeinheit zusätzlich extrem langsam wird wenn mit denormalisierten Werten gerechnet werden muss.
 
Hi, ich habe nochmal alles überprüft, immer noch alles null an den Ausgängen von meter_stat


@Harald
Welche Version des 'METER_STAT' wird eingesetzt bzw. ist der noch original?
-die originale V1.3
Welche SCL-Version?
-2010 SR2 (5.3 SP6)
Wird nur Simuliert oder echte CPU? Welche CPU genau? Welche Firmware?
-Auf der CPU 315_2 PN/DP Firmware V3.2.3

Hat das Neu-Erzeugen des IDB was genützt?
habe alle Bausteine neu Uebersetzt und geladen ohne Fehlermeldung

Habt Ihr noch eine Idee ...)-:

 
Zuviel Werbung?
-> Hier kostenlos registrieren
Hi all,
Hi Harald,



Welche Version des 'METER_STAT' wird eingesetzt bzw. ist der noch original?
- 1.3 das Original

Welche SCL-Version?
2010 SR2 (V5.3+SP6)

Wird nur Simuliert oder echte CPU? Welche CPU genau? Welche Firmware?
- Die 315-2 Firmware 3.2.8

Hat das Neu-Erzeugen des IDB was genützt?
Ja hab ich gemacht.. alle uebersetzt ohne Felhler und neu geladen


Hat noch einer ne Idee:-(



Im Beispiel im Anhang liegen 554,2 KWh am Eingang an




Meter_Stat.jpg
 
Hi again,

hab noch mal dank euren Beiträgen alle Zahlenformate ueberprueft:

Bingo Harald an dem Eingang lag das falsche Zahlenformat an, nach der Konvertierung mit DTR läuft der Zähler sauber... :D

super :D

DANKE !!
Juergen
 
Zurück
Oben