Step 7 FB wird nicht richtig aufgerufen

ladychaos · 23 März 2015

Hallo zusammen.
Ich stehe vor einem großen Problem. Letzte Woche habe ich beim Kunden eine Migration von WinCC V7.0 auf V7.3 durchgeführt und beim Testen der Softwarerweiterung einen Fehler gefunden:

8 EA-Felder werden auf Wertänderung (im DB) überprüft und sollte sich eine Änderung feststellen lassen, wird ein Button eingeblendet, der zur Bestätigung gedrückt werden soll. Wird der Button gedrückt, nimmt die CPU 314 2 DP einen Zeitstempel, trägt einen Text aus einer Combobox in einen DB ein und blendet den Button wieder aus. Das Ganze ist über verschiedene Pointer usw. in einem FB ausprogrammiert. Alles läuft in einem 10teiligen Schieberegister.

Ich habe das ganze ausreichend auf meiner ES getestet, in der plcSim + OS Simulation läuft alles einwandfrei, lade ich das ganze 1:1 auf CPU und Server beim Kunden, gehen 2 von 8 Buttons nicht mehr weg - keine Wertübernahme, keine Zeitstempel, kein Schieben...

Habe zu Testzwecken die Button gegen Merker getauscht, mich mit der OS Simulation auf den Server verbunden und es geht nicht. Stelle ich von CPU auf plcSim um, klappt alles wieder ohne Probleme - also der Code kann es nicht sein. Ein Bausteinvergleich online/offline sagt, dass ausser Aktualwerten alles identisch ist. Habe auch die CPU nochmals samt HW geladen, ohne Erfolg. Auch die Netzwerke aus dem FB habe ich soweit auskommentiert, dass nur noch die betreffenden EA-Felder bearbeitet werden, hilft auch nichts. Die Zykluszeit der CPU sowie Speicherplatz ist in Ordnung. Die Diagnose der CPU sagt keine Fehler.

Da alle 8 EA-Felder in dem gleichen FB nacheinander abgearbeitet werden und das Problem bei allen Instanzen auftaucht, weiss ich auch nicht weiter. Das erste EA-Feld ist im ersten NW des FBs, dann die 6 Felder die tadellos abgearbeitet werden, dann das 8. Feld, das wieder nicht läuft.

Hoffentlich habe ich mich einigermaßen verständlich ausgedrückt und jemand kann mir einen Tip geben, wo der Hund begraben liegt.

Liebe Grüße,
Sabine

mikeh · 23 März 2015

Hallo Sabine,

es klingt für mich so, als wäre dein Prozeßabbild in der HW-Konfig nicht groß genug. Hast du bei deinen neuen E/A´s das OB1-PA eingetragen?

Gruß Mike!

PN/DP · 23 März 2015

Mit HW Konfig hat das eher wenig bis garnichts zu tun...

Für mich klingt das wie falsche Verwendung von TEMP-Variablen.

Falls es das nicht ist: Wenn möglich würde ich den/die Instanz-DB im Projekt löschen und neu generieren. Dann die beteiligten DB und den FB nochmal in die CPU laden.

Steht vielleicht irgendwas relevantes im CPU-Diagnosepuffer?
Wie sieht es mit der Bausteinkonsistenz aus?
Wie sieht der Code Deines FB aus?

Harald

ladychaos · 24 März 2015

Danke euch beiden!
Also Prozessabbild kann ich ausschließen, da ich weder Ein- noch Ausgänge (HW) für die Funktion verwende. Die Merker waren auch nur zum Fehlersuchen. Alles läuft in FB + InzDB + GlobalDB, Zugriffe über Pointer.

@ Harald
Wenn ich ein Problem mit dem Temps hätte, müsste ich dann das Problem nicht auch in der plcSim haben? Hab schon vor Ort letzte Woche mal ein CLR am FB-Anfang eingefügt, das brachte keine Besserung. Wie könnte ich rausfinden, ob es die Temp sind? Habe mir Merker in die einzelnen NW des Programms gezogen, die werden gesetzt, wenn der FB mit plcSim läuft, nicht jedoch auf der realen CPU.

Die Bausteine lassen sich ohne Fehler und Warnungen übersetzen. Auch die Variablen beim Beobachten der DBs zeigen genau das Verhalten, das sie sollten

. Ich behaupte jetzt mal, dass die Funktion fehlerfrei ist, da ich ja in der Simulation genau das Ergebnis habe, das ich möchte. Der Diagnosepuffer bringt mir auch keinen Fehler. Heute Nachmittag bekomme ich eine Test-SPS von meinem Kollegen, dann lade ich mal alles auf die und lass mich überraschen, ob ich da den gleichen Fehler bekomme. Ist zwar ne 400ter, aber besser als nichts.

Ich werde das Gefühl nicht los, dass es an der CPU und nicht am Programm liegt...

Hier mal ein Ausschnitt aus einem der beiden NW, die nicht durchlaufen werden...

Code:

      L     #DB_Nr
      T     #Ziel_DB

      AUF   DB [#Ziel_DB]

//kontrollieren
      U     #ST_1_akt                   //Merker 1. Formeintrag gesetzt
      SPB   A1

      L     #DB_Pos_Eintrag
      L     #x1
      +I    
      T     #Position_Form
      L     2
      +I    
      T     #Position_Zeit_neu

      L     #DB_Pos_Grund
      L     #g1
      +I    
      T     #Position_Grund             //Position des 1. Eintrags
      SPA   B1

A1:   L     #DB_Pos_Eintrag
      L     #x1
      +I    
      L     10
      -I    
      T     #Position_Form              //Position für folgende Einträge

      L     #DB_Pos_Grund
      L     #g1
      +I    
      L     4
      -I    
      T     #Position_Grund             //Position für folgende Einträge


B1:   L     #Position_Form
      SLD   3
      LAR1  
      L     DBW [AR1,P#0.0]             //"gestempelte" Formnummer
      L     #St_1                       //akt. Formnummer aus EA-Feld
      ==I   
      SPB   NW2

      FP    #pFL_Z_St_1
      L     #Z_St_1
      L     1
      T     #Z_St_1

//alte, bzw. defekte Formnummer merken -> Nr für Bedienmeldung der gewechselten Form
      L     DBW [AR1,P#0.0]
      T     #alt_St_1

//Button "Übernehmen" einblenden
      AUF   "L51_Schichtdaten"

      U     #HM_Form_1
      SPB   C1

      L     #DB_Pos_Button
      SLW   3
      LAR1  
      SET   
      S     DBX [AR1,P#0.0]
      S     #HM_Form_1
      SPA   X1

C1:   AUF   "L51_Schichtdaten"

      L     #DB_Pos_Button
      SLW   3
      LAR1  
      UN    DBX [AR1,P#0.0]             //Formwechsel in VISU quittiert
      SPBN  X1

      AUF   DB [#Ziel_DB]

      UN    #ST_1_akt                   //Merker 1. Formeintrag gesetzt
      SPB   D1

      L     #Position_Form
      L     2
      +I    
      T     #Position_Zeit_alt          //Position Zeitstempel, wann Form eingelegt

      L     #Position_Form
      L     10
      +I    
      T     #Position_Form              //neue Eintragsadresse für neue Formnummer
      L     2
      +I    
      T     #Position_Zeit_neu          //Position Zeitstempel der neuen Form ->Laufzeitberechnung

      L     #Position_Grund
      L     4
      +I    
      T     #Position_Grund             //neue Eintragsadresse für neue Begründungsnummer

      L     0
      T     #lz_1

//neue Formnummer + Grund schreiben
D1:   L     #x1
      L     100
      ==I                               //x=100 entspricht 10 mal Form gewechselt
      SPBN  E1a

      SET   
      R     #ST_1_akt                   //ersten Eintrag wieder freischalten
      L     #DB_Pos_Eintrag
      T     #Position_Form              //Position des 1. Eintrags
      L     2
      +I    
      T     #Position_Zeit_neu          //Position des 1. Eintrags
      L     90
      +I    
      T     #Position_Zeit_alt          //nach 10 Durchläufen, Zeitstempel der 10. Form!

      L     0
      T     #x1

E1a:  L     #g1
      L     44
      ==I   
      SPBN  E1

      L     #DB_Pos_Grund               //Formwechsel_VF_FF[1].Grund[0].x
      L     4                           //Formwechsel_VF_FF[1].Grund[1].x
      +I    
      T     #Position_Grund             //Position des 1. Eintrags  

      L     0
      T     #g1
      L     4
      T     #lz_1                       //zur Positionierung nach dem 11. Wechsel

E1:   L     #Position_Form
      SLD   3
      LAR1  
      L     #St_1                       //neue Formnummer
      T     DBW [AR1,P#0.0]             //Ziel neue Formnummer

      L     #Position_Grund
      SLD   3
      LAR1  
      L     #Grund
      T     DBW [AR1,P#0.0]

//Hilfswert für Laufzeitzuordnung
      L     #Position_Grund
      L     528
      +I    
      T     #Position_Laufzeit
      L     #g1
      +I    
      T     #Position_Laufzeit
      L     #VF_FF
      +I    
      T     #Position_Laufzeit
      L     #lz_1
      +I    
      T     #Position_Laufzeit

//Inkrementieren für nächste Einträge  
      L     #x1
      L     10
      +I    
      T     #x1

      L     #g1
      L     4
      +I    
      T     #g1

      SET   
      S     #ST_1_akt
      R     #HM_Form_1

      SPB   CLK

X1:   NOP   0

#Ziel_DB und #pFL_Z_St_1 sind Temp.
Die anderen NW für die Formen sind identisch (nur die Summen sind anders) und laufen ohne Probleme. Nach den EA-Feld-NW kommen dann noch die Zeitstempel und Kopiervorgänge.

Larry Laffer · 24 März 2015

ladychaos schrieb:
Ich werde das Gefühl nicht los, dass es an der CPU und nicht am Programm liegt....

Hallo,
mit einer 314er ist das eher unwahrscheinlich. Die macht das Aktualisieren von B&B-Variablen m.W. am Zyklus-Kontrollpunkt (also nach dem OB1-BE) und nicht während des laufenden Zyklusses. Mit einer größeren CPU (>= 317) wäre das aber auch noch eine Möglichkeit ...

Die Simulation verhält sich übrigens recht häufig nicht so 100%ig identisch mit der Realität ...

Gruß
Larry

PN/DP · 24 März 2015

Auf die Schnelle:

ladychaos schrieb:
#Ziel_DB und #pFL_Z_St_1 sind Temp.

#pFL_Z_St_1 wird als Flankenmerker bei FP benutzt --> darf deshalb nicht in TEMP liegen
Das spielt aber keine Rolle, weil die Flanke garnicht ausgewertet wird (und vor dem FP wäre das VKE sowieso IMMER TRUE wegen dem SPB).

Auf die Schnelle:

Code:

B1:   L     #Position_Form
      SLD   3
      LAR1  
      L     DBW [AR1,P#0.0]             //"gestempelte" Formnummer
      L     #St_1                       //akt. Formnummer aus EA-Feld
      ==I   
      SPB   NW2

      [COLOR="#FF0000"]FP    #pFL_Z_St_1   <-- TEMP! ist falsch[/COLOR]
      L     #Z_St_1
[COLOR="#FF0000"]      L     1
      T     #Z_St_1  <-- fehlt hier vielleicht noch ein +I ?[/COLOR]

//alte, bzw. defekte Formnummer merken -> Nr für Bedienmeldung der gewechselten Form
      L     DBW [AR1,P#0.0]
      T     #alt_St_1

//Button "Übernehmen" einblenden
      AUF   "L51_Schichtdaten"

      U     #HM_Form_1
      SPB   C1

Dein Programm ist zu umfangreich, und zeigt trotzdem nicht genug, um da einen Fehler rein am Schreibtisch zu finden. Irgendwie sehe ich keinen Zusammenhang zwischen dem Code und Deiner Programmbeschreibung im Beitrag #1. Kannst Du Dein Programm nicht erstmal auf das wesentlichste zusammenstreichen, so daß Du erstmal nur den korrekten Durchlauf (ohne Datenveränderungen) prüfen kannst?
Werden die 8 E/A-Felder nacheinander im FB bearbeitet oder wird der FB 8 mal aufgerufen?

Der Fehler kann auch noch im WinCC sein.

Harald

Ralle · 24 März 2015

PN/DP schrieb:
Auf die Schnelle:

#pFL_Z_St_1 wird als Flankenmerker bei FP benutzt --> darf deshalb nicht in TEMP liegen
Das spielt aber keine Rolle, weil die Flanke garnicht ausgewertet wird (und vor dem FP wäre das VKE sowieso IMMER TRUE wegen dem SPB).

Auf die Schnelle:

Code:

B1: L #Position_Form SLD 3 LAR1 L DBW [AR1,P#0.0] //"gestempelte" Formnummer L #St_1 //akt. Formnummer aus EA-Feld ==I SPB NW2 [COLOR=#ff0000]FP #pFL_Z_St_1 <-- TEMP! ist falsch[/COLOR] L #Z_St_1 [COLOR=#ff0000] L 1 T #Z_St_1 <-- fehlt hier vielleicht noch ein +I ?[/COLOR] //alte, bzw. defekte Formnummer merken -> Nr für Bedienmeldung der gewechselten Form L DBW [AR1,P#0.0] T #alt_St_1 //Button "Übernehmen" einblenden AUF "L51_Schichtdaten" U #HM_Form_1 SPB C1

Dein Programm ist zu umfangreich, und zeigt trotzdem nicht genug, um da einen Fehler rein am Schreibtisch zu finden. Irgendwie sehe ich keinen Zusammenhang zwischen dem Code und Deiner Programmbeschreibung im Beitrag #1. Kannst Du Dein Programm nicht erstmal auf das wesentlichste zusammenstreichen, so daß Du erstmal nur den korrekten Durchlauf (ohne Datenveränderungen) prüfen kannst?
Werden die 8 E/A-Felder nacheinander im FB bearbeitet oder wird der FB 8 mal aufgerufen?

Der Fehler kann auch noch im WinCC sein.

Harald

Doch, die Flanke wird ausgewertet, denn sie beeinflußt ja das VKE und ganz unten wird

U #HM_Form_1
SPB C1

ausgeführt, was dann nur mit der Flanke passiert oder?
Wenn jetzt die Temp-Var zufällige werte annimmt ...
Aber was genau passiert, kann man kaum sagen, ich bin mit jedenfalls nicht ganz sicher, ist auch egal, die Temp muß da weg und ohnehin muß der Code an dieser Stelle korrigeirt werden, denn wie du schon sagtest, eine Flanke von was???

ladychaos · 24 März 2015

Danke, das +I fehlt wirklich...

muss ich noch rauswerfen, das brauche ich nicht mehr. Somit fällt auch die Flanke raus, damit wollte ich nur die Häufigkeit der Wechsel mitzählen, hat sich aber dann erübrigt.

Mit der Test-CPU habe ich meinen Fehler gefunden... ich habe den Pointer für das Button-Bit falsch zusammengesetzt:

mein Code:

Code:

      L     #DB_Pos_Button
      SLW   3
      LAR1  
      UN    DBX [AR1,P#0.1]             
      SPBN  X1

lieferte an der Test-CPU den gleichen Fehler wie an meiner 300ter, interessanter Weise allerdings bei anderen Feldern.

Mit

Code:

      L     P#0.0                       //Pointer für Bit zusammensetzen
      L     #DB_Pos_Button
      SLD   3
      +D    
      L     1                           //Bit-Nr   
      +D    
      T     #point_St

      UN    DBX [#point_St]             
      SPBN  X1

geht es jetzt bei allen Feldern.

Jetzt stellt sich mir nur noch die Frage, warum das die plcSim so einfach gefressen hat...

PN/DP · 24 März 2015

Ralle schrieb:
Doch, die Flanke wird ausgewertet, denn sie beeinflußt ja das VKE und ganz unten wird

U #HM_Form_1
SPB C1

ausgeführt

Ja böse Falle! Du hast recht.
Der falsche FP beeinflußt das "U #HM_Form_1", weil es außerdem bis zu dem "U #HM_Form_1" auch keine VKE-Abgrenzung gibt, das VKE wird zu dem "U #HM_Form_1" verschleppt, es wird keine neue Verknüpfung angefangen, sondern mit dem zufälligen VKE vom FP verknüpft.

Harald

PN/DP · 24 März 2015

ladychaos schrieb:
Mit der Test-CPU habe ich meinen Fehler gefunden... ich habe den Pointer für das Button-Bit falsch zusammengesetzt:

mein Code:

Code:

L #DB_Pos_Button SLW 3 LAR1 UN DBX [AR1,P#0.1] SPBN X1

lieferte an der Test-CPU den gleichen Fehler wie an meiner 300ter, interessanter Weise allerdings bei anderen Feldern.

Mit

Code:

L P#0.0 //Pointer für Bit zusammensetzen L #DB_Pos_Button SLD 3 +D L 1 //Bit-Nr +D T #point_St UN DBX [#point_St] SPBN X1

geht es jetzt bei allen Feldern.

Hmm, Dein erster "falscher" Code kommt in dem uns in Beitrag #4 gezeigten Code garnicht vor???
Außerdem ergibt der zweite (umständlichere) Code die selbe Zugriffsadresse wie der erste Code, solange #DB_Pos_Button kleiner 8192 ist.

War da vielleicht einfach nur ein Tippfehler bei "[AR1,P#0.1]"?
Welchen Wert hatte #DB_Pos_Button?

Harald

ladychaos · 25 März 2015

oh, dann habe ich den Code aus NW2 erwischt... Die Funktion bleibt aber die gleiche.
Die Pointer werden je nach Button ( 1-8 ) auf
NW1: Button 1 : [AR1,P#0.0]
NW2: Button 2 : [AR1,P#0.1]
NW3: Button 3 : [AR1,P#0.2] usw.
beschrieben. #DB_Pos_Button hat je nach Instanz Werte zw. 684.0 und 704.7

PN/DP · 25 März 2015

ladychaos schrieb:
Wenn ich ein Problem mit dem Temps hätte, müsste ich dann das Problem nicht auch in der plcSim haben?

Für mich erklärt sich Dein Problem einleuchtend durch die unsaubere Test-Leiche: das FP auf TEMP ohne nachfolgende VKE-Abgrenzung.
(siehe meine Erklärung in Beitrag #9)

PLCSIM und die Test-CPU arbeiten mit völlig anderen Eingangswerten als die CPU an der echten Anlage. Daher kann es sein, daß in der Anlagen-CPU irgendein Baustein an der Stackadresse, welche von dem "FP #pFL_Z_St_1" benutzt wird, ein TRUE hinterläßt und dadurch der Sprung "U #HM_Form_1 / SPB C1" nie ausgeführt wird und dadurch #HM_Form_1 und "DBX [AR1,P#0.0]" immer gesetzt werden, wodurch vermutlich der Button "Übernehmen" ständige eingeblendet wird.

Harald

PN/DP · 25 März 2015

ladychaos schrieb:
#DB_Pos_Button hat je nach Instanz Werte zw. 684.0 und 704.7

Ich meine nicht, welche Adresse die Variable #DB_Pos_Button hat, sondern welcher Dezimalwert da drin steht.

Falls da wirklich schon eine Adresse drinsteht, dann erkläre mal bitte den Sinn der SLW/SLD:

ladychaos schrieb:

Code:

      L     #DB_Pos_Button
      [COLOR="#FF0000"]SLW   3[/COLOR]
      LAR1

[...]

Code:

      L     #DB_Pos_Button
      [COLOR="#0000FF"]SLD   3[/COLOR]

Harald

Step 7 FB wird nicht richtig aufgerufen

ladychaos

Level-1

mikeh

Level-1

PN/DP

User des Jahres 2011-2013; 2015-2017; 2020-2022

ladychaos

Level-1

Larry Laffer

Super-Moderator , User des Jahres 2008-2009

PN/DP

User des Jahres 2011-2013; 2015-2017; 2020-2022

Ralle

Super-Moderator , User des Jahres 2006-2007

ladychaos

Level-1

PN/DP

User des Jahres 2011-2013; 2015-2017; 2020-2022

PN/DP

User des Jahres 2011-2013; 2015-2017; 2020-2022

ladychaos

Level-1

PN/DP

User des Jahres 2011-2013; 2015-2017; 2020-2022

PN/DP

User des Jahres 2011-2013; 2015-2017; 2020-2022

Similar threads

Wir schützen deine Privatsphäre