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

Seite 2 von 2 ErsteErste 12
Ergebnis 11 bis 20 von 20

Thema: Atlas Copco openProtocol Anbindung an S7 über Ethernet

  1. #11
    Registriert seit
    13.09.2010
    Beiträge
    2.292
    Danke
    178
    Erhielt 375 Danke für 355 Beiträge

    Standard


    Zuviel Werbung?
    -> Hier kostenlos registrieren
    hi Frank,

    so wie ich es kenne, wird bei RCV_Len über CP die empfangene Länge zurückgegeben (NACH dem Empfang), dort muss doch (VOR dem Empfang) keine Länge angegeben werden

    Gruss
    kind regards
    SoftMachine

  2. #12
    Registriert seit
    22.05.2005
    Ort
    sonniges Maifeld
    Beiträge
    1.067
    Danke
    77
    Erhielt 205 Danke für 159 Beiträge

    Standard

    Zitat Zitat von SoftMachine Beitrag anzeigen
    hi Frank,

    so wie ich es kenne, wird bei RCV_Len über CP die empfangene Länge zurückgegeben (NACH dem Empfang), dort muss doch (VOR dem Empfang) keine Länge angegeben werden

    Gruss

    Dann kennst du "es" aber schlecht...das funzt wirklich nicht. Nur bei PN-CPU´s ist das empfangen von Telegrammen unterschiedlicher Länge ohne Angabe der Länge möglich. Aber wenn in dem Header die Länge steht ist es auch mit einem CP möglich. Zwei gegeneinander Verriegelte Aufrufe von AG-Recv und ab dafür.
    "Man kann auf seinem Standpunkt stehen, aber man sollte nicht darauf sitzen" - Erich Kästner

  3. #13
    Registriert seit
    27.08.2003
    Ort
    Schweitenkirchen
    Beiträge
    472
    Danke
    101
    Erhielt 73 Danke für 59 Beiträge

    Standard

    Bin Grad bei Siemens drüber gesolpert:
    Für Variables TCP/IP (fast, da hier mit Ende Zeichen gearbeitet wird) kam diesen Monat ein neuer Beitrag raus:

    http://support.automation.siemens.co...ew/de/51101016

    Wäre vielleicht was fürn FAQ Bereich, da die Frage immer wieder auftaucht.
    Wenn ich einen meiner Finger in eines deiner Nasenlöcher stecke, haben wir beide nen Finger in der Nase

  4. Folgender Benutzer sagt Danke zu Zefix für den nützlichen Beitrag:

    SoftMachine (15.08.2011)

  5. #14
    Registriert seit
    13.09.2010
    Beiträge
    2.292
    Danke
    178
    Erhielt 375 Danke für 355 Beiträge

    Standard

    Hi Lars,

    Zitat Zitat von Lars Weiß Beitrag anzeigen
    Dann kennst du "es" aber schlecht...das funzt wirklich nicht. Nur bei PN-CPU´s ist das empfangen von Telegrammen unterschiedlicher Länge ohne Angabe der Länge möglich. Aber wenn in dem Header die Länge steht ist es auch mit einem CP möglich. Zwei gegeneinander Verriegelte Aufrufe von AG-Recv und ab dafür.
    Hier steht´s anders:

    LENGTH in INT:
    Anzahl der Bytes, die in den am Eingangsparameter RECV_BUF parametrierten Datenbereich übernommen wurden.
    (nur gültig mit NDR=1)

    Gruss
    kind regards
    SoftMachine

  6. #15
    Registriert seit
    22.05.2005
    Ort
    sonniges Maifeld
    Beiträge
    1.067
    Danke
    77
    Erhielt 205 Danke für 159 Beiträge

    Standard

    Zitat Zitat von SoftMachine Beitrag anzeigen
    Hi Lars,



    Hier steht´s anders:

    LENGTH in INT:
    Anzahl der Bytes, die in den am Eingangsparameter RECV_BUF parametrierten Datenbereich übernommen wurden.
    (nur gültig mit NDR=1)

    Gruss
    Joa, dann mach mir das mal vor. Bin gespannt.
    "Man kann auf seinem Standpunkt stehen, aber man sollte nicht darauf sitzen" - Erich Kästner

  7. #16
    Registriert seit
    13.09.2010
    Beiträge
    2.292
    Danke
    178
    Erhielt 375 Danke für 355 Beiträge

    Standard

    Witzbold ...


    Gruss
    kind regards
    SoftMachine

  8. #17
    Registriert seit
    22.06.2009
    Ort
    Sassnitz
    Beiträge
    11.306
    Danke
    932
    Erhielt 3.321 Danke für 2.683 Beiträge

    Standard

    OK, für SoftMachine und andere Interessierte ein paar Worte zum Send/Receive mit IE-CP.

    Die CPx43-1 wickeln selbständig die Kommunikation mit Partnern über Ethernet ab.
    Schnittstelle zwischen dem Anwenderprogramm und dem CP sind die Bausteine AG_SEND und AG_RECV.
    (die T-Bausteine für "offene Kommunikation" können nur mit den CPU-integrierten PN-Schnittstellen genutzt werden!)
    Die CP empfangen Telegramme unabhängig davon, ob AG_RECV aufgerufen wird oder nicht (bis der Empfangspuffer voll ist).
    Der Baustein AG_RECV hat KEINEN EXTRA Eingangsparameter, an dem man angeben könnte, wieviele Byte man als Telegrammlänge erwartet oder den man auf 0 setzen könnte für "beliebige Länge".
    Ein offenbar weit verbreiteter Irrglaube ist, daß der Baustein AG_RECV irgendwie Daten empfangen würde. Er holt lediglich eine vorgegebene Anzahl Zeichen aus dem Empfangspuffer des CP in das eigene Anwenderprogramm. Man muß am Eingangsparameter RECV einen Any-Pointer auf einen eigenen Datenbereich mit der gewünschten Anzahl zu holender Byte angeben (ein Any-Pointer auf einen Datenbereich mit der Länge 0 würde keinen Sinn machen!). Bei TCP-Verbindungen liefert der Baustein AG_RECV ERST DANN Bytes aus dem Empfangspuffer des CP, wenn der CP MINDESTENS die im Any-Pointer angegebene Anzahl Zeichen empfangen hat. Er liefert dann immer GENAU die Anzahl Zeichen die im Any-Pointer angegeben wurde, auch wenn mehr Zeichen als angegeben empfangen wurden.

    Hier offenbart sich das Dilemma beim Empfang unterschiedlich langer Telegramme, wenn man nicht exakt weiß, wieviele Bytes das nächste Telegramm lang ist.
    Ist das Telegramm länger als im Any-Pointer angegeben, dann wird nur ein Teil des Telegramms abgeholt, dann wird das Telegramm auf mehrere AG_RECV-Empfangsaufträge zerstückelt.
    Ist das Telegramm kürzer als im Any-Pointer angegeben, dann liefert AG_RECV SOLANGE NICHTS, bis so viele Telegramme empfangen wurden, daß die im Any-Pointer angegebene Byteanzahl mindestens erreicht ist. Wenn der Sender nur 1 Telegramm sendet und danach auf Antwort wartet, dann kann er ewig warten. Das Empfangsprogramm weiß noch gar nichts von diesem Telegramm.

    Bei solchen nicht exakt zur Telegrammlänge passenden Längenangaben im Any-Pointer ist zusätzlich zu beachten, daß die Empfangsdaten nicht immer an der selben Position im Anwender-Puffer stehen, sie verschieben sich und "wandern" bei jedem Telegramm-Empfang. Auch bei einer eigentlich fest vereinbarten Telegrammlänge kann es sich verheerend auswirken, wenn der Partner auch nur einmal 1 Zeichen zuviel oder zuwenig sendet oder der CP zuwenig empfängt und das Empfangsprogramm das nicht erkennt!
    Deshalb: Bei TCP-Verbindungen immer einen eigenen Telegramm-Rahmen mit Start/Ende-Zeichen oder Header vereinbaren!


    Möglichkeiten zum Empfang von Telegrammen mit variabler Länge:

    A. Man könnte immer genau 1 Zeichen mit AG_RECV abholen und die Empfangstelegramme im eigenen Anwenderprogramm zeichenweise wieder zusammensetzen. Das wird dann aber sehr langsam, weil günstigstenfalls je OB1-Zyklus nur 1 Zeichen aus dem CP geholt wird. Sendet der Partner zu schnell Telegramme, dann läuft der Empfangspuffer des CP über. (oder man ruft AG_RECV in einer Schleife auf)

    B. Man vereinbart einen festen Telegramm-Header, in dem die Länge des folgenden variabel langen Datenteils angegeben ist (oder die Gesamtlänge des Telegramms inklusive Header).
    Dann empfängt man mit 2 verschiedenen AG_RECV-Aufrufen abwechselnd den festen Header und den variablen Datenteil.

    Möglichkeit B siehe Beitrag #12 von Lars Weiß oder dieses Handbuch:

    Projektierungshandbuch: S7−CPs für Industrial Ethernet Projektieren und in Betrieb nehmen Teil A - Allgemeine Anwendung
    Kapitel 4 SEND/RECEIVE−Schnittstelle im Anwenderprogramm
    4.4.1 Datenübertragung über TCP−Verbindungen programmieren
    Bei TCP−Verbindungen gibt es im Protokoll keine Informationen über das Ende
    einer Nachricht bzw. den Anfang einer neuen Nachricht.

    Daher muss die Empfängerstation wissen, wieviel Bytes zu einer Nachricht
    gehören und demnach einen exakt dieser Länge entsprechenden ANY−Pointer
    beim Aufruf des FC AG_RECV/AG_LRECV übergeben.

    [...]

    Wenn Sie Daten mit variabler Länge empfangen möchten, gehen Sie wie folgt
    vor:
    Fügen Sie vor den eigentlichen Nutzdaten im Telegramm eine Information über
    die Länge der Nutzdaten ein. Werten Sie in der Empfängerstation zunächst nur
    die Längeninformation aus. Holen Sie in einem weiteren Empfangsauftrag die
    entsprechende Nutzdatenmenge ab, indem Sie dann einen ANY−Pointer entsprechender
    Länge an der der FC−Schnittstelle zum Abholen der eigentlichen
    Nutzdaten mitgeben.
    PS:
    Beim ISO-on-TCP-Protokoll enthält jedes Telegramm eine Information über die Telegrammlänge und der CP synchronisiert selbständig die AG_RECV-Empfangsaufträge mit den Telegrammlängen. AG_RECV liefert auch Telegramme, die kürzer sind als im RECV-Any-Pointer angegeben. Hier sollte man den Ausgang LEN auswerten.

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

    FAQ: Linkliste SIMATIC-Kommunikation über Ethernet
    Zitieren Zitieren TCP Send/Receive mit IE-CP  

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

    SoftMachine (15.08.2011)

  10. #18
    Registriert seit
    25.06.2007
    Ort
    Dresden
    Beiträge
    3.930
    Danke
    465
    Erhielt 878 Danke für 634 Beiträge

    Standard

    Zitat Zitat von PN/DP Beitrag anzeigen
    A. Man könnte immer genau 1 Zeichen mit AG_RECV abholen und die Empfangstelegramme im eigenen Anwenderprogramm zeichenweise wieder zusammensetzen. Das wird dann aber sehr langsam, weil günstigstenfalls je OB1-Zyklus nur 1 Zeichen aus dem CP geholt wird. Sendet der Partner zu schnell Telegramme, dann läuft der Empfangspuffer des CP über. (oder man ruft AG_RECV in einer Schleife auf)

    Harald
    A.
    So musste ich es leider auch schon machen, weil von der Partnerstelle ständig Müll ankam.

    Im Notfall ein reine Kommunikations-CPU verwenden.
    Die läuft dann mit 1ms. Das reicht fast immer für normale Telegrammlängen.

    Frank
    Grüße Frank

  11. #19
    Registriert seit
    22.05.2005
    Ort
    sonniges Maifeld
    Beiträge
    1.067
    Danke
    77
    Erhielt 205 Danke für 159 Beiträge

    Standard

    Zitat Zitat von IBFS Beitrag anzeigen
    A.
    So musste ich es leider auch schon machen, weil von der Partnerstelle ständig Müll ankam.

    Im Notfall ein reine Kommunikations-CPU verwenden.
    Die läuft dann mit 1ms. Das reicht fast immer für normale Telegrammlängen.

    Frank
    Ne IM 151-8
    "Man kann auf seinem Standpunkt stehen, aber man sollte nicht darauf sitzen" - Erich Kästner

  12. #20
    Registriert seit
    13.09.2010
    Beiträge
    2.292
    Danke
    178
    Erhielt 375 Danke für 355 Beiträge

    Standard


    Zuviel Werbung?
    -> Hier kostenlos registrieren
    Hi zusammen !

    hab´mich schlau gemacht...

    Harald hat recht ....

    Zefix hat recht.... --> vielen Dank für den neuen link in Deinem Beitrag !

    @Lars:
    Asche auf mein Haupt, ich kann´dir leider wirklich nicht vorführen ...

    Gruss an alle

    P.S. ...wieder dazu gelernt...
    kind regards
    SoftMachine

Ähnliche Themen

  1. Profi2Can Atlas Copco Combox
    Von Krug-Systems.de im Forum Feldbusse
    Antworten: 31
    Letzter Beitrag: 19.07.2017, 12:46
  2. S7 Ethernet-Anbindung über MPI
    Von hollyzwei im Forum Simatic
    Antworten: 3
    Letzter Beitrag: 22.07.2011, 09:28
  3. Atlas Copco Schrauber
    Von pseudoman im Forum Simatic
    Antworten: 2
    Letzter Beitrag: 31.03.2010, 11:55
  4. Atlas Copco open protocol (Trace)
    Von leo im Forum Hochsprachen - OPC
    Antworten: 6
    Letzter Beitrag: 23.03.2008, 08:20
  5. Atlas-Copco PowerMacs?
    Von ge_org im Forum Sonstige Steuerungen
    Antworten: 0
    Letzter Beitrag: 27.09.2007, 19:23

Stichworte

Lesezeichen

Berechtigungen

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