TIA PUT Status 16#0014 wie automatisch beheben?

vollmi

Level-3
Beiträge
5.425
Reaktionspunkte
1.403
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é
 
Hatte den Fehler nie, aber hast du mal versucht den InstanzDB neu runterzuladen, wenn der Fehler aufgetreten ist?
 
Zuviel Werbung?
-> Hier kostenlos registrieren
• 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
 
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é
 
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 :cool:
Aber was dagegen tun?

...
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 :oops:.
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.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
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é
 
Hi René

...
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

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.
 
Zurück
Oben