Gigabit-Kommunikation mit einer S7-300

jach0012 · 12 Juni 2009

Hallo,

ich habe eine CPU317F-2DP im Einsatz und muss zyklisch ca. 1MB Daten (ca. 100 DBs) von der SPS auf den PC übertragen.

Das funtioniert mit Deltalogic AGLink auch ganz gut aber es dauert mit 100 Mbits/s einfach viel zu lange und ich würd gerne auf Gigabit umsteigen. Das ist direkt mit der CPU ja nicht möglich.

Ich hab auch eine CP 343-1 Advanced und mit dem sollte doch eigentlich Gigabit möglich sein. Wenn ich mich verbinde geht aber nur eine 100Mbits/s-Verbindung.

Ist der Umweg über den CP überhaupt sinnvoll? Wenn ja, wie richte ich den für Gigabit ein? Habt ihr einen anderen Vorschlag?

Rainer Hönle · 12 Juni 2009

Das Problemist weniger die Netzwerkgeschwindigkeit sindern eher die Reaktionszeiten der SPS. Wenn es schneller gehen soll, dann eher zu einer PBN-CPU greifen (wenn die Zyklusuzeiten kurz sind). Die externe CP ist auch nur über 187,5 KBit/s (Rückwand) angeschlossen. Eine Alternative ist die OnBoard-DP-Schnittstelle (wenn noch verfügbar) und dann über einen Profibusadapter mit 12 MBit/s darauf zugreifen.
Wenn das alles noch zu langsam ist, dann wird es eher teuer.

jach0012 · 12 Juni 2009

Vielen Dank für die schnelle Antwort!

Dann fällt mir nur noch ein die DBs erst zu lesen wenn sie geändert wurden.....aber wie ich das realisieren soll muss ich noch rausfinden.

Rainer Hönle · 12 Juni 2009

jach0012 schrieb:
Vielen Dank für die schnelle Antwort!

Dann fällt mir nur noch ein die DBs erst zu lesen wenn sie geändert wurden.....aber wie ich das realisieren soll muss ich noch rausfinden.

Für diesen Fall bietet AGLink die Unterstützung von BSend/BReceive an. Dann sendet die SPS die Daten wenn sie etwas geändert hat. Dies benötigt allerdings eine prjektierte Verbindung und Verwendung von S7-ConnIE statt S7-TCP/IP.
Eine Alternative ist auch, dass die SPS bei Änderung ein Bit setzt und der PC nur die Bits prüft und bei Änderung dann erst die Daten abholt und ein Quittierbit setzt bzw. das Triggerbit rücksetzt. Dies erfordert keine projektierten Verbindungen. Nur eine Änderung im SPS-Programm. Zu beachten ist in diesem Falle auch die Konsistenz. SPS Darf nur ändern, wenn PC gelesen hat und nicht wenn er gerade liest.

jach0012 · 12 Juni 2009

Das hört sich gut an.

Soweit ich das verstehe muss ich also nur die Verbindung projektieren und AGlink umparametrieren? Funktioniert dass auch sicher mit LabView?
Wie wird die Verbindung in der S7 projektiert? In der Doku finde ich dazu nichts.

Rainer Hönle · 12 Juni 2009

jach0012 schrieb:
Das hört sich gut an.

Soweit ich das verstehe muss ich also nur die Verbindung projektieren und AGlink umparametrieren? Funktioniert dass auch sicher mit LabView?
Wie wird die Verbindung in der S7 projektiert? In der Doku finde ich dazu nichts.

Stichwort hierzu ist NetPro. Außerdem werden die ganzen BReceive-Aufrträge mit AGLink normalerweise asynchron ausgeführt. Dies macht bei LabView wahrscheinlich Ärger. Deshalb doch lieber die Variante mit den Triggerbits verwenden.

jach0012 · 12 Juni 2009

Wenn ich Triggerbits setze brauch ich nur noch ne komfortable Lösung um auf DB-Änderungen zu prüfen. Bei Siemens gibts da ein Beispiel für Prüfsummenerzeugung aber das muss man bezahlen.

Danke für die Hilfe. Am Besten mach ich für die Prüfsummenerzeugung n neues Thema auf.

Human · 12 Juni 2009

Du musst doch einfach nur dein Triggerbit aus der CPU lesen (1 Byte) und bei einer positiven Flanke liest du die Daten aus der SPS, da brauchst du keine Prüfsumme oder sowas!

jach0012 · 12 Juni 2009

Das Problem ist nicht das Lesen, sondern dass es sehr aufwändig ist bei jeder Schreiboperation auf den DB zu prüfen ob es Änderungen gab und das Bit zu setzen.

Lieber würde ich zyklisch bei allen DBs Prüfsummen bilden, die neue mit der alten vergleichen und bei Änderung das TriggerBit setzen.

Key · 15 Juni 2009

Also wie schon erwähnt liegt die Begrenzunh am rückwnadbuss. Hatte erst letztens auch das Problem einen DB mit 12kBytes über ne 300er EthernetCP zu schicken. Durch den Rückwandbuss bin ich bei 2,5 sec für die Übertragung gelandet. Hab jetzt ne 400er und ist mal richtig schnell. Das mit front DP hätte ich auch gern gemacht wenn dieser für die Kommunikation freigegeben gewesen wäre.

Das mit dem Trigger war auch so eine idee bei mir, gerade bei großen Datenmengen.

Aktive Verbindung von SPS zu PC wenn sich Daten ändern mitteilen. Und PC nutzt dann lib zum datentransfer und liest die DBs direkt.

Mit Prüfsumme würd ich nix machen. Muss doch möglich sein auf SPS seite zu sagen wann Daten bearbeitet wurden. Also wenn Daten in DB geschoben werden dann setze Bit und Go...

jach0012 · 15 Juni 2009

Das mit dem Trigger is bei mir eher schlecht. Ich habe ca. 50 Profibusteilnehmer an der S7. Jeder sendet so ca. 24Byte an Daten.
Die brauche ich alle auf dem PC.

Hab fälschlicherweise am Anfang vo 1MB gesprochen. Is natürlich Quatsch

.
Also insgesamt ca 1,2kBytes.
Mit AGLink hab ich in der Applikation eine Dauer fürs Lesen von ca. 2s gemessen.

Im Endeffekt fällt für mich die Lösung mit den Triggerbits sowieso flach, da sich die DBs sowieso ständig ändern da jeder Teilnehmer einen Messwert (Real) hat.
Das Auslagern in einen eigenen Messwerte-DB wäre sehr aufwändig und ich bräuchte für die restlichen Daten immer noch Triggerbits.
Ich muss dann immer auf Änderung prüfen. Jeden Zyklus für jeden über Profibus gelesenen Wert.

Wenn das Geschwindigkeitsproblem am Rückwandbus der 300er liegt und ich die Triggerbits nicht durch z.B. eine Prüfsumme o.Ä. erzeugen kann dann weiß ich auch nicht mehr weiter. Wieviel schneller is der Rückwandbus einer 400er?

S7-ConnIE hat sich noch am Besten angehört. Gibts da keine Möglichkeit dass mit LabView zu verwenden? Zur Not schreib ich was in ner anderen Programmiersprache und binde das dann in LabView ein.
Gibt es zu der Lösung mit S7-ConnIE irgedwelche Unterlagen?

Rainer Hönle · 15 Juni 2009

Wenn sich sowieso dauern etwas ändert, dann bringt auch der Umstieg auf S7-ConnIe nichts. Vorteil hier wäre, dass nur bei seltenen Änderungen die SPS die Daten schickt und nicht der PC dauernd die Daten abfrägt.
Aber AGLink bietet noch weitere Optimierungsmöglichkeiten. Einfach alle DBs mittels AGL_ReadMixEx in einem Rutsch lesen. Dies sollte dann deutlich schneller sein als alle DBs einzeln anzufragen.

Key · 15 Juni 2009

Faktor 10 sollte auf jedenfall möglich sein. Hat mir meine Probleme gelöst. Genaue Messungen hatte ich nur mit ner 300er gemacht. Also konkret hatte ich sogar ein Phenomen das ich mit der CP schneller ein Bit gepollt habe als es in einem Zyklus von der SPS zurückgesetzt wurde. Habe es mir durch den SPS Mann auch nochmal bestätigen lassen. Kann Herr Hönle das evtl. bestätigen. Denn dann würde es ja in den Bereich <5ms gehen. Bei der 300er hatte ich min. 20-25ms Polling erreicht. Bei einer PDU von grob 220Byte(300er) und 440Bytes(400er).

Mit der Mischfunktion gehen aber nur eine bestimmte Anzahl von Bereichen oder? Ähnlich wie bei libnodave!? Da waren es glaub ich 10 oder so. Sprich wenn ich 100 Bits aus 100DBs lesen möchten macht es dann noch 10 Anfragen mit der Mixfunktion wenn die Aufteilung so wäre.

Gruß Key

Rainer Hönle · 15 Juni 2009

Bei der 400er läuft die Kommunikation asynchron zum Zyklus. Deshalb kann es schon passieren, dass man schneller liest als die SPS den OB1 bearbeitet. Ich hatte schon den Fall, dass ein Kunde in einem Baustein am Anfang die relevanten Bits genullt hatte und im Baustein dann die entsprechenden Bits wieder gesetzt hat. Hier hat nun ein memcmp auf dem PC immer wieder Unterschiede in diesem Bereich gezeigt, obwohl an der Anlage nichts passierte. Dies bedeutet, dass selbst Zwischenzustände gelesen werden können. Zum Einsatz kam damals eine 414-3 mit einer 443-1.
In diesem Fall sollte aber vor dem SPS-Wechsel die Zusammenfassung der Anfragen getestet werden.

jach0012 · 19 Juni 2009

So.
Hab nun mit Deltalogic gesprochen. Ergebnis: 1 DB statt 70 -> 5x schneller
Bringt aber Arbeitmit sich....Schnittstelle ändern :-(

Beim Siemens-Support kam garnichts raus. Außer weniger lesen und am SendeCredit schrauben.

Soll angeblich was bringen.

Ich war auch so wahnsinnig und hab einen MD5 anhand des Pseudocodes bei Wikipedia implementiert. Funktioniert auch wirklich (nicht 100% getestet).
Dauert nur leider länger als die Kommunikation an sich. Vieleicht kann ich das mal für was anderes brauchen.

Am Ende werd ich wahrscheinlich 2 DBs machen. Einer für langsame und einer für schnelle Kommunikation....Lese DB 1,1,2,1,1,2 etc...

Rainer Hönle · 19 Juni 2009

Die Alternative ist, wie ich bereits erwähnt hatte, die DBs alle in einem Aufruf abzufragen. Dann kommt mit Sicherheit ein ähnliches Ergebnis raus wie wenn alle Daten in einem DB stehen. Die Frage ist nur, ob LabView die Funktion AGL_ReadMixEx brauchbar unterstützt.
Schick mir mal Deine Telefonnummer per pn. Wir können dann über das Eingemachte reden ;-).

Gigabit-Kommunikation mit einer S7-300

jach0012

Level-1

Rainer Hönle

Level-3

jach0012

Level-1

Rainer Hönle

Level-3

jach0012

Level-1

Rainer Hönle

Level-3

jach0012

Level-1

Human

Level-1

jach0012

Level-1

Key

Level-1

jach0012

Level-1

Rainer Hönle

Level-3

Key

Level-1

Rainer Hönle

Level-3

jach0012

Level-1

Rainer Hönle

Level-3

Similar threads

Wir schützen deine Privatsphäre