Step 7 AGSEND fehlerhaft?

O

OKL

Level-1
Beiträge
143
Reaktionspunkte
3
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo Gemeinde,

ich verwende eine ältere 300er SPS, 2AF03 und einen CP 1EX11.

Jetzt nutze ich seit Jahren einen HTTP-Request über AGSEND, das funktionierte gut, jedoch sendete ich damit sehr selten Nachrichten, sodass ich nicht bemerkte, dass aufeinander folgende ein Problem darstellen. Soll heißen, sende ich zwei Nachrichten innerhalb von einigen Minuten, kommt die erste an, die zweite nicht, die dritte aber kurz darauf wieder mit Erfolg. Wartet man einige Stunden, kommt auch die zweite Nachricht an.

Hier der eigentliche Aufruf. Pushover-Start wird gesetzt, wenn etwas gesendet werden soll. Der Aufruf funktioniert, jedoch wird das DONE beim ersten Aufruf nach 2 Sekunden gesetzt, die Nachricht wird gesendet. Der zweite Aufruf erfolgt genau so, hier wird das DONE aber sofort gesetzt, obwohl die Nachricht eben nicht raus ist, im selben Zyklus wie der Aufruf selbst. Beim dritten wieder Normalität, AGSEND verbindet sich und so weiter. Es wird aber auch kein Error geworfen. Pushover_Start wird quasi auch gleich wieder zurück gesetzt. Nun könnte ich das bestimmt verzögern, indem ich das für 1 Sekunde gesetzt lasse und es noch einmal gesendet wird, ist mir aber eigentlich nicht recht.

Die Firmware von dem CP ist 2.3.5, der AGSEND ist von 2004. Sind derartige Probleme bekannt?

Ich danke euch.

U "Pushover_Start"
ZV Z 4






CALL "AG_SEND"
ACT :="Pushover_Start"
ID :=1
LADDR :=W#16#100
SEND :="DB_Pushover".NR1
LEN :=184
DONE :=M104.0
ERROR :=#ERROR
STATUS:=#STATUS


UN M 104.0
SPB ende
L MW 210
+ 1
T MW 210


R "Pushover_Start"
ende: CLR
 
Bin mir nicht ganz sicher, aber:

Done und Error kommen bei einigen Bausteinen jeweils nur für einen Zyklus.
D.h. du könntest den Error durchaus verpassen.

Deshalb auf jeden Fall:

UN M 104.0
UN Error
SPB ende
L MW 210
+ 1
T MW 210

Auch #Status sollte im Error-Fall gespeichert werden:

UN ERROR
SPB KERR

L #STATUS
T MyStatVar

KERR: NOP 0
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo Ralle,

Danke für die Tipps. Verrückt, wenn der Durchlauf funktioniert und die Nachricht gesendet wird, bekomme ich als Fehler 8183 zurück. Beim nächsten Aufruf erhalte ich dann Fehler 0, die Nachricht geht aber nicht raus. Beim Übernächsten Versuch wieder 8183 und eine gesendete Nachricht.
 
Ich hoffe, es hat noch jemand eine Idee, wenn die Hälfte der Nachrichten nicht ankommen (nebst Alarmierungen), ist das schon ein Problem..
 
Mache mal den Sende-Anstoß nur 1 Zyklus lang:
Code: 
U "Pushover_Start"
FP M104.7
= #SEND_ACT

CALL "AG_SEND"
 ACT   :=#SEND_ACT
 ...
 DONE  :=#DONE
 ERROR :=#ERROR
 STATUS:=#STATUS


U #ERROR
O #SEND_ACT //(debug)
O #DONE     //(debug)
SPBN KERR

L #STATUS
T #MyStatVar

KERR: SET

OKL schrieb:
Die Firmware von dem CP ist 2.3.5, der AGSEND ist von 2004.
Zum Vergrößern anklicken....
AG_SEND sollte Version 4.2 sein, Firmware CP ist OK, Firmware der CPU sollte V1.2.1 sein

Harald
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo Harald,

danke für deine Mühe. Der Baustein hat die Version 4.2, meine CPU zeigt mir online die Version 1.1.0 an, der CP in der Hardwareconfig die 2.0, online die 2.3.5. Wie lässt sich ein Firmwareupdate der CPU realisieren? Benötige ich da einen Eprom?

Den Tipp habe ich umgesetzt, leider dasselbe Verhalten. Wenn das Senden i. O. war, Fehler 8183, der nächste Versuch scheitert, danach klappt es wieder.
[FONT=Verdana,Arial,Tahoma,Calibri,Geneva,sans-serif]
[/FONT][FONT=Verdana,Arial,Tahoma,Calibri,Geneva,sans-serif]
Code: 
[/FONT]
[FONT=Verdana,Arial,Tahoma,Calibri,Geneva,sans-serif][FONT=Verdana,Arial,Tahoma,Calibri,Geneva,sans-serif]      U     "Pushover_Start"
      FP    M    104.7
      =     #send_act[/FONT]
[FONT=Verdana,Arial,Tahoma,Calibri,Geneva,sans-serif]      CALL  "AG_SEND"
       ACT   :=#send_act
       ID    :=1
       LADDR :=W#16#100
       SEND  :="DB_Pushover".NR1
       LEN   :=184
       DONE  :=#DONE
       ERROR :=#ERROR
       STATUS:=#STATUS
      U     #ERROR
      O     #send_act                   //(debug)
      O     #DONE                       //(debug)
      SPBN  KERR[/FONT]
[FONT=Verdana,Arial,Tahoma,Calibri,Geneva,sans-serif]      L     #STATUS
      T     MW   212[/FONT]
[FONT=Verdana,Arial,Tahoma,Calibri,Geneva,sans-serif]KERR: SET [/FONT]
[/FONT]
 
Hast du mal nachgesehen, was 8183 bedeutet?
Mit Maus auf den Baustein klicken und dann "F1", sollte die Hilfe zum Baustein öffnen.
Scheint so, als würde das Senden nicht korrekt abgeschlossen, bzw. quittiert.
 
Wenn du ein http-Request absendest, dann kommunizierst du vermutlich mit einem Webserver.
Die TCP Verbindung baut aber der CP auf und hält diesen die ganze Zeit geöffnet. Das wird bei http aber nur in ganz seltenen Fällen so gemacht.
Normalfall ist, TCP-Verbindung aufbauen, http-request, http-response und trennen.
Kommt auf die Einstellung im CP für die Verbindung an, ob es dort keep-Alive Telegramme gibt. Allerdings werden viele Webserver die Verbindung von selber wieder trennen, wenn du nach dem Aufbau keine Daten schickst, oder er gibt die Ressourcen schon wieder frei. Oder dein CP denkt die Verbindung ist noch offen, der Webserver hat die Ressourcen schon wieder freigegeben.

Vermutlich wird dann beim ersten Mal nachdem nach langer Zeit die Verbindung wirklich genutzt wird festgestellt, dass die Verbindung nicht mehr funktioniert. Der CP baut neu auf, und wenn du dann über die neue Verbindung sendest, dann funktioniert es.

Sinnvoll wäre es darum die Verbindung aus dem Programm heraus nur bei Bedarf zu aktivieren und anschließend wieder zu trennen. Das ist auch bei projektierten Verbindungen möglich.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Also, ich habe Neuigkeiten.
Die Karte treibe ich auf, dann bringe ich das alte Mädchen auf den neuesten Stand.

Der Fehler wird bei Siemens so beschrieben, ich las aber auch schon andere Hinweise dazu.

Richtig, es ist ein Webserver, ich rufe eine PHP-Seite auf und übergebe eine Nummer, die Seite verbindet sich mit Pushover und schon habe ich, theoretisch zumindest, immer fix und unkompliziert eine Nachricht. Die Antwort frage ich jedoch nicht ab, bin schon froh, dass ich überhaupt das Aufrufen hinbekomme. ;)

Die leicht abgeänderte (nicht dass ich hier ständig Nachrichten bekomme) Syntax des lautet: GET /aufrufdatei.php?nummer=0001&nachricht=ABCD HTTP/1.1$R$LHOST: 99.999.99.99$R$L$R$L$R$L$R$L$R$L$R$L$R$L$R$L$R$L

Nummer und Nachricht werden hier übergeben, den Rest macht die PHP-Datei (Prioritäten, Sound etc.)

Thomas, ich habe eine Verbindung im Netpro angelegt. Lokal mit der IP des CP und entfernt die des Webservers. Aktiver Verbindungsaufbau, Ports wie verwendet. Sollte ich hier etwas ändern? Benötige ich dann den AG_Ctrl Baustein?

Meine neuen Erkenntnisse: Ich habe einen zweiten Webserver testen können, von uns auf Arbeit. Der verhält sich anders, lässt das aufeinander folgende Senden zu. Quasi im Netpro die IP und im DB den String angepasst, auch den Aufruf, an welche Stelle die Ziffern ausgetauscht werden (nummer = ..). Beide Webserver sind unmanaged, also selbst verwaltbar, auf beiden läuft ein Webserver unter Linux, nginx. Beide mit der Standardkonfiguration, nur bei mir Debian, auf Arbeit eine andere Distribution mit Plesk obendrauf. Die Theorie, dass der Webserver die Verbindung abbaut, ist gar nicht so abwegig, Netpro zeigt nach wie vor Status OK an. Nachdem es dann ein Mal schief ging (kurioser Weise mit Error 0) etabliert er vielleicht die Verbindung neu.

Wie kann ich das passiv gestalten und jedes Mal die Verbindung aufbauen?

Echt schön hier unter Fachmännern
 
Die TCP-Verbindung wird bei http 1.1 auch aufrecht erhalten, z.B. um mit einer Verbindung bei Anfrage einer Seite auch alle Bilder und andere Elemente nachladen zu können.
Wenn du die Verbindung allerdings nicht für einen Datenaustausch nutzt, dann trennen diese Verbindungen die meisten Webserver automatisch um die Ressourcen wieder freizugeben. Beim Apache Webserver ist das z.B. nach ca. 15 Sekunden. Das Verhalten und Timeoutzeiten können von Webserver zu Webserver unterschiedlich sein.

Das hat den Grund, weil durchs Internet die Verbindungen nicht sonderlich stabil sind, und wenn ein Webserver alle TCP-Verbindungen die nicht explizit getrennt wurden bis Ultimo aufrechterhält, das System sehr schnell an die Grenzen gerät.

Die TCP-Verbindung steuern kannst du mit den AG_CNTRL bzw. AG_CNTRLEX Funktionen. Wichtig ist dabei, dass du die Verbindung über den entsprechenden Befehl so deaktivierst, dass sie nicht automatisch wieder aufgebaut wird. Dann muss du vor dem AG_SEND aber mit einem entsprechenden AG_CNTRL Aufruf die Verbindung erst wieder aktivieren, Status auswerten und erst dann AG_SEND aufrufen. Eine kleine Schrittkette ist hier angebracht.
 
Du kannst das Verhalten auch mal z.B. am Webserver vom SPS Forum ausprobieren. Du öffnest eine Eingabeaufforderung und gibst dann:
telnet sps-forum.de 80

ein. Der Befehl baut eine TCP-Verbindung zum angegebenen Host auf Port 80 auf.
Wenn die Verbindung aufgebaut werden konnte, dann wird der Text gelöscht und der Cursor blinkt oben links.
Wenn du jetzt nur wartest, dann kehrt nach ca. 50 Sekunden das Programm wieder zur Eingabeaufforderung zurück, weil der Webserver die Verbindung getrennt hat.

Windows schickt hier im Hintergrund nach 30 Sekunden (Defaultwert) noch ein Keepalive Telegramm, nach weiteren 20 Sekunden trennt der Webserver nun die Verbindung von sich aus weil keine Daten kommen. Aber selbst wenn du weiterhin Daten austauschen würdest, dann kannst du diese Verbindung nicht ewig aufrechterhalten. Zumindest nicht in der üblichen Konfiguration eines Webservers.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Danke für die Hilfe, hier sieht man, dass tiefes Wissen weiterhilft. Ich programmiere eigentlich Datenbanken und ERP-Systeme, beschäftige mich Zuhause nur bisschen mit meiner SPS, dass die den Brenner der Ölheizung betreibt, paar Pumpen anwirft und Holzkessel , Mischer, Heizkurve und Puffer sowie Türen, Wintergarten und Bewässerung verwaltet. Mit Schrittketten hatte ich bisher noch nichts zu tun, ich werde mich mit der Thematik beschäftigen. Hoffentlich funktioniert der ag_cntr bei mir, ich las, dass der wohl nicht überall einzusetzen geht..

Einen schönen Abend euch.
 
Eine Frage hätte ich noch, gibt es vielleicht jemanden, der ein Muster bzw. Beispielprojekt hat bezüglich AG Ctrl und AG send in einer Schrittkette? Ich würde das Problem sehr gern zeitnahe beheben.

Übrigens verwende ich nginx und der Webserver auf Arbeit ist Apache. Letzterer verhält sich anders, da kann ich nacheinander Nachrichten ohne Probleme senden. Meiner funktioniert auch, wenn die Nachrichten zeitlich Abstand haben, kommen die auch an, nur nicht direkt hintereinander.

Danke. :)
 
Also, bevor ich die Schrittkette hier poste, mein CP hat scheinbar ein Problem mit dem AG_CTRL, es kommt die Fehlermeldung: 80b0 Baugruppe kennt den Datensatz nicht. Egal ob beim Verbinden oder Trennen. Laden konnte ich ihn in die Steuerung jedoch..

Bin ratlos.

MfG.
Olaf
 
Zuletzt bearbeitet:
Zuviel Werbung?
-> Hier kostenlos registrieren
Oh, du hast einen 1EX11, und die AG_CNTRL FCs werden erst ab einem CP der mit Artikel-Nummer 1EX21 unterstützt. Das war mir bisher auch nicht so bewusst.

https://support.industry.siemens.com/cs/ww/de/view/22637440

Das ist für deinen Anwendungsfall natürlich sehr ungünstig. Das einzige was mir einfällt ist, dass du auch wenn keine Alarme über die URL absenden möchtest, du zyklisch irgendeine Status-Seite oder etwas in der Art abfragst. Das sollte zumindest dafür sorgen, dass die TCP-Verbindung wenn du sie benötigst schon verfügbar ist.
 
Ach Mist. Weißt du, eigenartig ist ja, dass das direkte Senden nacheinander ein Problem zu sein scheint, die erste Nachricht kommt an, die gleich darauf nicht, die dritte wieder. Sind 10 Minuten als Beispiel dazwischen, funktioniert es wieder tadellos. Halte ich jetzt die Verbindung offen, funktioniert das womöglich auch dann nicht mehr? Ich werde es mal ausprobieren.

Danke für den Hinweis, schon blöd, wenn das nicht kompatibel ist.
 

Similar threads

M
Step 7 BSEND / RECEIVE Problem bei Neustart CPU mit 9 S7-Verbindungen
Antworten
1
Aufrufe
4K
SoftMachine
SoftMachine
G
FTP Verbindung mit CP343
Antworten
0
Aufrufe
3K
gally11
G
Zurück
Oben