# cp443-1 - cp343-1 lean mit fb/sfb 12/13



## volker (15 Juli 2010)

hallo

habe hier eine cp443-1 und eine cp343-1 lean.
diese möchte ich über eine s7-verbindung koppeln.

habe beide cp im projekt projektiert.
nun versuche ich eine verbindung zwischen beiden herszustellen und die id zuzuweisen die die fb/sfb 12/13 ja benötigen.

füge ich eine verbindung bei der 443 hinzu kann ich die 343 auswählen und übernehmen.
versuche ich die 343 mit der 443 zu verbinden meckert s7, dass nicht genügend verbindungen (oder so ähnlich) zur verfügung stehen.

was mach ich hier falsch?


----------



## HaDi (15 Juli 2010)

Der CP343-1 LEAN unterstützt bei S7-Kommunikation ausschließlich Serverfunktion.

Grüße von HaDi


----------



## volker (16 Juli 2010)

gesehen hatte ich das aber mir keine gedanken darüber gemacht.
mitlerweile weiss ich, das die komplette kommunikation von der 443 gemacht werden muss.

aber wie das auszusehen hat finde ich nirgendno.

hat vllt jemand ein beispiel?

ansonsten werde ich mal eine der anderen kommunikationsmöglichkeiten probieren. die scheinen, wenn ich mir die beispiele ansehe, aber recht aufwendig zu sein.


----------



## volker (16 Juli 2010)

ich machs jetzt auf der 400er seite mit sfb 14/15 get/put

blöderweise kann man nur max 36 byte pro auftrag lesen/schreiben.
bei mehr passiert gar nichts mehr. aber damit kann/muss ich leben


----------



## HaDi (16 Juli 2010)

Gibt es einen besonderen Grund warum du das per S7-Kommunikation machen wolltest und jetzt per PUT/GET?
Mit der gegebenen Hardware müsste doch eigentlich eine TCP- oder ISO-on-TCP-Verbindung möglich sein.

Grüße von HaDi


----------



## volker (16 Juli 2010)

nein, einen zwingenden grund gibt es nicht.

aber ich hab mir mal das beispiel für iso on tcp angesehen.
finde ich sehr aufwendig gemacht.

bei der s7-kommunikation habe ich gerade mal ein paar aufrufe der entsprechenden fb/sfb und gut ist.

ausserdem habe ich gelesen, das s7-kommunikation sehr schnell sein soll.

wieviel daten im endefekt übertragen werden müssen weis ich jetzt noch nicht genau. aber es werden auf jeden fall (ähh wahrscheinlich) deutlich unter 1k

oder gibt es einen guten grund doch besser iso on tcp oder tcp einzusetzen
udp scheidet aus da dort daten verlorengehen können wenn ich das richtig gelesen habe


----------



## HaDi (16 Juli 2010)

Naja, bei einer ISO-on-TCP-Verbindung sind es ja auch nur 4 Bausteinaufrufe, im beiliegenden Projekt hab ich das mal versucht (ungetestet).
PUT/GET mag ich nicht besonders, weil sich in der per PUT beschriebenen Steuerung Daten ändern und ich, wenn das nicht ordentlich dokumentiert ist, mir einen Wolf suchen muss, um das herauszufinden.
Schneller ist die Übertragung per PUT/GET sicher auch nicht.

Grüße von HaDi


----------



## Rainer Hönle (16 Juli 2010)

volker schrieb:


> oder gibt es einen guten grund doch besser iso on tcp oder tcp einzusetzen
> udp scheidet aus da dort daten verlorengehen können wenn ich das richtig gelesen habe



Stimmt, UPD ist messagebasiert und ungesichert (keine Gewährleistung dass Gegenstelle die Daten empfängt), TCP ist streambasiert und gesichert (entweder es klappt oder man bekommt eine Fehlermeldung)


----------



## volker (17 Juli 2010)

@hadi

hab mir dein prog mal angesehen.

astrein. genausowas einfaches wollte ich. 
warum machen die im siemensbeispiel son riesenheckmeck daraus wenns doch so einfach ist? 

danke


----------



## HaDi (17 Juli 2010)

volker schrieb:


> warum machen die im siemensbeispiel son riesenheckmeck daraus wenns doch so einfach ist?


Ich kenne das Beispiel nicht, aber natürlich kann man mit der Ansteuerung und Auswertung der beiden Bausteine schon noch einige Netzwerke füllen.
Ein Hinweis erscheint mir noch wichtig:
Wenn es bei den zu übertragenden Daten auf Konsistenz ankommt empfiehlt es sich, den Empfangspuffer mit NDR=TRUE in z.B. einen Arbeits-DB zu kopieren, das war hier vor kurzem Thema.

Grüße von HaDi


----------



## volker (19 Juli 2010)

das mit der datenkonsistenz ist klar.

das beispiel gibts hier


----------



## HaDi (19 Juli 2010)

Hab mir mal das Beispiel angesehen. Die übertragen ja da die selben Daten einmal über eine Verbindung (wie in meinem Beispiel) und dann noch mal parallel auf 4 Verbindungen aufgeteilt, um zu sehen, was das an Performance bringt. Das Synchronisieren dieser 4 Verbindungen macht dann wohl den größten Aufwand aus.
Wenn du mein Beispiel nimmst und den LEN versorgst (geht auch als Konstante) genügt es, zum Testen erst mal den ACT auf TRUE zu setzen und schon geht´s los. Am NDR sieht man dann, wie schnell das Ganze läuft.
Ist das ausreichend (ich weiß ja nicht, in welchem Takt/Zyklus du übertragen willst/musst), dann machst du die Ansteuerung/Auswertung noch ein wenig "hübsch" und fertig ist die Laube.

Grüße von HaDi

[edit]
Den AG_LSEND und AG_LRECV (anstatt AG_SEND und AG_RECV) in der 400er braucht man wohl erst bei Datenmengen über 240 Bytes.
[/edit]


----------



## volker (19 Juli 2010)

hab das von dir samstag meinen bedürfnissen angepasst. läuft wunderbar.
im cp-handbuch hab ich glaube ich gelesen bei 200byte <1ms (finds jetzt gerade nicht mehr).
das reicht mir dicke.


----------

