Unterschiedliche Werte in DBD<-->MD

Steve81

Level-1
Beiträge
505
Reaktionspunkte
77
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo,

ich habe einen FC, der mir einen REAL-Wert berechnet und ausgibt. Nun beobachte ich diesen Wert in der Variablentabelle und beobachte unterschiedliche Werte wenn ich ein MD bzw. ein DBD beschreibe. Das was ich bei einem MD lese ist der Wert, den ich auch erwarte. Was ich beim DBD lese kann ich leider nicht ganz nachvollziehen.

Hab zum Test 2mal den FC aufgerufen und schreibe einmal in MD und einmal in DBD (siehe Grafik).

Hat jemand eine Idee?
 

Anhänge

  • VAT_1_1.jpg
    VAT_1_1.jpg
    162,8 KB · Aufrufe: 97
Hallo,

nimm mal statt "out" den Variablentyp "inout".
Beim Schreiben in DBs wird in den Funktionen über temp. Lokalvariablen rangiert. Das kann die Verfälschungen bringen.

Gruß
raika
 
Hallo,

nimm mal statt "out" den Variablentyp "inout".
Beim Schreiben in DBs wird in den Funktionen über temp. Lokalvariablen rangiert. Das kann die Verfälschungen bringen.

Gruß
raika

Danke für den Tipp, wenn ich "inout" verwende funktioniert es.:-D
Aber so recht verstehen tu ichs nicht.:confused:
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo Steve,

geh einfach mal in "erreichbare Teilnehmer", lösche die FC und schau den Aufruf der FC an.

Der Aufruf "Call" ist nur ein Makro, der jetzt rot dargestellt wird.
Der eigentliche Aufruf ist der "UC FC...".

Bei der Parameterübergabe werden DB-Werte über temporäre Lokalvariablen dem UC-Aufruf übergeben, Merkerbereiche dagegen werden direkt übergeben.

Dies passiert aber auch nur, wenn der FC-Aufruf grafisch programmiert wurde.

Beim AWL-Call-Aufruf kannst Du allerdings die Parameter direkt angeben.


Gruß
raika
 
Hallo Steve,

geh einfach mal in "erreichbare Teilnehmer", lösche die FC und schau den Aufruf der FC an.

Der Aufruf "Call" ist nur ein Makro, der jetzt rot dargestellt wird.
Der eigentliche Aufruf ist der "UC FC...".

Bei der Parameterübergabe werden DB-Werte über temporäre Lokalvariablen dem UC-Aufruf übergeben, Merkerbereiche dagegen werden direkt übergeben.

Dies passiert aber auch nur, wenn der FC-Aufruf grafisch programmiert wurde.

Beim AWL-Call-Aufruf kannst Du allerdings die Parameter direkt angeben.


Gruß
raika

Aber mir ist noch nicht ganz klar, warum das dann passiert.
 
Aber mir ist noch nicht ganz klar, warum das dann passiert.

Mir leider auch nicht!
Da macht man "eigentlich" nichts falsch und trotzdem ist das Ergebnis Schrott und man zerbricht sich den Kopf wo das Problem liegt!

Ist das ein Siemensproblem oder taucht das auch bei anderen Entwicklungsumgebungen auf?
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Folgendes sagt die Siemens FAQ dazu
Warum liefert eine Funktion bei den OUT-Parametern sporadisch falsche Rückgabewerte und was ist bei der Parametrierung der Ein- und Ausgangsparameter zu beachten?

Beschreibung:
Dieser Beitrag erfasst die folgenden Themengebiete:
  1. Sporadisch falsche Rückgabewerte bei den OUT-Parametern einer Funktion
  2. Versorgung der elementaren Ein- und Ausgangsparameter
  3. Unterschied zwischen Formal- und Aktualparametern
  1. Sporadisch falsche Rückgabewerte bei den OUT-Parametern einer Funktion
Dieses Verhalten von STEP 7 bezüglich der OUT-Parameter von Funktionen (FCs) kann folgende Ursache haben:
Gemäß IEC 1161 ist der FC ein Baustein ohne Gedächtnis und im Gegensatz zum FB hat der FC keine statischen Variablen. Die Bausteinparameter werden bei Funktionen und Funktionsbausteinen unterschiedlich abgelegt.
Unterschied zwischen statischen und temporären Lokaldaten:
  • Statische Lokaldaten sind Operanden, die im Instanz-DB des FBs abgelegt werden. Statische Lokaldaten gehen nach der Beendigung des Bausteins nicht verloren.
  • Temporäre Lokaldaten werden nicht im Instanz-DB, sondern im Lokaldatenstack im Systemspeicher der CPU abgelegt und können nicht über Zyklusgrenzen hinaus verwendet werden. Diese temporären Lokaldaten werden zur Zwischenspeicherung von Ergebnissen verwendet und stehen nur während der Programmbearbeitung zur Verfügung. Die Daten gehen nach Beendigung des Bausteins verloren.
Darstellung für die interne Arbeitsweise der CPU bzw. der Parameterablage bei FCs
Die temporären Lokaldaten werden in der Reihenfolge der Deklaration - gemäß dem Datentyp - im Lokaldatenstack abgelegt:
L Input T LW"1" Initialisierung der Variable L InOut T LW"3" Initialisierung der Variable CALL FC L LW"2" // Initialisierung der Variable wird hier nicht durchgeführt!
// Der Anwender muss hier sicherstellen, dass die OUTPUT Variable
// bei jedem Durchlauf des FCs beschrieben wird: T Output L LW"3" T InOut Nach dem Aufruf der FC legt der Editor die Bausteinparameter als bereichsübergreifende Bereichszeiger im Bausteincode ab. Jeder Bausteinparameter benötigt ein Doppelwort Speicherplatz:
  • P# LW"1" INPUT (E,A,M)
  • P# LW"2" OUTPUT (E,A.M)
  • P# LW"3" IN_OUTPUT (E,A,M)
Der Editor verwendet die temporären Lokaldaten bei der Bausteinparameterübergabe. Je nach Datentyp und Deklarationstyp weist der Zeiger auf den Aktualparameter:
L LW"2" T Output L LW"3" T InOut
Im Gegensatz zum Funktionsbaustein gibt es bei der Funktion nur eine "nicht remanente" Speicherung der Daten im Lokaldatenbereich. Dadurch ist eine Auswertung / Zuweisung der Daten beim Aufruf der Funktion zwingend erforderlich.
( 3 KB )
Bild 01
Durch diese Art der Parameterübergabe bei FC-Aufrufen wird vom Betriebssystem der Lokaldatenstack verbraucht. Dem Anwender steht somit nicht der volle Stack zur Verfügung.
  1. Versorgung der elementaren Ein- und Ausgangsparameter
Bei der Versorgung von elementaren Formalparametern (z.B. die Datentypen BOOL, BYTE, WORD oder DWORD) der Schnittstelle einer Funktion sind zwei Fälle zu unterscheiden.
  1. Der elementare Formalparameter wird mit einem Merker, einem Ein- oder Ausgang aus dem Prozessabbild oder aus dem Lokaldatenstack (L-Stack) des aufrufenden Bausteines versorgt.
    In diesem Fall arbeitet der Code der Funktion mit einem bereichsübergreifenden Zeiger direkt(!) auf diesen elementaren Aktualparametern (z.B. P#E0.0, P#M0.0).
  2. Der elementare Formalparameter wird mit einer Konstanten oder einem Datenbausteinelement versorgt.
    In diesem Fall wird der Wert des Aktualparameters vor dem Aufruf der Funktion in den L-Stack des aufrufenden Bausteines kopiert. Der Code der Funktion arbeitet dann mit einem bereichsübergreifenden Zeiger auf diesen Lokaldatenbereich des aufrufenden Bausteines.
    Beachten Sie bitte, dass bei Ausgangsparametern keine Initialisierung erfolgt und die Eingangsparameter nicht gelöscht werden. Deshalb ist in diesem Fall darauf zu achten, dass Eingänge nur gelesen und Ausgänge in jedem Zyklus geschrieben werden. Bei Befehlen wie "S" oder "R" wird das Signal nur abhängig vom VKE geschrieben. Deshalb sollten Sie diese Befehle durch die Zuweisung "=" ersetzen oder die Werte vor der Abfrage initialisieren.
    Wenn Sie das Beschreiben der Werte nicht in jedem Zyklus sicherstellen können, sollten Sie einen IN/OUT- Parameter verwenden.
Abhilfe:
  • Wenn bei einem FC eine OUTPUT-Variable beim Aufruf mit einer DB-Adresse versorgt und diese OUTPUT-Variable im FC anschließend mittels Setz- bzw. Rücksetz-Befehl in einen definierten Zustand gesetzt werden soll, so führt der Aufruf dazu, dass der S- bzw. R-Befehl sich wie ein =-Befehl auswirkt. Die Ursache hierfür liegt darin, dass die beim FC-Aufruf mit DB-Adressen versorgten OUTPUT-Variablen beim Aufruf über den L-Stack versorgt werden. Sollte nun die Bedingung für den R- bzw. S-Befehl nicht mehr erfüllt sein, wird die OUTPUT-Variable nicht mehr beschrieben. Somit wird die DB-Zelle mit einem zufällig in dieser Lokal-Stack-Adresse stehenden Wert versorgt. In diesem Fall empfehlen wir Ihnen als Abhilfe die OUTPUT-Variable durch eine IN/OUT-Variable zu ersetzten. Dadurch wird die Lokal-Stack-Adresse vor dem Aufruf durch den Inhalt der DB-Adresse definiert vorbelegt.
  • Das Verhalten kann auch auftreten, wenn der FC mehrfach aufgerufen wird und/oder DB-Variablen als Aktualwerte benutzt werden. Beachten Sie dabei bitte die Hinweise aus der STEP 7-Onlinehilfe "Vermeiden von Fehlern beim Aufruf von Bausteinen". Die OUT-Parameter in einem FC müssen bei jedem Bausteinaufruf im Zyklus beschrieben werden.
Weitere Informationen zu diesem Thema finden Sie in der Online-Hilfe auch unter den Suchbegriffen:
  • Vermeidung von Fehlern beim Aufrufen von Bausteinen
  • Zulässige Datentypen beim Übergeben von Parametern.
 
DbVsMd

Hallo zusammen,


ich kann dass alles nicht so ganz nachvollziehen.

Habe mir einen FB und einen FC geschrieben.

Jeweils mit einem Eingang, Out und InOut.

Code im FB/FC

l Eingang
T Out
T InOut

Zusätzlich eine Global DB mit 4 DBD's

Jetzt rufe ich alles im OB1 auf.

Getestet habe ich alles mit einer 315.

Das Ergebnis seht ihr in der VAT.

Denke hier wird etwas im DB überschrieben, oder in der Vat auf den falschen Datenbereich geschaut.

Schöne Grüße zum WE
 

Anhänge

  • Unbenannt1.jpg
    Unbenannt1.jpg
    186,9 KB · Aufrufe: 34
  • Vat.jpg
    Vat.jpg
    76,4 KB · Aufrufe: 42
Zuviel Werbung?
-> Hier kostenlos registrieren
Daß man Outputs im FC immer beschreiben muß ist eigentlich klar, ich denke, das hat er auch gemacht. (Leider war der Code des FC nicht dabei). Ansonsten hatte ich schon einige Mal Probleme, wenn im FC (oder war es FB?) Outputs geschrieben wurden, die letztendlich in unterschiedlichen DB lagen, also am FC qualifiziert angegeben wurden. Damit kommt Step7 irgendwie manchmal nicht zurecht, es schreibt dann durchaus mal in den falschen DB, wenn man Glück hat merkt man es, weil die SPS in STOP geht. Leider kann ich das nicht mehr ganz nachvollziehen, da ich den Code abgeändert hab, so daß er funktioniert, hätte mal den fehlerhaften FC/FB aufheben sollen :confused:.

PS: Ich glaub es war auch ganz lustig, die Funktion CONCAT aus der IEC-Library mit Inputs (aus IN-Parametern eines FC) aus unterschiedlichen DB zu versorgen. Wenn ich mich richtig entsinne, brach das Caos aus.
 
Zuletzt bearbeitet:
Sporadisch

... sollte sie wirklich nicht!

Was sagt den die Siemens Hotline dazu?

Die Jungs sind ja recht fit und testen gerne auch mal den
kritischen Code.
 
Daß man Outputs im FC immer beschreiben muß ist eigentlich klar, ich denke, das hat er auch gemacht. (Leider war der Code des FC nicht dabei).

Hallo, ich muss zugeben, dass ich den Output des FC nicht in jedem Zyklus beschrieben haben. Dafür hatte ich aber auch nicht nur sporadisch den falschen Wert sondern immer (auser eventuell direkt in dem Zyklus in dem ich ihn beschrieben habe).
Hab ich also doch einen Fehler gemacht!:cry:

Ich werde morgen den FC nochmal mit nem OUT testen und ihn dann mal in jedem Zyklus beschreiben obs dann funktioniert.

Für alle interessierten werd ich morgen auch noch den SCL-Code des FC rein stellen (ist aber nix besonderes, nur eine FOR-Schleife, ein paar Rechnungen und ein paar IF abfragen).
 
Hallo, ich muss zugeben, dass ich den Output des FC nicht in jedem Zyklus beschrieben haben. Dafür hatte ich aber auch nicht nur sporadisch den falschen Wert sondern immer (auser eventuell direkt in dem Zyklus in dem ich ihn beschrieben habe).
Dieses Problem hatte ich auch schon mal. Solange am OUT ein Merkerwort angegeben wurde, funktionierte das ganze, mit einem DBW nicht.
Der Fehler war auch hier, dass die OUT-Variable nicht zyklisch beschrieben wurde.

So gesehen ist es eher "Zufall" dass es mit einem Merkerwort funktionierte.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Dieses Problem hatte ich auch schon mal. Solange am OUT ein Merkerwort angegeben wurde, funktionierte das ganze, mit einem DBW nicht.
Der Fehler war auch hier, dass die OUT-Variable nicht zyklisch beschrieben wurde.

So gesehen ist es eher "Zufall" dass es mit einem Merkerwort funktionierte.

Das würde ich nicht "Zufall" nennen.
Merkerbereiche werden ja direkt übergeben, nicht aber DB-Bereiche.
Mach mal den hier beschriebenen Test: http://www.sps-forum.de/showpost.php?p=122627&postcount=6

Gruß
raika
 
Ja, aber warum dann falsche Ergebnisse?

Du schreibst doch selbst:"Daß man Outputs im FC immer beschreiben muß ist eigentlich klar...".

Merkerbereiche werden nicht über Lokalvariablen weitergereicht, also muss ich sie auch nicht kontinuierlich beschreiben.
Wie bekannt, ist es bei Datenbausteinen halt anders. Wenn ich hier nicht kontinuierlich zuweise, ändern die Lokaldatenbereiche, die hier ja als Übergabebereich fungieren, aufgrund ihres temporären Charakters auch mal ihren Inhalt.

Gruß
raika
 
Zurück
Oben