Skip to Content

SiePortal

Die integrierte Plattform für Produktauswahl, Einkauf und Support - und Verbindung von Industry Mall und Online Support

SiePortalEnglish

Suche

Home
Support Support
{{(apiData.Support | filter:{'rank':1}:true)[0].title}} Support
- Menü derzeit nicht verfügbar
- Menü derzeit nicht verfügbar
- Menü derzeit nicht verfügbar
- {{item.title}}

Produkte & Services
- Menü derzeit nicht verfügbar
- Menü derzeit nicht verfügbar
- {{item.title}}
Support Support
{{(apiData.Support | filter:{'rank':1}:true)[0].title}} Support
- Menü derzeit nicht verfügbar
- Menü derzeit nicht verfügbar
- {{item.title}}
MySiePortal MySiePortal
{{(apiData.MySiePortal | filter:{'rank':1}:true)[0].title}} MySiePortal
- Menü derzeit nicht verfügbar
- Menü derzeit nicht verfügbar
- {{item.title}}
Warenkorb ({{apiData.CartCount}})

Navigation

Geschwindigkeit von S7-Verbindungen über Ethernet

Erstellt von: schneckal am: 23.09.2009 19:24 (15 Antworten)

Bewertung (0)

Dank 3

Result pages:: |; 1 | 2; |

16 Einträge

Einträge pro Seite: 10 | alle

23.09.2009 19:24	Bewerten (0)
schneckal Beiträge: 29 Bewertung: (4)	Ich habe einen Verbund von Steuerungen, die über Ethernet verbunden sind. Dabei werden für die Kommunikation zwischen den Steuerungen S7 Verbindungen genutzt. (genauer Aufbau der Verbindungen siehe Anhang)Jetzt gibt esein Problem mit der Geschwindigkeit mit der die Nutzdaten übertragen werden.Es wurde je eine Verbindung fürs Senden und fürs Empfangen, einmal für StandardKommunikation und einmal für die F-Kommunikation projektiert. Problem ist bei mir in erster Linie die Kommunikation der Standard-Daten.(bei den F-Bausteinen wurdedie Timeout-Zeit auf 1s gestellt) Standard-Teil:Die Daten werden mit SFB8/9 gesendet/ gelesen.EN_R von URECV ist immer auf 1. REQ von USEND wird mit dem DONE-Bit neu gesartet.Jetzt habe ich die Zeit gemessen, die ein Signalwechsel zwischen einer 319er und einer 317er CPU braucht(einmal hin-und zurück). und komme dabei halbwegs konstant auf eine Zeit von ca. 3s.Die Zykluszeiten der Steuerungen: 317er: 30ms, 319er: 4ms Muss ich vielleicht die Senderaten an die unterschiedlichen Zykluszeiten anpassen, evtl. mit SFB12/13 arbeiten, oder was kann ich sonst machen, um die Übertragungsgeschwindigkeit zu verbessern? Dateianhang Verbindungen.jpg (191 Downloads)
schneckal Beiträge: 29 Bewertung: (4)
Vorschlag Bedanken Zitat Antwort

24.09.2009 08:35	Bewerten (0)
cevau Beiträge: 103 Bewertung: (5)	schneckal bei den F-Bausteinen wurdedie Timeout-Zeit auf 1s gestellt) Das hilft Dir zwar hier bestimmt nicht weiter, aber mich würde interessieren ob diese riesige Timeout Zeit für eine F-Funktion überhaupt zulässig ist. MFG
cevau Beiträge: 103 Bewertung: (5)
Vorschlag Bedanken Zitat Antwort

24.09.2009 11:25	Bewerten (0)
schneckal Beiträge: 29 Bewertung: (4)	also, die Timeout Zeiten sind abhängig von der geforderten Anwendung. Wenn ich den Zustand einer Lichtschranke über diese Verbindung übertrage und damit eine Bewegung stoppen will die nur einen halben Meter entfernt ist, ist das sicher nicht zulässig. Natürlich will ich diese Zeit noch minimieren, nur kann ich das zurzeit nicht testen, da die Anlage in Betrieb ist. Jedoch scheint es, als ob die Kommunikation auch mit der Timeout Zeit von 1ssporadisch ausfällt. Hab mich jetzt nur mal auf das Thema des "normalen" Datenaustausches konzentriert. Mit SFB12/13 funktioniert es tatsächlich besser, jedoch kann ich mich für das Anstoßeneines neuenSendeauftrags nicht auf das DONE oder ERROR - Bit verlassen. Hab deswegen zusätzlich diese beiden Bits überwacht und sollte keines von beiden innerhalb einer gewissen Zeit kommen, wird der Auftrag neu angestoßen. Auf jeden Fall war die Kommunikation über PN/PN-Koppler schneller und unkomplizierter...
schneckal Beiträge: 29 Bewertung: (4)
Vorschlag Bedanken Zitat Antwort

24.09.2009 12:55	Bewerten (0)
J_Bell Beiträge: 5822 Bewertung: (412)	Hallo schneckal, ich würde auch sagen das BSEND / BRECV besser geeignet ist für diese Kommunikation. USEND / URECV haben leider den Nachteil, weil sie unkoordiniert sind, das man nie weiß wann die Daten gesendet wurden wenn man sie abholt, da ist es mir lieber das ich vielleicht nicht so viele Telegramme durch bekommen diese aber per Handshake durch die Anwendungsbausteine sicher sind. Deine Beobachtung mit dem Done und Errorkannich leider nicht teilen, ich lasse mein Programm immer darauf triggern... und hatte bis jetzt keine Ausfälle. Ob das aber am F-Programm oder an Zeit OBs liegt die Du vielleicht verwendest kann ich nicht beurteilen. Was den PN/PN Koppler angeht stimme ich Dir zwar zu, aber ich bitte Dich zu bedenken das die Daten von PN generell nicht unbedingtkonsistent sind, sobald ein Datenbereich verlassen wird. Ob dass in einem F-System erstrebsam ist wage ich zu bezweifeln. Viele Grüße J_Bell
J_Bell Beiträge: 5822 Bewertung: (412)
Vorschlag Bedanken Zitat Antwort
Für diesen Beitrag bedanken sich 1 Benutzer schneckal

24.09.2009 14:41	Bewerten (0)
schneckal Beiträge: 29 Bewertung: (4)	Die Kommunikation über PN-Koppler ist zumindest ohne Probleme gelaufen. Ich weiß zwar nicht wie F_SENDDP und F_RECVDP intern arbeiten,gehe davon aus, dasshier Konsistenzprobleme eigentlich zu einer Störung führen sollten, aber bei mir war das nicht der Fall. von der Anwendung her wäre es kein Problem, wenn die Daten nicht konsistent wären, da ich keine Gleichzeitigkeit zwischen einzelnen Signalen brauche. Mir fällt auch spontan keine Anwendung ein, bei der das wichtig wäre. Habe mittlerweile einen Projekierungsfehler gefunden, bin mir aber noch nicht sicher, ob das wesentliche Auswirkungen hat, da ich bis jetzt noch keine Verbesserung beobachtet habe. Bei den R_ID's für die F-Kommunikation müssen laut Bausteinhilfeungerade Nummernverwendet werden und die nächste ID darf nicht verwendet werden. Habe zwar ungerade ID's verwendet, die geraden allerdings für die Standard-Kommunikation verwendet. Ich hoffe, dass damit die Ausfälle der F-Kommunikation behoben sind.
schneckal Beiträge: 29 Bewertung: (4)	Zuletzt bearbeitet von: schneckal am: 24.09.2009 17:59 Zuletzt bearbeitet von: schneckal am: 24.09.2009 17:58
Vorschlag Bedanken Zitat Antwort

30.09.2009 11:43	Bewerten (0)
schneckal Beiträge: 29 Bewertung: (4)	die Kommunikation mit den SFB12/13 auf der Standardseite funktioniert jetzt einigermaßen. Leider kommt es 1-2 mal am Tag zu Ausfällen der F-Kommunikationsbausteine F_SENDS7/F_RECVS7. Die letzten Ausfälle waren besonders massiv. Es wurde beobachtet, dass 2 Kommunikationswege gleichzeitig betroffen waren. 2 RECV-Bausteineder 317er Steuerung(Empfangsdatenvon 2 319er Steuerungen)meldeten einen Timeout, bzw. Sequenznummernfehler(Bit 4+5 des Diagnosebytes der Bausteine). Die Fehler konnten zwar quittiert werden, jedoch kehrten diese immer sofort wieder. Einmal zuerst Bit 5 und danach Bit 4, dann wiederum umgekehrt. Die Kommunikation konnte nicht wiederhergestellt werden, bis die 317er Steuerung neu gestartet wurde. danach lief die Kommunikation für 1-2 Minuten, danach wieder Ausfall. Nach ein paar Mal half auch das nichts mehr(auch kein Neustart der 319er Steuerungen), es wurden daraufhin alle Schaltschränke abgeschaltet und wieder eingeschaltet. Jetzt läuft die Kommunikation wieder. Die Timeout Zeit ist nach wie vor noch auf 1s.
schneckal Beiträge: 29 Bewertung: (4)
Vorschlag Bedanken Zitat Antwort

30.09.2009 12:01	Bewerten (0)
luigi_KSI Beiträge: 56 Bewertung: (27)	Hallo Schneckal, das deutet auf Netzwerkprobleme hin (Performance). Zur Analyse des Telegrammverkehrs (zeitlicher Verlauf der Telegramme) bietet sich ein Netzwerktracetool an. zB. Wireshark (Freeware) oder NetSpector (kostenpflichtig von Inat, aber speziell auf Simatic zugeschnitten). Abhilfe könnte ein eigenes VLAN über die betroffenen Steuerungen sein (wird am Switch konfiguriert). Dadurch werden Broadcasts uä. ausgefiltert. Hatte ähnliches Problem mit Profinet im Kundennetz. VLAN war der Problemlöser. sg Luigi
luigi_KSI Beiträge: 56 Bewertung: (27)
Vorschlag Bedanken Zitat Antwort
Für diesen Beitrag bedanken sich 1 Benutzer J_Bell

30.09.2009 15:25	Bewerten (0)
schneckal Beiträge: 29 Bewertung: (4)	Das Maschinennetz ist noch nicht an das Firmennetz angebunden. Aufteilung in VLAN's ist noch nicht möglich, da an der Anlageselbst nur SCALANCE X108-Switches aufgebaut sind. Ich werde noch einmal nachkontrollieren, ob nicht irgendwo Ringleitungen gelegt sind oder sonstiges. Obwohl ich dann wahrscheinlichwesentlichmehr Probleme haben müsste.
schneckal Beiträge: 29 Bewertung: (4)
Vorschlag Bedanken Zitat Antwort

30.09.2009 16:18	Bewerten (0)
schneckal Beiträge: 29 Bewertung: (4)	Bin jetzt nicht gerade der Netzwerkexperte, dass ich wahrscheinlich viel aus dem aufgezeichneten Verkehr rauslesen könnte. Gibts hierzu irgendwelche Quellen, die man empfehlen könnte, oder Tipps, worauf man achten muss? Müsste dann wahrscheinlich auch einen "echten" Hub besorgen, damit ich den Verkehr überhaupt aufzeichnen kann.
schneckal Beiträge: 29 Bewertung: (4)
Vorschlag Bedanken Zitat Antwort

30.09.2009 16:43	Bewerten (0)
luigi_KSI Beiträge: 56 Bewertung: (27)	ich kann an dieser Stelle das Handbuch des NetSpectors empfehlen. Ist zwar natürlich auf das Produkt zugeschnitten, verrät aber auch einiges über Ethernetkommunikation im Simatic-Umfeld. http://www.inat.de/fileadmin/documents/pdfs/manuals/netspect_d_01.pdf?register=0 Du brauchst dazu natürlcih einen altmodischen Hub, richtig.
luigi_KSI Beiträge: 56 Bewertung: (27)	Zuletzt bearbeitet von: luigi_KSI am: 30.09.2009 16:46 Zuletzt bearbeitet von: luigi_KSI am: 30.09.2009 16:44
Vorschlag Bedanken Zitat Antwort
Für diesen Beitrag bedanken sich 1 Benutzer schneckal

|

Teile diese Seite:

Teile diese Seite auf...

Folgen Sie uns auf