Step 7 SFC67 X_Get -> Fehler 80C0

Betriebselektriker28

Betriebselektriker28

Level-2
Beiträge
622
Reaktionspunkte
67
Zuviel Werbung?
-> Hier kostenlos registrieren
Guten Morgen,

ich habe hier ein "kleines" Problem. Vielleicht kann mir ja jemand helfen. ;)

Grundaufbau:

1x S7 CPU317
2x Vipa Speed 7


Die CPU´s sind per MPI Bus verbunden.

Die beiden Vipa´s holen sich per X_GET 240 Bytes an Daten von der S7
Die S7 holt sich ebenfalls per X_GET Daten von den beiden Vipa SPS

Das funktioniert aber nur sporadisch, manchmal kommen 20 Sekunden lang keine neuen Daten!
Mir ist aufgefallen das bei RET_Val sehr oft der Fehler 80C0 ausgegeben wird.
Also: "Die angegebene Verbindung ist durch einen anderen Auftrag bereits belegt"

Woran kann das liegen? Habe schon mal testweise eine der Vipas gestoppt, das macht es aber auch nicht besser...
Außerdem mal zwischen den Aufträgen die Verbindung abgebaut(also Cont auf 0), macht es nur langsamer nicht besser.

Hier der Programmcode von einer VIPA, die andere ist genau so programmiert.
Req wird immer erst gesetzt wenn der vorige Auftrag beendet ist und beginnt dann wieder von vorne wenn alle 4 Aufträge bearbeitet sind.

Code: 
NETWORK
TITLE =Kommunikation mit Server MPI 2
//      SPA   M001

      CALL "X_GET" (
           REQ                      := DB8.DBX   20.0,//DB8.DBX20.0  M2.3 
           CONT                     := "Daten Allgemein".DB_VAR19,//Verbindung aufrecht erhalten (Ja/Nein)?   
           DEST_ID                  := W#16#2,//Empfängeradresse
           VAR_ADDR                 := P#DB33.DBX0.0 BYTE 60,//Variablenadresse im Kommunikationspartner
           RET_VAL                  := "Transfer Text PC --> SPS".DB_VAR6841,//Statusanzeige, negativ wenn ein Fehler auftritt
           BUSY                     := DB8.DBX   20.1,//SFC aktiv?
           RD                       := P#DB33.DBX0.0 BYTE 60);//Pointer auf die Adresse, in die die Empfangsdaten geschrieben werden
      U     DB8.DBX   20.1; 
      FN    DB8.DBX   20.2; 
      S     DB8.DBX   20.3; 
      R     DB8.DBX   20.0; 
 
      CALL "X_GET" (
           REQ                      := DB8.DBX   20.3,
           CONT                     := "Daten Allgemein".DB_VAR19,//Verbindung aufrecht erhalten (Ja/Nein)?   
           DEST_ID                  := W#16#2,//Empfängeradresse
           VAR_ADDR                 := P#DB33.DBX60.0 BYTE 60,//Variablenadresse im Kommunikationspartner
           RET_VAL                  := "Transfer Text PC --> SPS".DB_VAR6841,//Statusanzeige, negativ wenn ein Fehler auftritt
           BUSY                     := DB8.DBX   20.4,//SFC aktiv?
           RD                       := P#DB33.DBX60.0 BYTE 60);//Pointer auf die Adresse, in die die Empfangsdaten geschrieben werden
      U     DB8.DBX   20.4; 
      FN    DB8.DBX   20.5; 
      S     DB8.DBX   20.6; 
      R     DB8.DBX   20.3; 

      CALL "X_GET" (
           REQ                      := DB8.DBX   20.6,
           CONT                     := "Daten Allgemein".DB_VAR19,//Verbindung aufrecht erhalten (Ja/Nein)?   
           DEST_ID                  := W#16#2,//Empfängeradresse
           VAR_ADDR                 := P#DB33.DBX120.0 BYTE 60,//Variablenadresse im Kommunikationspartner
           RET_VAL                  := "Transfer Text PC --> SPS".DB_VAR6841,//Statusanzeige, negativ wenn ein Fehler auftritt
           BUSY                     := DB8.DBX   20.7,//SFC aktiv?
           RD                       := P#DB33.DBX120.0 BYTE 60);//Pointer auf die Adresse, in die die Empfangsdaten geschrieben werden
 
      U     DB8.DBX   20.7; 
      FN    DB8.DBX   21.0; 
      R     DB8.DBX   20.6; 
      S     DB8.DBX   21.1; 

      CALL "X_GET" (
           REQ                      := DB8.DBX   21.1,
           CONT                     := "Daten Allgemein".DB_VAR19,//Verbindung aufrecht erhalten (Ja/Nein)?   
           DEST_ID                  := W#16#2,//Empfängeradresse
           VAR_ADDR                 := P#DB37.DBX0.0 BYTE 60,//Variablenadresse im Kommunikationspartner
           RET_VAL                  := "Transfer Text PC --> SPS".DB_VAR6841,//Statusanzeige, negativ wenn ein Fehler auftritt
           BUSY                     := DB8.DBX   21.2,//SFC aktiv?
           RD                       := P#DB37.DBX0.0 BYTE 60);//Pointer auf die Adresse, in die die Empfangsdaten geschrieben werden
      U     DB8.DBX   21.2; 
      FN    DB8.DBX   21.3; 
      R     DB8.DBX   21.1; 
//    S     DB8.DBX   20.0
      NOP   0;

Irgendwer eine Idee woran es liegen könnte? :idea:

Danke für eure Zeit!
 
Zuletzt bearbeitet:
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo Harald,

Den von dir verlinkten Thread hatte ich vorher schon gefunden, da sind wirklich sehr hilfreiche Informationen drinn, aber nichts scheint mein Problem zu erklären.
Die 4 Aufrufe werden ja schön getrennt hintereinander bearbeitet.

Ich habe im Rest vom Programm der VIPA keinen X_GET oder X_PUT Aufruf mehr gefunden.
Gesucht habe ich über die Programmstruktur in den Referenzdaten...

Das die CPU 317 gleichzeitig X_GET Zugriffe auf der VIPA macht, kann ja wohl nicht der Grund sein, oder? :confused:


Das ganze ist eine Steuerung zur Betriebsdatenerfassung/Auftragswahl.

Diese hat z.b. immer schon extrem zäh auf Eingabe an den Bedienpanels reagiert, bzw Probleme mit der richtigen Stückzählung.
Manchmal muss man eine Taste Sekundenlang halten bis endlich eine Reaktion erfolgt.
Die OP7 Panels sind an die S7 über Profibus angeschlossen, dann holt sich die VIPA die Daten, und die S7 holt sich quasi die Antwort von der VIPA...



Ich habe dieses Spitzensystem nun leider geerbt und würde das gerne mal in den Griff kriegen.
Von den Dingern Also jeweils eine S7+2Vipas) haben wir insgesamt 3 Stück im Werk verteilt, und alle funktioneren gleich "toll". :rolleyes:


Die Programme sind jeweils ziemlich identisch.
Es scheint sich hier also um einen grundlegenden Fehler zu handeln.


Da die VIPA ja eine S7-318 "simuliert" müsste X_GET eigentlich funktioneren. ;)

lg
Michael
 
Funktioniert der MPI-Bus ordnungsgemäß? Sind die Busabschlußwiderstände korrekt gesetzt? Wie lang ist der MPI-Bus? (MPI ist elektrisch fast identisch zu Profibus, es müssen die selben Vernetzungsregeln beachtet werden)
Kommst Du per MPI auf die CPUs und kannst das Programm normal beobachten?

Harald
 
Betriebselektriker28 schrieb:
Das die CPU 317 gleichzeitig X_GET Zugriffe auf der VIPA macht, kann ja wohl nicht der Grund sein, oder? :confused:
Zum Vergrößern anklicken....
Auf einer MPI-Verbindung (S7-Basiskommunikation) kann nur ein einziger X_GET/X_PUT-Auftrag gleichzeitig aktiv sein.
Verschiebe die X_GET-Aufträge vom Programm der 317 in X_PUT-Aufträge im VIPA-Programm. Dann können die X_GET/X_PUT-Aufträge sauber verriegelt werden.

Harald
 
Zuviel Werbung?
-> Hier kostenlos registrieren
PN/DP schrieb:
Auf einer MPI-Verbindung (S7-Basiskommunikation) kann nur ein einziger X_GET/X_PUT-Auftrag gleichzeitig aktiv sein.
Verschiebe die X_GET-Aufträge vom Programm der 317 in X_PUT-Aufträge im VIPA-Programm. Dann können die X_GET/X_PUT-Aufträge sauber verriegelt werden.

Harald
Zum Vergrößern anklicken....

Das wäre ja super wenn das mal funktioniert...

Angenommen ich realisiere das nun in VIPA SPS 1
Dann wäre dann natürlich noch VIPA SPS 2, die ja ebenfalls zeitgleich auf die S7 317 zugreift.

Stört das dann nicht ebenso? :confused:


Also anders gefragt:
Wäre es nicht besser alles in der 317er zu programmieren?
Die VIPAS kommunizieren untereinander übrigens nicht...



Zur MPI Verbindung:
Alles zusammen kommt da wohl so ~1m Leitungslänge zusammen, die 3 Steuerungen sitzen jeweils alle in einem Schrank. :rolleyes:
Ist auch ordnungsgemäß verkabelt/terminiert soweit ich das beurteilen kann.

Geschwindigkeit ist 187,5kbit, also auch da eher auf der sicheren Seite.


Das ganze läuft jetzt schon Jahrelang so holprig und war gar nicht billig...wurde von einer externen Firma programmiert. :shock:
 
Zuletzt bearbeitet:
Ja natürlich, kannst auch alles in der 317 programmieren. Es müssen nur die Aufträge je Verbindung verriegelt werden, die 317 kann je 1 Auftrag an die Vipa1 und die Vipa2 gleichzeitig starten.

Harald
 
Also sind schon mehrere Verbindungen zeitgleich möglich, müssen aber an unterschiedliche MPI Adressen gehen. Stimmt das passt ja auch zur Hilfe zum 80C0 Fehler. :icon_idea:


Heißt das im Umkehrschluss auch das ich mit beiden Vipa´s gleichzeitig auf die 317er zugreifen kann?
Immerhin greifen ja dann beide gleichzeitig auf MPI 2 zu...
Oder ist das wiederum kein Problem da es ja unterschiedliche Verbindungen sind?

Nur damit ich das endlich mal verstehe was ich darf und was nicht. :wink:
 
Zuletzt bearbeitet:
Zuviel Werbung?
-> Hier kostenlos registrieren
Betriebselektriker28 schrieb:
Heißt das im Umkehrschluss auch das ich mit beiden Vipa´s gleichzeitig auf die 317er zugreifen kann?
Zum Vergrößern anklicken....
Ja, weil das sind 2 verschiedene Verbindungen. Die können gleichzeitig bestehen und auf jeder kann 1 X_PUT- oder X_GET-Auftrag laufen.
Verbindung_1: 317 --- Vipa_1
Verbindung_2: 317 --- Vipa_2

Harald
 
Habe das diese Woche mal getestet:

Zuerst die komplette Kommunikation auf einer Vipa programmiert, mit XPut und XGet, und in der S7 auskommentiert.
Leider immer noch sehr oft 80C0 im Retval. :confused:

Dabei fiel mir auch auf das die Zykluszeit der Vipas zw 80 und 160ms variiert...das macht die Sache auch nicht schneller.


Also habe ich jetzt die komplette Kommunikation zu den zwei Vipas auf der S7 programmiert, die hat keine 10ms Zykluszeit.
Natürlich immer noch 80C0 Fehler ohne Ende, aber durch die reinen Masse an Kommunikationsversuchen ist die Kommunikation ausreichend schnell und alle
Maschineführer sind begeistert wie schnell die OP7 nun auf Eingaben reagieren. :ROFLMAO:

Ich hingegen bin nicht ganz zufrieden, weil ich immer noch nicht weiß warum zum Teufel ich noch immer 80C0 Fehler bekomme. :oops:
 

Similar threads

T
Step 7 ASI-Fehler erkennen
Antworten
4
Aufrufe
6K
Clyde82
C
S
TIA X_GET und X_PUT auf collision detection Verfahren vertrauen?
Antworten
9
Aufrufe
3K
M-Ott
M
M
Sfc 72 wie Verwalten ???
Antworten
0
Aufrufe
2K
Montancy
M
D
X_PUT Syntax mit SCL
Antworten
3
Aufrufe
3K
Ralle
Ralle
Zurück
Oben