Step 7 Verbindungsabbruch FC10 "AG_CNTRL"

[Tigerente1974]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo Forum,

mich plagt jetzt schon recht lang ein Problem, das ich einfach nicht lösen kann.

Projektiert ist eine TCP-Verbindung zu einem Netzwerkrechner für Telegrammverkehr.
Die Länge der Telegramme ist fest. (STRING[50])
Als Hardware habe ich eine S7-317 2DP mit CP343-1 lean.

Der Telegrammverkehr funktioniert zwar in der Regel, doch hin und wieder gehen Telegramme "verloren".
Das passiert, weil die Verbindung immer wieder neu aufgebaut wird, sobald ich ein Telegramm mittels FC5 "AG_SEND" verschicke.
Das Telegramm kommt beim projektierten Partner noch an. Manchmal bekomme ich die Antwort aber nicht mit.

Im Statuswort des FC10 steht im Fehlerfall W#16#80C2. Laut Siemens-Hilfe liegt ein Auftragsstau vor.
Mir fehlt da die Erfahrung mit TCP-Verbindungen. Probieren kann ich auch nicht viel, weil die Anlage beim Kunden permanent laufen muss.

1. Warum funktioniert das nicht richtig?
2. Gibt es eine (einfache) Möglichkeit, das irgendwie zu simulieren ohne auf der Anlage beim Kunden zu probieren?

Ich habe eine Quelle von dem aufrufenden FB erzeugt und angehängt.
Falls noch weitere Informationen fehlen, kann ich die nachreichen.

 

[PN/DP]

Der Telegrammverkehr funktioniert zwar in der Regel, doch hin und wieder gehen Telegramme "verloren".
Das passiert, weil die Verbindung immer wieder neu aufgebaut wird, sobald ich ein Telegramm mittels FC5 "AG_SEND" verschicke.

Woher weißt Du, daß die Verbindung immer wieder neu aufgebaut wird?
Wie sieht die Verbindungsprojektierung aus? Wer baut die Verbindung auf?

Die Länge der Telegramme ist fest. (STRING[50])

Hat das einen Grund, warum in Deinem Programm die meisten STRING[50] mit nur 49 Zeichen initialisiert werden?

Im Statuswort des FC10 steht im Fehlerfall W#16#80C2. Laut Siemens-Hilfe liegt ein Auftragsstau vor.

Welchen Status liefert AG_SEND im Fehlerfall?
Wie wird "FOT_COMMDB".COMFLAGS.SendReq gesteuert? Kann es sein, daß das Bit "flackert"? Also häufiger 0/1/0/1 wird als die Aufträge abgearbeitet werden?

2. Gibt es eine (einfache) Möglichkeit, das irgendwie zu simulieren ohne auf der Anlage beim Kunden zu probieren?

Du könntest zum Test/Simulation die Verbindungsprojektierung ändern und statt zu dem Kunden-Server zu einem PC mit HyperTerm senden. Oder zu einer Test-SPS.

Harald

 

[kapo666]

Zuviel Werbung?
-> Hier kostenlos registrieren

hello,

sieht für mich so aus als würden zu viele Auftrage in Arbeit gegeben worden sein. Wie oft erfolgt der Sendeanstoß für AG_SEND?

ich habe mir Abhilfe geschaffen, indem ich die Sende- und Fehlerstatusbits abfrage und erst wieder neu senden lasse, wenn alles in Ordnung

z.B.:

U     "FOT_COMMDB".COMFLAGS.SendReq
UN   "FOT_COMMDB".COMFLAGS.SendDone
UN   "FOT_COMMDB".COMFLAGS.SendError
=     "Auftrag anstoßen"

Probieren kannst du es in einer Versuchsecke oder du bastelst dir eine Versuchsverbindung mit Versuchs-DB's. Oder auch während dem laufenden Betrieb. Soweit ich weiß juckt es die CPU nicht, ob deine Daten verschickt werden oder nicht.

gruß kapo

 

[Tigerente1974]

hello,

sieht für mich so aus als würden zu viele Auftrage in Arbeit gegeben worden sein. Wie oft erfolgt der Sendeanstoß für AG_SEND?

ich habe mir Abhilfe geschaffen, indem ich die Sende- und Fehlerstatusbits abfrage und erst wieder neu senden lasse, wenn alles in Ordnung

z.B.:

U     "FOT_COMMDB".COMFLAGS.SendReq
UN   "FOT_COMMDB".COMFLAGS.SendDone
UN   "FOT_COMMDB".COMFLAGS.SendError
=     "Auftrag anstoßen"

Probieren kannst du es in einer Versuchsecke oder du bastelst dir eine Versuchsverbindung mit Versuchs-DB's. Oder auch während dem laufenden Betrieb. Soweit ich weiß juckt es die CPU nicht, ob deine Daten verschickt werden oder nicht.

gruß kapo

Hallo kapo,

das Sendebit wird im Programm in einer Schrittkette gesetzt, die dann später auf SendDone oder auf SendError wartet bevor sie wieder anläuft.
ich habe das trotzdem mal eingebaut, um einen Fehler auszuschließen.
Leider kein Erfolg.

Probieren ist halt schwierig, weil die Verbindung permanent benötigt wird. Die Gegenstelle ist ein Materialflussrechner. Ohne den Telegrammverkehr bewegt sich nichts mehr auf der Anlage.

 

[centipede]

Aber jetzt hier nochmals die Frage, wie kommst du darauf, dass die Verbindung abgebaut wurde?
Wer baut die Verbindung auf?
Wireshark schon mal reingehängt?

 

[Tigerente1974]

Zuviel Werbung?
-> Hier kostenlos registrieren

Woher weißt Du, daß die Verbindung immer wieder neu aufgebaut wird?
Wie sieht die Verbindungsprojektierung aus? Wer baut die Verbindung auf?

Da die Bits 12+13 des RESULT1 sind nach dem Senden immer beide 0 gewesen. Daraus hatte ich das geschlossen.
Gestern habe ich mir das noch einmal genauer angesehen. Nach dem Senden gehen alle Bits des Statusworts auf 0.
Eine Erklärung habe ich erstmal nicht dafür.

Hat das einen Grund, warum in Deinem Programm die meisten STRING[50] mit nur 49 Zeichen initialisiert werden?

Da hab ich mich wohl irgendwo verzählt... Ist jetzt korrigiert. Sollte m.E. keine Auswirkung haben

Welchen Status liefert AG_SEND im Fehlerfall?

W#16#0000

Wie wird "FOT_COMMDB".COMFLAGS.SendReq gesteuert? Kann es sein, daß das Bit "flackert"? Also häufiger 0/1/0/1 wird als die Aufträge abgearbeitet werden?

Ich hab mal einen Schmiermerker reingemacht der beim Sendeanstoß gesetzt wird. Das Rücksetzen wurde über SendDone / SendError gemacht. Damit sollte ein Flackern ausgeschlossen sein.

Du könntest zum Test/Simulation die Verbindungsprojektierung ändern und statt zu dem Kunden-Server zu einem PC mit HyperTerm senden. Oder zu einer Test-SPS.

Ändern geht nicht, weil die Verbindung dauernd benötigt wird. Siehe mein vorheriger Post.


Sehr merkwürdig finde ich, dass alle Bits Statusworts1 genullt werden.

Weiter habe ich noch folgendes herausgefunden:
Der FC6 AG_RECV gibt die Störung W#16#80C2 heraus. Vermutlich weil die Verbindung immer wieder weg ist.
Die Bits 2+3 bzw. 6+7 im RESULT1 sehen so aus, als würde immer eine Störung beim Senden/Empfangen auftreten.

 

[Tigerente1974]

Die Verbindung ist in NetPro wie auf den Bildern projektiert.

 

[Tigerente1974]

Für weitere Hilfe bin ich dankbar.

 

[centipede]

Zuviel Werbung?
-> Hier kostenlos registrieren

Jetzt wäre interessant ob und wer die Verbindung abbaut

 

[PN/DP]

@Tigerente1974
Bei Deiner Kommunikation verhalten sich Client und Server falsch herum. Der Client muß die Verbindung zum Server aufbauen. Deine SPS agiert wie ein Server - sie wartet, daß der Kommunikationspartner (MFR) die Verbindung aufbaut. Dann darf sie aber auch nur dann Telegramme senden, wenn der Kommunikationspartner sie dazu auffordert/anfragt. Euer Protokoll scheint aber so zu sein, daß der MFR keine Aufforderung sendet sondern nur eine Empfangs-Antwort.

Warum ist das so eingerichtet?

Ich vermute, wenn Du in der Verbindungsprojektierung Partner-IP und Partner-Port angibst und "Aktiver Verbindungsaufbau" aktivierst, dann wird es funktionieren.


Wenn Du nicht mit der originalen SPS testen kannst: Zum Testen könntest Du eine zusätzliche Testverbindung zu einem Test-Kommunikationspartner einrichten oder eine zweite SPS als Testaufbau benutzen.

ich habe mir Abhilfe geschaffen, indem ich die Sende- und Fehlerstatusbits abfrage und erst wieder neu senden lasse, wenn alles in Ordnung

z.B.:

U     "FOT_COMMDB".COMFLAGS.SendReq
UN   "FOT_COMMDB".COMFLAGS.SendDone
UN   "FOT_COMMDB".COMFLAGS.SendError
=     "Auftrag anstoßen"

Der Code funktioniert leider nicht gegen zu häufiges SendReq - "Auftrag anstoßen" würde im selben Rhythmus "flackern" wie SendReq. Es müßte eine Lösung mit S/R sein: SendReq setzt eine Bitvariable für AG_SEND.ACT, SendDone oder SendError rücksetzt das Bit.

Harald

 

[Tigerente1974]

Hallo Harald,

vielen Dank für die Hilfe.
Ich werde die Einstellung in NetPro beim nächsten Kundenbesuch testen und wieder berichten.

Ich hab mal einen Schmiermerker reingemacht der beim Sendeanstoß gesetzt wird. Das Rücksetzen wurde über SendDone / SendError gemacht. Damit sollte ein Flackern ausgeschlossen sein.

Den Code mit dem Schmiermerker hab ich sofort wieder gelöscht, als ich gesehen habe dass es keine Wirkung hat.

 

[Tigerente1974]

Zuviel Werbung?
-> Hier kostenlos registrieren

@Tigerente1974
Bei Deiner Kommunikation verhalten sich Client und Server falsch herum. Der Client muß die Verbindung zum Server aufbauen. Deine SPS agiert wie ein Server - sie wartet, daß der Kommunikationspartner (MFR) die Verbindung aufbaut. Dann darf sie aber auch nur dann Telegramme senden, wenn der Kommunikationspartner sie dazu auffordert/anfragt. Euer Protokoll scheint aber so zu sein, daß der MFR keine Aufforderung sendet sondern nur eine Empfangs-Antwort.

Warum ist das so eingerichtet?

Die Einrichtung habe ich seinerzeit in Kooperation mit dem Projektierer der Gegenstelle gemacht. Ich vermute es ist noch genau so wie wir das damals zusammen eingerichtet haben. Wie gesagt, normalerweise benutze ich solche Verbindungen gar nicht. Deswegen habe ich mich auch nicht bis in die Tiefe damit auseinandergesetzt. Von da her kann ich auchz gar nicht begründen, warum das jetzt genau so gemacht wurde.

 

[Tigerente1974]

Hallo Harald,

ich bin inzwischen dazu gekommen, den Vorschlag auszuprobieren. Leider hat das nicht geklappt und ich habe wieder nur Fragezeichen auf der Stirn.
Oder bin ich einfach zu blöd? :-/

Ich habe die Verbindung in NetPro auf "aktiv verbinden" gesetzt und den Partner eingetragen (Siehe screenshot)
In der Verbindungstabelle wurde der Eintrag auch auf aktive Verbindung gesetzt.
Anschließend habe ich in NetPro die Aktion "Speichern und übersetzen durchgeführt. Im HW-Manager habe ich die Hardwaredaten in die Steuerung geladen.Trotzdem hat die CP343-lean keine aktive Verbindung aufgebaut.

Ich hab dann noch weiter in der Spezialdiagnose geforscht. Dort steht immer noch, dass der "passive Verbindungsaufbau" läuft.
Auch ein Neustart des CP343 mit STOP --> RUN hat keine Erfolg gebracht.
Irgendwas scheint noch zu fehlen?!?

Mir ist in der Spezialdiagnose aber auch aufgefallen, dass dort laut Protokoll alle gesendeten und empfangenen Nachrichten fehlerfrei übertragen wurden.
Müßte hier nicht etwas anderes stehen, wenn Telegramme "verlorengehen".
Ich finde es nach wie vor sehr merkwürdig, dass alle Bits des RESULT1 vom FC10 gleichzeitig auf 0 gehen. Ich hab sogar das angeschlossene Merkerdoppelwort mal gewechselt um irgendeinen blöden Fehler auszuschließen.

Ich bin weiterhin für jede Hilfe dankbar.

Gruß

Christian

 

[PN/DP]

Die Verbindungsprojektierung muß aus NetPro in die CPU geladen werden:

A) Station mit der CPU markieren + Zielsystem > Laden im aktuellen Projekt > Markierte Stationen
--> lädt Verbindungen und HW Konfig (also komplette Systemdaten), CPU-Stop erforderlich
(Nachtrag: das Gleiche erreicht man, wenn man die Systemdaten aus dem Bausteine-Ordner in die CPU lädt)

oder B) Station mit der CPU markieren + Zielsystem > Laden im aktuellen Projekt > Verbindungen und Netzübergänge
--> lädt nur Verbindungen und Routing-SDB, geht ohne CPU-Stop

Harald

 

[kapo666]

Zuviel Werbung?
-> Hier kostenlos registrieren

Deine beiden Geräte hängen nicht im selben Netz

Lokal: 185.9.199.222
Partner: 185.9.200.13

vielleicht könnte das dein Problem sein

 

[Tigerente1974]

Hallo kapo,

es ist ein Router eingetragen. Ich vermute auch, dass die Kommunikation dann auch gar nicht klappen würde, wenn die Adressen nicht stimmen.

Sobald ich den aktiven Verbindungsaufbau realisieren konnte, gebe ich hier nochmal Rückmeldung.

 

[Tigerente1974]

Hallo Forum,

manche Dinge brauchen einfach länger...
Ich habe das Problem jetzt endlich gelöst.
Im Ablauf habe ich den AG_SEND angetriggert und darauf gewartet, dass der AG_SEND mit DONE antwortet.
Erst dann habe ich auf die Quittierung meines Telegramms gewartet. (AG_RECV). Weil ich die Antwort nicht mitbekommen habe, habe ich den Sendeauftrag wiederholt.
Die Antwort der Gegenstelle kam aber schon vor dem DONE vom AG_SEND. Zumindest was meine Schrittkette betrifft.
Die Schrittkette läuft ganz normal in einer zyklischen Task. Die SEND/RECEIVE-Bausteine arbeiten aber asynchron.
Daher hat der Code nicht funktioniert und ich hab mich an der Stelle festgebissen...

Vielen Dank an alle, die mir geholfen haben.