# Atlas Copco openProtocol Anbindung an S7 über Ethernet



## Thommi1969 (25 November 2009)

Hallo,

ich möchte einen Atlas Copco Power Focus 4000 über openProtocol an eine SIMATIC S7 300 mit Ethernet-CP (Advanced) anbinden. Ich muß die VIN übertragen um einen SchraubJob zu starten. Hat da jemand eine funktionierende Lösung?

mfG, Thommi1969


----------



## Bert (11 Juli 2011)

Hallo!

Ich habe das gleiche Problem (Aufgabenstellung) mit einem PF3000. Den PF3000 über einen PC via Ethernet anzusprechen und Schraubwerte abzugreifen habe ich schon gesehen. Wie funktioniert das über ne SPS?
Danke im Voraus.

MfG
Bert


----------



## IBFS (11 Juli 2011)

Bert schrieb:


> Hallo!
> 
> Ich habe das gleiche Problem (Aufgabenstellung) mit einem PF3000. Den PF3000 über einen PC via Ethernet anzusprechen und Schraubwerte abzugreifen habe ich schon gesehen. Wie funktioniert das über ne SPS?
> Danke im Voraus.
> ...




Und warum ruft ihr nicht beim Hersteller (AC) direkt an? Die haben ein sehr guten Support.

Frank


----------



## Thommi1969 (10 August 2011)

Vielen Dank, für den nützlichen Beitrag !!!! AC stellt nur das OpenProtocol nebst Doku zur Verfügung. Aber keine SPS-Bausteine und dergleichen. Da es mit einer SPS nicht geht die vielen verschiedenen Telegramme zu verwalten (da unterschiedlichen Längen usw) habe ich damals dann eine PC-Applikation entwickelt. Läuft seit ein paar Jahren bei Skoda.

mfG, Thommi



IBFS schrieb:


> Und warum ruft ihr nicht beim Hersteller (AC) direkt an? Die haben ein sehr guten Support.
> 
> Frank


----------



## Thommi1969 (10 August 2011)

Hallo,

mit einer S7-300 fast unmöglich, da beim RECEIVE schon die zu empfangende Länge mit angegeben werden muss. Die Telegramme (OpenProtocol von AC) haben aber alle verschiedene Längen. Mit einer 400er wäre es vielleicht noch denkbar. Ich habe damals dann eine PC-Applikation entwickelt die ca. 30 PF3000 verwaltet und mit der SPS über TCP/IP kommuniziert.

mfG, Thommi1969




Bert schrieb:


> Hallo!
> 
> Ich habe das gleiche Problem (Aufgabenstellung) mit einem PF3000. Den PF3000 über einen PC via Ethernet anzusprechen und Schraubwerte abzugreifen habe ich schon gesehen. Wie funktioniert das über ne SPS?
> Danke im Voraus.
> ...


----------



## Ralle (10 August 2011)

Thommi1969 schrieb:


> Hallo,
> 
> mit einer S7-300 fast unmöglich, da beim RECEIVE schon die zu empfangende Länge mit angegeben werden muss. Die Telegramme (OpenProtocol von AC) haben aber alle verschiedene Längen. Mit einer 400er wäre es vielleicht noch denkbar. Ich habe damals dann eine PC-Applikation entwickelt die ca. 30 PF3000 verwaltet und mit der SPS über TCP/IP kommuniziert.
> 
> mfG, Thommi1969



Zumindest für die neueren PN-CPU trifft das nicht mehr zu, dort kann man am RVC-Baustein für LEN 0 eintragen und bekommt dann bei RECV_LEN die tatsächlich empfangene Telegrammlänge zurück. CP habe ich leider nicht und somit kann ich darüber nichts sagen.


----------



## ronnie.b (10 August 2011)

Hallo zusammen,



> Hallo,
> 
> mit einer S7-300 fast unmöglich, da beim RECEIVE schon die zu  empfangende Länge mit angegeben werden muss. Die Telegramme  (OpenProtocol von AC) haben aber alle verschiedene Längen. Mit einer  400er wäre es vielleicht noch denkbar.



Das ist so nicht ganz richtig (zumindest kann ich vom PF3000 sprechen).
Das OpenProtocol schickt immer die Daten mit einem Header versehen.
Man empfängt also zuerst die ersten 4 Bytes. Darin ist die Telegrammlänge enthalten. Danach baut man sich die Restlänge zusammen und empfängt den Rest.
Den eigentlichen Kommunikationsablauf kannst du mit den Bausteinen TCON,TDISCON,TSEND,TRCV machen.
Sollte alles von deinem PC-Programm her übertragbar sein. Wir haben das schon mehrfach im Einsatz ich kann dir aber leider (zumindst im Moment) kein Projekt zur verfügung stellen aber du kannst ja dein Glück mal probieren und bei Problemen hier posten.

Gruß
Ronnie


----------



## SoftMachine (10 August 2011)

Hallo zusammen,

also ich kenne das auch so.



Ralle schrieb:


> Zumindest für die neueren PN-CPU trifft das nicht mehr zu, dort kann man am RVC-Baustein für LEN 0 eintragen und bekommt dann *bei RECV_LEN die tatsächlich empfangene Telegrammlänge* zurück. CP habe ich leider nicht und somit kann ich darüber nichts sagen.


 
Das geht bei PN als auch bei CP !

gruss


----------



## bike (10 August 2011)

Thommi1969 schrieb:


> Hallo,
> 
> mit einer S7-300 fast unmöglich, da beim RECEIVE schon die zu empfangende Länge mit angegeben werden muss. Die Telegramme (OpenProtocol von AC) haben aber alle verschiedene Längen. Mit einer 400er wäre es vielleicht noch denkbar. Ich habe damals dann eine PC-Applikation entwickelt die ca. 30 PF3000 verwaltet und mit der SPS über TCP/IP kommuniziert.
> 
> mfG, Thommi1969



Müssen wir jetzt zu jeder PLC eine PC kaufen und programmieren? 

Vielleicht solltest du dir die entsprechende Spezifikationen einmal genauer anschauen? 

Also unsere CP 341 Advanced können mit den Teilen sich gut und zuverlässig unterhalten.


bike


----------



## IBFS (12 August 2011)

SoftMachine schrieb:


> Hallo zusammen,
> 
> also ich kenne das auch so.
> 
> ...



neh das geht NICHT bei den CP (zumindest nicht bei denen, die ich hatte ), weil man dort nicht die FAKE-Länge Null - für variable Länge - antragen kann.

Frank


----------



## SoftMachine (13 August 2011)

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


----------



## Lars Weiß (13 August 2011)

SoftMachine schrieb:


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


----------



## Zefix (14 August 2011)

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.com/WW/view/de/51101016

Wäre vielleicht was fürn FAQ Bereich, da die Frage immer wieder auftaucht.


----------



## SoftMachine (14 August 2011)

Hi Lars,



Lars Weiß schrieb:


> 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


----------



## Lars Weiß (14 August 2011)

SoftMachine schrieb:


> Hi Lars,
> 
> 
> 
> ...



Joa, dann mach mir das mal vor. Bin gespannt.


----------



## SoftMachine (14 August 2011)

Witzbold ...


Gruss


----------



## PN/DP (14 August 2011)

*TCP Send/Receive mit IE-CP*

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



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


----------



## IBFS (14 August 2011)

PN/DP schrieb:


> 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


----------



## Lars Weiß (15 August 2011)

IBFS schrieb:


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



Ne IM 151-8


----------



## SoftMachine (15 August 2011)

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


----------

