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

[volker]

Zuviel Werbung?
-> Hier kostenlos registrieren

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]

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

Grüße von HaDi

 

[volker]

Zuviel Werbung?
-> Hier kostenlos registrieren

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]

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]

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]

Zuviel Werbung?
-> Hier kostenlos registrieren

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]

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]

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]

Zuviel Werbung?
-> Hier kostenlos registrieren

@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]

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]

das mit der datenkonsistenz ist klar.

das beispiel gibts hier

 

[HaDi]

Zuviel Werbung?
-> Hier kostenlos registrieren

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]

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.