Zuviel Werbung? - > Hier kostenlos beim SPS-Forum registrieren

Ergebnis 1 bis 7 von 7

Thema: PUT Status 16#0014 wie automatisch beheben?

  1. #1
    Registriert seit
    22.11.2006
    Ort
    CH
    Beiträge
    3.620
    Danke
    777
    Erhielt 647 Danke für 493 Beiträge

    Standard


    Zuviel Werbung?
    -> Hier kostenlos registrieren
    Hi zusammen

    Ich habe hier einen sporadischen Fehler mit einem Put bzw mit einigen Puts

    Irgendwann bringen sie im Status den Wert Status 16#0014 und setzen das Error Flag. Ab da geht dann keine Kommunikation mehr.

    Es hilft dann nur noch ein Neustart der CPU (Stop/Run schalter).

    Wann genau das Auftritt konnte ich noch nicht nachvollziehen. Aber Offenbar dann wenn ich mit dem PG viele Programmänderungen konsistent runterlade kann das passieren.

    In der hilfe

      • Maximale Anzahl paralleler Aufträge/Instanzen ist überschritten
      • Die Instanzen wurden bei CPU-RUN überladen (STOP-RUN-Übergang der CPU oder des CP ist erforderlich)
      • Ist beim Erstaufruf möglich
    Erstaufruf kann ich ausschliessen.
    den zweiten Punkt verstehe ich nicht ganz. Aber offenbar hilft Stop-Run.
    Aufträge kann ich vermutlich ausschliessen, da in 99% der Zeit beide Put im Programm funktionieren und URECV auch.

    Die gehen zwar alle über dieselbe projektierte Verbindung aber das hat bisher noch nie gestört.

    Kann den Fehler jemand nachvollziehen und ihn mir erklären? Und vor allem. Ist es möglich das ganze wärend der Runtime wieder anzustossen?

    mfG René
    Zitieren Zitieren PUT Status 16#0014 wie automatisch beheben?  

  2. #2
    Registriert seit
    21.10.2010
    Beiträge
    158
    Danke
    21
    Erhielt 29 Danke für 17 Beiträge

    Standard

    Hatte den Fehler nie, aber hast du mal versucht den InstanzDB neu runterzuladen, wenn der Fehler aufgetreten ist?

  3. Folgender Benutzer sagt Danke zu funkey für den nützlichen Beitrag:

    vollmi (09.10.2013)

  4. #3
    Registriert seit
    22.06.2009
    Ort
    Sassnitz
    Beiträge
    11.192
    Danke
    925
    Erhielt 3.292 Danke für 2.661 Beiträge

    Standard

    Zitat Zitat von vollmi Beitrag anzeigen
    • Die Instanzen wurden bei CPU-RUN überladen (STOP-RUN-Übergang der CPU oder des CP ist erforderlich)
    Wie bei jedem FB ist es auch bei PUT/GET nicht ratsam, im RUN einen neuen Instanz-DB zu laden - insbesondere wenn gerade ein Kommunikationsauftrag läuft und PUT/GET in dem IDB wichtige Statusinformationen hält.

    Das Problem wirst Du wohl nur umgehen können, wenn Du Dir extra einen Programmteil zum Anhalten der Kommunikation schreibst.
    Du könntest vor dem Laden mit dem PG einen Merker (oder Multi-IDB-Bit) setzen, der auf das nächste DONE oder ERROR wartet und danach den Aufruf der PUT/GET-Instanz verhindert. Nach dem Laden kannst Du mit dem PG den Merker rücksetzen und die Kommunikation startet neu. Oder das Bit ist im Multi-IDB mit Aktualwert FALSE, dann startet die Kommunikation automatisch nach dem Laden des IDB.

    PS: welche CPU?

    Harald
    Es ist immer wieder überraschend, wie etwas plötzlich funktioniert, sobald man alles richtig macht.

    FAQ: Linkliste SIMATIC-Kommunikation über Ethernet

  5. Folgender Benutzer sagt Danke zu PN/DP für den nützlichen Beitrag:

    vollmi (09.10.2013)

  6. #4
    Avatar von vollmi
    vollmi ist offline Erfahrener Benutzer
    Themenstarter
    Registriert seit
    22.11.2006
    Ort
    CH
    Beiträge
    3.620
    Danke
    777
    Erhielt 647 Danke für 493 Beiträge

    Standard

    Ich war mir eben nicht mehr sicher ob ich den IDB auch nochmal runtergeladen habe. Eigentlich hätte das unnötig sein müssen da ich in der Schnittstelle nichts mehr verändert hatte.
    Wenn das wirklich aufs PG zurückzuführen ist könnte ich damit leben.

    Ein wegnehmen und wiederbringen des REQ hat eben auch nichts gebracht. Das hab ich im Baustein standardmässig drin falls ein Auftrag mal ungewöhnlich lange brauchts nehme ich REQ weg und bringe ihn erneut.

    Achja ist eine 317PN/DP mit einem gesteckten Lean CP den ich für die S7 kommunikation nutze.

    mfG René

  7. #5
    Registriert seit
    24.04.2013
    Beiträge
    309
    Danke
    23
    Erhielt 160 Danke für 88 Beiträge

    Standard

    Hi

    PN/DP hat ganz recht, die Instanzen von asynchronen Funktionen zu laden, während dies gerade arbeiten ist keine gute Idee. Alle Funktionen, die REQ, BUSY, DONE und ERROR Parameter haben sind gefährdet. Sogar READ_DBL und WRIT_DBL, obwohl das SFC sind. Aber die mögen es auch nicht "gestört" zu werden. Es macht auch gar keinen Unterschied, ob du eine 300,400,1200 oder 1500 hast. Ich hab sie alle schon an die Wand gefahren
    Aber was dagegen tun?

    Zitat Zitat von PN/DP Beitrag anzeigen
    ...
    Das Problem wirst Du wohl nur umgehen können, wenn Du Dir extra einen Programmteil zum Anhalten der Kommunikation schreibst.
    Du könntest vor dem Laden mit dem PG einen Merker (oder Multi-IDB-Bit) setzen, der auf das nächste DONE oder ERROR wartet und danach den Aufruf der PUT/GET-Instanz verhindert. Nach dem Laden kannst Du mit dem PG den Merker rücksetzen und die Kommunikation startet neu. ...
    Daran habe ich mich schon mal versucht. Bin aber an meiner eigenen Schusseligkeit gescheitert oder war es der Zeitdruck .
    Wer denkt schon immer dran, dass er vor dem Laden in die VAT wechselt, und dort eine Variable steuert um die asynchronen Tätigkeiten im Programm zu verriegeln.
    Außerdem muss man ja überall im Programm diese Variable abfragen.
    In einer Library funktion ist das schon wieder blöd, denn dort soll man ja nicht auf was globales zugreifen. D.h. alle Bausteine bekommen einen Parameter mehr. Gar nicht schön

    Während ich das so schreibe, wundere ich mich, dass das nicht noch viel öfter schief geht. Während einer Inbetriebnahme kommt es schon mal vor, dass ich alle drei Minuten irgendwas lade. Und da ist eigentlich immer irgend eine Kommunikation im Programm. Trotzdem begegne ich dem Fehler nur alle paar Monate. OK die Instanzen von asynchronen mögen da seltener bei sein, aber als Mutliinstanz ... Und beim Portal mit der Konsistenzprüfung ist sowieso oft mehr dabei als mir lieb ist. Im August hatte ich ein großes Projekt mit mehr als 10 1214 und mehr als 5 1516 und das kam kein einziges mal vor.

    Wenn es nicht wirklich sporadisch ist, dann kannst du folgendes versuchen. Wenn der Fehler auftritt, dann nimm REQ weg und mach die Instanz platt. Also alles was zum PUT/GET, SEND/RECV gehört auf 0 setzen. Danach wieder die Instanz füllen und schließlich REQ wieder true. Schon klar, was jetzt wieder als Gegenargument kommt: "ich hab die Instanzdaten aber nicht durch das Programm gesetzt sondern durch das PG." Dann musst du dir in einem OB eine Kopie dieser Instanzdaten machen. Das kann mann ganz gut mit dem durch PN/DP beschriebenen Trick automatisieren ohne dass es dauernd Zeit frisst. Und sind die Daten retain, dann kann man sie sogar im OB100 zum initiieren verwenden.

  8. Folgender Benutzer sagt Danke zu HelleBarde für den nützlichen Beitrag:

    vollmi (10.10.2013)

  9. #6
    Avatar von vollmi
    vollmi ist offline Erfahrener Benutzer
    Themenstarter
    Registriert seit
    22.11.2006
    Ort
    CH
    Beiträge
    3.620
    Danke
    777
    Erhielt 647 Danke für 493 Beiträge

    Standard

    Ich hatte das Verhalten halt genau bei diesem Projekt (das erste grössere mit TIA) ein paar mal und hab halt gedacht vielleicht liegt der Fehler effektiv in meinem Programm.
    Aber es scheint nun echt so dass das am überschreiben des Instanzdbs liegt. Was TIA nun doch öfter als eigentlich wirklich nötig anbietet.

    z.B. ich habe in meinem KommunikationsFB zugriffe auf meine DBs die ich an andere Stationen übertrage. Deren länge ändert sich hat bei Programmänderungen. Also muss der Pointer ja angepasst werden. Von P#DB167.DBX0.0 BYTE 872 nach P#DB167.DBX0.0 BYTE 894 .

    Da würde ich jetzt sagen wäre es nicht nötig den IDB mit runterzuladen. Beim Konsistenten Runterladen wird der aber auf jeden Fall mit angehakt. Und ich mag es halt, wenn alle Punkte grün sind

    mfG René

  10. #7
    Registriert seit
    24.04.2013
    Beiträge
    309
    Danke
    23
    Erhielt 160 Danke für 88 Beiträge

    Standard


    Zuviel Werbung?
    -> Hier kostenlos registrieren
    Hi René

    Zitat Zitat von vollmi Beitrag anzeigen
    ...
    Deren länge ändert sich hat bei Programmänderungen. Also muss der Pointer ja angepasst werden. Von P#DB167.DBX0.0 BYTE 872 nach P#DB167.DBX0.0 BYTE 894 .
    "Wat mut dat mut" sacht man hier

    Zitat Zitat von vollmi Beitrag anzeigen
    Beim Konsistenten Runterladen wird der aber auf jeden Fall mit angehakt. Und ich mag es halt, wenn alle Punkte grün sind
    Ja, grün ist gut. Das mit dem konsistenten Runterladen ist Segen und Fluch.

    Du machst eine echte Änderung am DB, z.B. zusätzliche Variable hinten dran hängen, und alle verwendenden Baustein gehen über die Leitung. Das find ich schon heftig, und war bei der 300/400 nicht nötig. Wenn man die Variable mitten rein fügt, dann war das auch bei der 300/400 so, denn durch die Verschiebung aller folgender Variablenadressen ist das nötig. Das es jetzt bei 1200/1500 immer so ist Aber irgendwie zu akzeptieren.

    Du machst eine "falsche" Änderung am DB, z.B. änderts einen Startwert oder noch unverständlicher einen Kommentar. Und wieder gehen alle verwendenden Bausteine über die Leitung. Das ist Zeitverschwendung.

    Fazit: Um alles grün zu bekommen, muss man viel zu viel runter laden.

Ähnliche Themen

  1. PUT / GET in SCL
    Von Carsten77 im Forum Simatic
    Antworten: 10
    Letzter Beitrag: 17.12.2012, 23:09
  2. HW-Inkonsistenz bei altem S7 Projekt beheben
    Von vollmi im Forum Simatic
    Antworten: 7
    Letzter Beitrag: 04.05.2011, 10:12
  3. Wie den Status der CPU-LED "SF" abfragen?
    Von Spud im Forum Simatic
    Antworten: 11
    Letzter Beitrag: 22.12.2008, 23:25
  4. Antworten: 0
    Letzter Beitrag: 22.01.2008, 09:50
  5. Antworten: 12
    Letzter Beitrag: 19.09.2007, 07:47

Lesezeichen

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •