Zuviel Werbung? - > Hier kostenlos beim SPS-Forum registrieren

Seite 2 von 3 ErsteErste 123 LetzteLetzte
Ergebnis 11 bis 20 von 21

Thema: Geschwindigkeiten ISO-on-TCP und S7-Kommunikation

  1. #11
    Registriert seit
    20.11.2004
    Ort
    Linz, OÖ
    Beiträge
    1.365
    Danke
    96
    Erhielt 178 Danke für 133 Beiträge

    Standard


    Zuviel Werbung?
    -> Hier kostenlos registrieren
    Zitat Zitat von Ingo dV Beitrag anzeigen
    Ist diese Erfahrung allgemein gültig oder von der Qualität des Switches abhängig (hast du auch unterschiedliche Standard-Switche getestet)? Der Scalance X208 ist ja nicht so wirklich günstig!
    Ich habe bisher 3 Konfigurationen ausprobiert.
    - 1. CPU - Scalance X208 - CPU
    - 2. CPU - Surecom 30€-Switch - Scalance X208 - CPU
    - 3. CPU - Surecom 30€-Switch - Firmennetz (3 manged switches) - CPU

    Weitere Versuche laufen! Mein Ziel ist derzeit, bis Mitte Jänner ein Konzept zu haben, welches ich auf Anlagen einsetzen kann. Hier spielt derzeit Zuverlässigkeit die wichtigste Rolle, da investieren wir auch gern mal einige Hunderter mehr in die Switches.

    mfg
    Maxl

  2. #12
    Registriert seit
    25.06.2003
    Ort
    Emden
    Beiträge
    61
    Danke
    0
    Erhielt 0 Danke für 0 Beiträge

    Standard

    Hallo Maxl.
    Ersteinmal vielen Dank für die Info.
    Es währe sehr nett, wenn du deine Ergebnisse in diesem Threat veröffendlichen würdest.
    mfG
    Ingo dV

    Regelmässiges Versagen ist auch
    eine Form der Zuverlässigkeit

  3. #13
    Registriert seit
    20.11.2004
    Ort
    Linz, OÖ
    Beiträge
    1.365
    Danke
    96
    Erhielt 178 Danke für 133 Beiträge

    Standard

    Zitat Zitat von Ingo dV Beitrag anzeigen
    Es währe sehr nett, wenn du deine Ergebnisse in diesem Threat veröffendlichen würdest.
    Hab schon mal einen Thread mit dem Thema begonnen - hier gings zwar primär um Profinet-IO usw, aber werde dort (wenn möglich) regelmäßig meine Erfahrungen mit meinem Versuchsaufbau schildern.

    http://www.sps-forum.de/showthread.php?t=9946

    mfg
    Maxl

  4. #14
    Registriert seit
    10.10.2006
    Ort
    Essen, NRW, Deutschland
    Beiträge
    46
    Danke
    0
    Erhielt 1 Danke für 1 Beitrag

    Standard

    Ich hab jetzt auch mal mit BSEND / BRCV unter Verwendung unten stehender SPS (2 Stück) einige Tests gemacht. Dabei hab ich jeweils 240Byte aus einem DB verschickt, also 1x hin und 1x zurück. Ansonsten läuft nix auf der SPS, so dass ich eine Zykluszeit von 1ms habe.

    SPS1:
    Manueller Start (auf '1' steuern) des REQ vom BSEND, wodurch auch ein Timer gestartet wurde. Der Timer wurde wieder gestoppt wenn am NDR des BRCV der Datemempfang signalisiert wurde.

    SPS2:
    Die Emfangsbestätigung NDR des BRCV ist direkt mit dem REQ des BSEND verbunden, so dass die angekommenen Daten sofort zurückgeschickt werden.

    Dauer der Kommunikation mit BSEND/BRCV: 30ms

    Das ganze hat natürlich jetzt nix mit Profinet zu tun, denn meine CPs unterstüzen das nicht. War also reine S7-Kommunikation.
    Zwischen den Steuerungen, die direkt nebeneinander stehen, ist ein Hirschmann Switch.
    Ob jetzt Pakete verloren gehen kann ich nicht 100%ig sagen, aber sieht irgendwie nicht danach aus, denn dann mussten die Zeiten ja auch mal wesentlich länger werden. (oder?)

    @Maxl:
    Hab ich da jetzt nen "Fehler" drin? Ich hab ja doch wesentlich schnellere Werte als du.


    Ergänzung:
    8000Byte hin und zurück: 860ms
    1000Byte hin und zurück: 120ms
    Geändert von Kuffel (06.12.2006 um 09:35 Uhr) Grund: siehe 'Ergänzung'
    Gruß,
    Der Kuffel

    Meine SPS: CPU 416-2DP (..XK04..), CP 443-1 (..EX11..)

  5. #15
    Registriert seit
    10.10.2006
    Ort
    Essen, NRW, Deutschland
    Beiträge
    46
    Danke
    0
    Erhielt 1 Danke für 1 Beitrag

    Standard

    Hat sich mit dem Thema zufällig noch mal jemand beschäftigt?
    Gruß,
    Der Kuffel

    Meine SPS: CPU 416-2DP (..XK04..), CP 443-1 (..EX11..)

  6. #16
    Registriert seit
    20.11.2004
    Ort
    Linz, OÖ
    Beiträge
    1.365
    Danke
    96
    Erhielt 178 Danke für 133 Beiträge

    Standard

    Ja, natürlich. Mein Versuchsaufbau liegt nach wie vor bei mir am Schreibtisch.

    Also die von Dir gemessene Zeit kann ich nicht 1:1 nachvollziehen, jedoch ist ist das durchaus plausibel. Ich muss dazusagen, dass ich die Status-Bits der SEND/RECV-Bausteine nicht direkt für die Laufzeitmessung verwende, sondern dass ich ein Bit in den Nutzdaten hin und herschicke.
    Master --> Slave; Slave schickt 1:1 zurück; Master invertiert empfangenes Bit und schickt wieder zu Slave usw.
    Ich messe nun am Master die Zeit vom letzten Zustandswechsel des Bits, bis dieser Zustand vom Slave zurückkommt. Dadurch dann ich die Reaktionszeit in einer realen Applikation recht genau bestimmen.


    Mein Versuchsaufbau läuft mittlerweile seit Donnerstag (7.12.) wieder durch. Werde Ende dieser Woche wieder mal ein Resumée ziehen, und dann den Versuchsaufbau wieder umbauen.


    mfg
    Maxl
    Geändert von Maxl (13.12.2006 um 09:26 Uhr)

  7. #17
    Registriert seit
    10.10.2006
    Ort
    Essen, NRW, Deutschland
    Beiträge
    46
    Danke
    0
    Erhielt 1 Danke für 1 Beitrag

    Standard

    @ Maxl:
    Hast du dir denn mal meine "Messbeschreibung" durchgelesen? Ich komme ja auf ganz andere Werte, aber hab irgendwie keine passende Erklärung dafür. Hast du eine?
    Gruß,
    Der Kuffel

    Meine SPS: CPU 416-2DP (..XK04..), CP 443-1 (..EX11..)

  8. #18
    Registriert seit
    19.09.2006
    Beiträge
    49
    Danke
    0
    Erhielt 2 Danke für 2 Beiträge

    Standard

    Hallo Leute

    also wenn ihr jetzt RFC Verbindungen nutzt ist die Datensicherheit durch das Protokoll an sich sichergestellt, dh das Protkoll sorgt dafür das ein(mehrere) Datenframes von Sender zum Empfänger übertragen werden und dort auch exakt mit dem selben Inhalt ankommen. Ist nun die Hardware die dazwischen geschaltet wurde stabil(keine Ausfälle der Switches oder der Ethernet CPs) kommt auch alles an was abgeschickt wird.

    die Ethernetlandschaft sollte von einem Spezialisten geprüft werden wenn es sehr wichtig ist das eine 100% Verfügbarkeit vorhanden ist.

    am Ethernet CP der S7 gibt es eine Statistikfunktion welche Online angesehen werden kann.

    Hier gibts noch zwei versteckte Befehle welche diese Statistik erweitern und eventuelle Netzwerkfehler aufzeigen.

    1. smcie
    2. history

    diese Befehle einfach blind bei aktivem NCM S7 Diagnosefenster eingeben und schon wird die entsprechende Statistik eingeblendet.

    ansonsten kann ich nur sagen das ich sehr zufrieden bin mit der RCF Kommunikation über ISO on TCP.


    allerdings handhaben wir es bei uns in der Firma auch so das wir synchrone Telegrammquittierungen eingebaut haben damit auch eine zusätzliche Sicherheit auf Softwareebene vorhanden ist.
    Kaum macht mans richtig, schon funktionierts...

  9. #19
    Registriert seit
    20.11.2004
    Ort
    Linz, OÖ
    Beiträge
    1.365
    Danke
    96
    Erhielt 178 Danke für 133 Beiträge

    Standard

    So, schließe meinen Versuch nun mal vorläufig ab.

    Also nochmal mein Versuchsaufbau:
    2 x CPU317-2PN/DP, CP343-1 Lean bei 1. CPU, Scalance X208 Switch, PN/PN-Koppler, Surecom 30€-Switch


    Versuchsaufbau 1:
    Code:
    CPU1 / CP343-1-Lean     CPU2       
      |         |             |
      |  +------+             |
      |  |  +-----------------+
      |  |  |  +-----------------------------------------+  +----> Firmennetz
      |  |  |  |        +----------+    +-------------+  |  |  +--> Laptop
      |  |  |  |        |          |    |             |  |  |  |
      |  |  |  |      X1P1 X1P2  X2P1 X2P2          Surecom-Switch
    Scalance-X208        PN/PN-Koppler
    Versuchsaufbau 2:
    Code:
    CPU1 / CP343-1-Lean                                       CPU2
      |         |                                               |
      |  +------+                                               +----------------+
      |  |                                                                       |
      |  |     +-----------------------------------------+  +-----> Firmennetz <-+
      |  |     |        +----------+    +-------------+  |  |  +--> Laptop
      |  |     |        |          |    |             |  |  |  |
      |  |     |      X1P1 X1P2  X2P1 X2P2          Surecom-Switch
    Scalance-X208        PN/PN-Koppler
    Ich hoffe mal, meine Zeichnungen sind halbwegs verständlich.

    Beim ersten Versuchsaufbau sind die beiden CPUs direkt über den Scalance X208 verbunden, lediglich der PN/PN-Koppler kann nur über den Standard-Switch angesprochen werden. Dieser Aufbau ist ist vom 3. bis 18. Jänner (mit 2 Nächte Ausnahme) durchgelaufen.

    Beim zweiten Versuchsaufbau hängen zwischen den CPUs neben dem X208 und dem Surecom-Switch noch 3 Switches von unserem Firmennetz (100MBit-Anbinung, GBit Backbone). Dieser Versuchsaufbau lief 2 mal über Nacht.


    Die Kopplung erfolgte insgesamt über 6 Protokolle:
    - S7-Verbindung: PUT/GET, USEND/URECV, BSEND/BRECV
    - Profinet IO: Master-Slave-Kopplung (CPU2 = Master, CP343-1 = Slave), PN/PN-Koppler
    - Profinet-CBA

    CBA hab ich nach den ersten Versuchen sofort wieder verworfen, da iMAP meiner Meinung nach für die Kommunikationsprojektierung bei NICHT-Technologiemodulen absolut unbrauchbar ist. Es bleiben also 5!

    1. S7-Verbindung, PUT/GET
    Bei beiden Aufbauten keine messbaren Laufzeitunterschiede. Blockgröße 212 Byte, Signallaufzeit von CPU1 zu CPU2 und retour ca. 150ms

    2. S7-Verbindung, USEND/URECV
    Bei beiden Aufbauten keine messbaren Laufzeitunterschiede. Blockgröße 212 Byte, Signallaufzeit von CPU1 zu CPU2 und retour ca. 75ms

    3. S7-Verbindung, BSEND/BRECV
    Bei beiden Aufbauten keine messbaren Laufzeitunterschiede. Blockgröße 240 Byte, Signallaufzeit von CPU1 zu CPU2 und retour ca. 200ms

    4. Profinet-IO, CPU als Master, CP343-1 Lean als Slave, Profinet-Aktualisierungszeit 2ms
    Konnte hier ebenfalls kaum Laufzeitunterschiede messen, allerdings gab es beim 2. Aufbau einen Busausfall. Nach Erhöhen der Aktualisierungszeit auf 4ms keine Ausfälle mehr. Datenmenge 512 Byte, Signallaufzeit von CPU1 zu CPU2 und retour max. 45ms

    5. Profinet-IO, PN/PN-Koppler
    Datenmenge 256 Byte, Signallaufzeit von CPU1 zu CPU2 und retour max. 8ms (PN-Aktualisierungszeit 8ms) bzw. 16ms (PN-Aktualisierungszeit 4ms). Bei Versuchsaufbau 2 und 2ms-Aktualisierungszeit einmal Busausfall.


    Kommunikationsablauf bei den S7-Verbindungen:
    PUT/GET: Put und Get werden immer nacheinader abgearbeitet, eine gleichzeitige Bearbeitung macht die Verbindung eher langsamer
    SEND/RECV: eine CPU ist "Master", eine ist "Slave". Die Master-CPU sendet Daten, die Slave-CPU sendet nur Daten zurück, wenn zuvor Daten vom Master empfangen wurde. Empfängt der Master nicht binnen einer definierten Zeit die Daten vom Slave, wird erneut gesendet. Es sind 2 Sendwiederholungen möglich, bevor die Überwachung anspricht. Die Differenz zwischen gesendeten und empfangenen Datenblöcken ist die Anzahl der verlorenen Datenblöcke.

    Zur Messung der Signallaufzeit läuft ein Bit in den Nutzdaten im Kreis (kein Takt, sondern Handshake-Signal). Es wird immer die Laufzeit Hin und Zurpck gemessen - als in einer Applikation nutzbare Reaktionszeit kann also die Hälfte der gemessenen Zeit angenommen werden.


    So, Resümee:
    Alle 3 Arten der S7-Kommunikation sind gut einsetzbar bei Datenmengen bis 212 Byte. USEND/URECV ist etwas schneller, PUT/GET etwas leichter zu programmieren. BSEND/BRECV würde ich nur verwenden, wenn ich Datenblöcke > 212 Byte schicken muss. Für Signale, bei denen schnell reagiert weren muss, sind S7-Verbindungen wohl nicht geeignet.

    Müssen wirklich Signale in Echtzeit hin- und hergeschaufelt werden, bleibt wohl nur der Umweg über CP343-1 Lean als Slave oder (besser) ein PN/PN-Koppler.


    Switches
    Ein genaues Urteil zum Thema Switches kann ich wohl erst abgeben, wenn ich mal größere IO-Systeme am laufen hab. Für S7-Verbindungen und Visu-Anbindung sollten Standard-Unmanaged-Switches absolut ausreichend sein.
    Für die IO-Anbindung wird es wohl darauf ankommen, welche Reaktionszeit gefordert wird. Kann man als PN-Aktualisierungszeit 8, 16 oder 32ms verkraften, sind sicher keine Scalance X2xx notwendig, ein Scalance X1xx oder vergleichbare Modelle von Phönix oder Hirschmann sollten absolut ausreichen.


    wie gehts weiter
    Ich arbeite derzeit an einer Anlage, wo 3 F-CPUs über die PN-Schnittstelle gekoppelt werden sollen. Hierbei sollen auch die sicherheitsgerichteten Signale übers Ethernet laufen. Hab morgen einen Herrn von Siemens im Haus, mit dem ich das Thema F-Kopplung über Ethernet durchgehen möchte.
    Zusätzlich werden auch noch Bediengeräte und SEW-Servos an der PN-Schnittstelle betrieben. Erste Ergebnisse mit der Anlage wirds im April geben.


    mfg
    Maxl
    Bin aufgrund §2 der "Rechte des Betreibers" der Forum-Regeln nicht mehr aktiv, da nicht nicht akzeptiere, dass Informationen und Erkenntnisse ohne Quellangabe weitergegeben werden sollen. Jedem steht frei, auf die gleichen Erkenntnisse durch Eigenversuche zu kommen, vor allem Buchautoren.

  10. Folgender Benutzer sagt Danke zu Maxl für den nützlichen Beitrag:

    Perfektionist (24.04.2008)

  11. #20
    Registriert seit
    01.10.2007
    Ort
    Waiblingen
    Beiträge
    3.317
    Danke
    767
    Erhielt 536 Danke für 419 Beiträge

    Standard


    Zuviel Werbung?
    -> Hier kostenlos registrieren
    Zitat Zitat von Maxl Beitrag anzeigen
    ...
    Müssen wirklich Signale in Echtzeit hin- und hergeschaufelt werden, bleibt wohl nur der Umweg über CP343-1 Lean als Slave oder (besser) ein PN/PN-Koppler.
    ...
    Da hab ich heute mal bei Siemens nachgehakt: ob, und warum es nicht möglich ist, so wie bei Profibus eine CPU als PN-Master und eine andere als PN-Slave zu konfigurieren (derzeit kann eine 317-2PN/DP an der PN-Schnittstelle nur Master).
    Antwort: ist in Arbeit. kommt möglicherweise dieses Jahr noch. Soll als Firmwareerweiterung nachrüstbar sein.

  12. Folgender Benutzer sagt Danke zu Perfektionist für den nützlichen Beitrag:

    Maxl (04.06.2008)

Ähnliche Themen

  1. GESCHWINDIGKEITEN Normen?
    Von wincc im Forum Antriebstechnik
    Antworten: 4
    Letzter Beitrag: 15.04.2008, 16:01
  2. Geschwindigkeiten DP/DP Koppler
    Von Front im Forum Simatic
    Antworten: 2
    Letzter Beitrag: 17.03.2008, 10:03
  3. Pumpe mit zwei geschwindigkeiten betreiben.
    Von Johannes Ashur im Forum Antriebstechnik
    Antworten: 5
    Letzter Beitrag: 31.10.2007, 11:51
  4. DDE Kommunikation in VB
    Von vladi im Forum Hochsprachen - OPC
    Antworten: 3
    Letzter Beitrag: 12.12.2006, 21:02
  5. Antworten: 10
    Letzter Beitrag: 25.02.2006, 10:59

Lesezeichen

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •