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

Seite 1 von 2 12 LetzteLetzte
Ergebnis 1 bis 10 von 17

Thema: Verbindungsabbruch FC10 "AG_CNTRL"

  1. #1
    Registriert seit
    06.10.2009
    Ort
    NRW
    Beiträge
    1.552
    Danke
    63
    Erhielt 257 Danke für 217 Beiträge

    Standard


    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.
    Angehängte Dateien Angehängte Dateien
    Meine Motivation läuft nackig mit einem Cocktail über eine Wiese.
    Zitieren Zitieren Verbindungsabbruch FC10 "AG_CNTRL"  

  2. #2
    Registriert seit
    22.06.2009
    Ort
    Sassnitz
    Beiträge
    10.767
    Danke
    884
    Erhielt 3.158 Danke für 2.559 Beiträge

    Standard

    Zitat Zitat von Tigerente1974 Beitrag anzeigen
    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?


    Zitat Zitat von Tigerente1974 Beitrag anzeigen
    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?


    Zitat Zitat von Tigerente1974 Beitrag anzeigen
    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?


    Zitat Zitat von Tigerente1974 Beitrag anzeigen
    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
    Geändert von PN/DP (25.08.2015 um 18:59 Uhr) Grund: HyperTerm schreibt sich ohne h :(
    Es ist immer wieder überraschend, wie etwas plötzlich funktioniert, sobald man alles richtig macht.

    FAQ: Linkliste SIMATIC-Kommunikation über Ethernet

  3. #3
    Registriert seit
    23.11.2012
    Ort
    Österreich
    Beiträge
    147
    Danke
    48
    Erhielt 19 Danke für 19 Beiträge

    Standard

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

  4. #4
    Tigerente1974 ist offline Erfahrener Benutzer
    Themenstarter
    Registriert seit
    06.10.2009
    Ort
    NRW
    Beiträge
    1.552
    Danke
    63
    Erhielt 257 Danke für 217 Beiträge

    Standard

    Zitat Zitat von kapo666 Beitrag anzeigen
    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.:
    Code:
    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.
    Angehängte Grafiken Angehängte Grafiken
    • Dateityp: jpg FC5.jpg (57,2 KB, 19x aufgerufen)
    Meine Motivation läuft nackig mit einem Cocktail über eine Wiese.

  5. #5
    Registriert seit
    30.04.2005
    Beiträge
    904
    Danke
    57
    Erhielt 161 Danke für 147 Beiträge

    Standard

    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?
    Krieg ist Gottes Art den Amerikanern Geographie beizubringen

  6. #6
    Tigerente1974 ist offline Erfahrener Benutzer
    Themenstarter
    Registriert seit
    06.10.2009
    Ort
    NRW
    Beiträge
    1.552
    Danke
    63
    Erhielt 257 Danke für 217 Beiträge

    Standard

    Zitat Zitat von PN/DP Beitrag anzeigen
    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.


    Zitat Zitat von PN/DP Beitrag anzeigen
    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

    Zitat Zitat von PN/DP Beitrag anzeigen
    Welchen Status liefert AG_SEND im Fehlerfall?
    W#16#0000

    Zitat Zitat von PN/DP Beitrag anzeigen
    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.

    Zitat Zitat von PN/DP Beitrag anzeigen
    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.
    Angehängte Grafiken Angehängte Grafiken
    Geändert von Tigerente1974 (27.08.2015 um 09:15 Uhr)
    Meine Motivation läuft nackig mit einem Cocktail über eine Wiese.

  7. #7
    Tigerente1974 ist offline Erfahrener Benutzer
    Themenstarter
    Registriert seit
    06.10.2009
    Ort
    NRW
    Beiträge
    1.552
    Danke
    63
    Erhielt 257 Danke für 217 Beiträge

    Standard

    Die Verbindung ist in NetPro wie auf den Bildern projektiert.
    Angehängte Grafiken Angehängte Grafiken
    Meine Motivation läuft nackig mit einem Cocktail über eine Wiese.

  8. #8
    Tigerente1974 ist offline Erfahrener Benutzer
    Themenstarter
    Registriert seit
    06.10.2009
    Ort
    NRW
    Beiträge
    1.552
    Danke
    63
    Erhielt 257 Danke für 217 Beiträge

    Standard

    Für weitere Hilfe bin ich dankbar.
    Meine Motivation läuft nackig mit einem Cocktail über eine Wiese.

  9. #9
    Registriert seit
    30.04.2005
    Beiträge
    904
    Danke
    57
    Erhielt 161 Danke für 147 Beiträge

    Standard

    Jetzt wäre interessant ob und wer die Verbindung abbaut
    Krieg ist Gottes Art den Amerikanern Geographie beizubringen

  10. #10
    Registriert seit
    22.06.2009
    Ort
    Sassnitz
    Beiträge
    10.767
    Danke
    884
    Erhielt 3.158 Danke für 2.559 Beiträge

    Standard


    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?

    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.


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

    z.B.:
    Code:
    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
    Es ist immer wieder überraschend, wie etwas plötzlich funktioniert, sobald man alles richtig macht.

    FAQ: Linkliste SIMATIC-Kommunikation über Ethernet

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

    kapo666 (27.08.2015)

Ähnliche Themen

  1. Antworten: 8
    Letzter Beitrag: 07.05.2015, 08:25
  2. Antworten: 0
    Letzter Beitrag: 05.09.2012, 12:08
  3. Antworten: 6
    Letzter Beitrag: 16.03.2012, 18:20
  4. "Index Pulse", "Home Switch" und "Position Limit Switch"
    Von senmeis im Forum Antriebstechnik
    Antworten: 3
    Letzter Beitrag: 07.03.2011, 11:21
  5. Simatic Net, AG_CNTRL (FC10) und AG_RECV (FC6)
    Von Hansruedi im Forum Simatic
    Antworten: 0
    Letzter Beitrag: 12.03.2010, 08:56

Lesezeichen

Berechtigungen

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