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

Ergebnis 1 bis 6 von 6

Thema: OPC und Abtastzeit

  1. #1
    Registriert seit
    22.11.2005
    Ort
    kl.Odenwald
    Beiträge
    716
    Danke
    111
    Erhielt 85 Danke für 71 Beiträge

    Standard


    Zuviel Werbung?
    -> Hier kostenlos registrieren
    Hallo,

    für mich stellt sich dem nächst folgende Frage:

    Wie ist der Einfluss der Abtastzeit eines OPC-Servers - als Beispiel OCP von Deltalogic wenn:
    a ) 1000 Variablen im gleichen DB liegen
    b) 1000 Variablen in 10 DB's aufgeteilt sind.
    c) 1000 Variablen in 100 unterschiedlichen DB's sind.

    Angeblich soll a) erheblich flinker sein. Aber wie groß ist der Effekt tatsächlich?
    "Das Leben ist viel zu kurz, um schlecht zu essen !"
    (Johann Lafer zur SWR3 Grillparty)
    Zitieren Zitieren OPC und Abtastzeit  

  2. #2
    Registriert seit
    07.07.2004
    Beiträge
    3.285
    Danke
    38
    Erhielt 584 Danke für 382 Beiträge

    Beitrag

    Hallo,

    Zitat Zitat von kiestumpe
    a ) 1000 Variablen im gleichen DB liegen
    b) 1000 Variablen in 10 DB's aufgeteilt sind.
    c) 1000 Variablen in 100 unterschiedlichen DB's sind.
    Natürlich ist die Variante a die schnellste. Einfach weil der OPC-Server die Daten in einem Rutsch holen kann. Bei Variante b muss der OPC-Server sich die Werte in 10 Einzeltelegrammen holen, bei Variante c logischerweise in 100 Einzeltelegrammen. Dazu kommt noch ein protokollbedingter, zusätzlicher Overhead durch mehr Telegramme (z.B. Anforderung, Quittierung etc.).
    Es gibt auch OPC-Server, die das automatisch optimieren. Wenn Du z.B. OPC-Items im DBx aus dem Bereich DB10, DW1-10 und DB10,DW21-30 anforderst, holt sich der OPC-Server den ganzen Bereich von DB10, DW1-30 aus der Steuerung. Eben damit der zusätzliche Overhead durch den Protokollrahmen entfällt.
    Ich habe jetzt mal nicht berücksichtigt, dass 1000 Variablen sowieso nicht in einem Rutsch übertragen werden können. Die Anzahl ist abhängig von der MaxPDUSize der S7-CPU, bei der S7-400 440Byte, wenn ich mich jetzt richtig erinnere. Größere Blöcke teilt das Protokoll automatisch in Einzeltelegramme auf, der Anwender merkt davon nichts.
    Also ist es immer vorteilhaft, die Daten in einem DB möglichst lückenlos zu rangieren, ist sowieso übersichtlicher.
    Du hast beispielhaft nach dem Deltalogic OPC-Server gefragt, da kann Rainer Hönle mit Sicherheit genauere Zahlen über die Transferzeiten sagen.
    Übrigens, Abtastzeit beim OPC-Server ist was anderes. Deine Frage ging eher in Richtung Telegrammlaufzeiten und deren Optimierung.

    Gruß

    Question_mark
    ''Ich habe wirklich keine Vorurteile.
    Meine Meinung ist nur die Summe der Erfahrungen" ... (Question_mark)
    Zitieren Zitieren Abtastzeit  

  3. Folgender Benutzer sagt Danke zu Question_mark für den nützlichen Beitrag:

    kiestumpe (17.01.2008)

  4. #3
    Registriert seit
    07.07.2004
    Beiträge
    3.285
    Danke
    38
    Erhielt 584 Danke für 382 Beiträge

    Beitrag

    Hallo,

    Zitat Zitat von Ich
    Übrigens, Abtastzeit beim OPC-Server ist was anderes.
    Nur zur Erklärung : Unter Abtastzeit verstehe ich die am OPC-Server eingestellte CycleTime. Also das Zeitraster, mit dem der OPC-Server die Daten aus der SPS ausliest. Der Anwender kann eine gewünschte CycleTime für das Abtasten am OPC-Server einstellen. Wenn der OPC-Server erkennt, das dieses Zeitraster nicht realisiert werden kann (z.B. weil man in 50ms nach Variante c 100 DB's auslesen will), dreht er automatisch die CycleTime zurück. Dem stehen eben die protokollbedingten Laufzeiten des Datentransfer gegenüber. Insofern betrachte ich das etwas differenzierter.

    Gruß

    Question_mark
    ''Ich habe wirklich keine Vorurteile.
    Meine Meinung ist nur die Summe der Erfahrungen" ... (Question_mark)
    Zitieren Zitieren a, b oder c ???  

  5. Folgender Benutzer sagt Danke zu Question_mark für den nützlichen Beitrag:

    kiestumpe (17.01.2008)

  6. #4
    Registriert seit
    27.10.2005
    Ort
    Schwäbisch Gmünd
    Beiträge
    5.224
    Danke
    630
    Erhielt 955 Danke für 769 Beiträge

    Standard

    Zitat Zitat von kiestumpe Beitrag anzeigen
    Hallo,

    für mich stellt sich dem nächst folgende Frage:

    Wie ist der Einfluss der Abtastzeit eines OPC-Servers - als Beispiel OCP von Deltalogic wenn:
    a ) 1000 Variablen im gleichen DB liegen
    b) 1000 Variablen in 10 DB's aufgeteilt sind.
    c) 1000 Variablen in 100 unterschiedlichen DB's sind.

    Angeblich soll a) erheblich flinker sein. Aber wie groß ist der Effekt tatsächlich?
    Da gibt es noch eine Reihe von weiteren Einflußfaktoren. Grundsätzlich gilt: die schnellste Datenübertragung kann stattfinden, wenn der zu lesende Bereich am Stück vorliegt. Dann ist die Anzahl der abgesetzten Anfragen mit Sicherheit am geringsten und somit die Zeit am kürzesten. Wenn die Daten nicht am Stück vorliegen, bedeutet dies nicht zwangsweise, dass die Anfragezeit zunimmt, da bei 1000 Variablen sowieso mehrere Pakete erforderlich sind und dort dann auch mehrere Bereiche angefragt werden können. Die größte Lesezeit haben mit Sicherheit Variablen, die weit verstreute Bytes sind und nicht zusammengefaßt werden können.
    Ich kann hier leider keine pauschale Angabe machen, wie groß ggf. der Vorteil ist. Hier hilft nur ein Test. Oder schick mir Deine Alternativvorschläge, dann kann ich Dir eventuell eine Abschätzung geben.
    Rainer Hönle
    DELTA LOGIC GmbH

    Ein Computer kann das menschliche Gehirn nicht ersetzen. Engstirnigkeit kann unmöglich simuliert werden. (Gerd W. Heyse)

  7. Folgender Benutzer sagt Danke zu Rainer Hönle für den nützlichen Beitrag:

    kiestumpe (17.01.2008)

  8. #5
    Avatar von kiestumpe
    kiestumpe ist offline Erfahrener Benutzer
    Themenstarter
    Registriert seit
    22.11.2005
    Ort
    kl.Odenwald
    Beiträge
    716
    Danke
    111
    Erhielt 85 Danke für 71 Beiträge

    Standard

    Hallo,

    zunächst mal Danke für die Ausführlichen Informationen.

    Wenn ich das richtig verstanden habe, sind einige wenige mittelgroße Blöcke (200-400Bytes) eine ganz gute Lösung.

    Der Hintergrund ist folgender: Wir haben 2 Anlagensteuerungen als Muster:

    Bei der einen Anlage wird für jeden Prozess ein Baustein von der Visu bearbeitet und direkt von der SPS weiterverarbeitet. Ausserdem gibt's noch Parameter und Messwerte für den jeweiligen Anlagenteil. Insgesamt sind's über 40 Prozesse (also >40DB's).

    Im zweiten Falls gibt's genau einen Übergabe-DB. Über diesen läuft die ganze Kommunikation. Allerdings wurden dort die zugehörigen Datenpunkte nicht immer nach Anlagengruppen sortiert (über 1000Bytes Länge). Nachteilig stellt sich auch heraus, dass bei Erweiterung die Aktualwerte nur auf recht umständliche Weise erhalten werden können (hin und her kopieren).


    Ich schätze wir werden die Variante b) einsetzen.

    Gruss

    Kiestumpe
    "Das Leben ist viel zu kurz, um schlecht zu essen !"
    (Johann Lafer zur SWR3 Grillparty)
    Zitieren Zitieren Wenige mittelgroße DB's  

  9. #6
    Registriert seit
    27.10.2005
    Ort
    Schwäbisch Gmünd
    Beiträge
    5.224
    Danke
    630
    Erhielt 955 Danke für 769 Beiträge

    Standard


    Zuviel Werbung?
    -> Hier kostenlos registrieren
    Zitat Zitat von kiestumpe Beitrag anzeigen
    Hallo,

    zunächst mal Danke für die Ausführlichen Informationen.

    Wenn ich das richtig verstanden habe, sind einige wenige mittelgroße Blöcke (200-400Bytes) eine ganz gute Lösung.

    Der Hintergrund ist folgender: Wir haben 2 Anlagensteuerungen als Muster:

    Bei der einen Anlage wird für jeden Prozess ein Baustein von der Visu bearbeitet und direkt von der SPS weiterverarbeitet. Ausserdem gibt's noch Parameter und Messwerte für den jeweiligen Anlagenteil. Insgesamt sind's über 40 Prozesse (also >40DB's).

    Im zweiten Falls gibt's genau einen Übergabe-DB. Über diesen läuft die ganze Kommunikation. Allerdings wurden dort die zugehörigen Datenpunkte nicht immer nach Anlagengruppen sortiert (über 1000Bytes Länge). Nachteilig stellt sich auch heraus, dass bei Erweiterung die Aktualwerte nur auf recht umständliche Weise erhalten werden können (hin und her kopieren).


    Ich schätze wir werden die Variante b) einsetzen.

    Gruss

    Kiestumpe
    Also die Sortierung für die Anfrage führt der OPC-Server durch. Er fasst auch entsprechende Blöcke zu einer Anfrage zusammen, wenn es sinnvoll ist. Es bringt somit keinen Nachteil, wenn die Variablen "durcheinander" vorliegen. Bei der Blockgröße ist nur der Unterschied zwischen den SPS-Familien zu beachten: die 300er, bis auf 318, ca. 220 Bytes und die 400er ca. 460 Bytes Nutzdaten. Dies handelt der OPC-Server aber alles automatisch und teilt die Anfragen ggf. auf. Aber eine Blockgröße von 200-400 Bytes ist sicher keine schlechte Lösung. Allerdings kommen bei 400 x 40 schon einige Daten zusammen. Das würde ich nicht mehr auf einer 300er laufen lassen (rein aus Kommunikationssicht), denn dort ist die Aktualisierung dann schon etwas zäh.
    Rainer Hönle
    DELTA LOGIC GmbH

    Ein Computer kann das menschliche Gehirn nicht ersetzen. Engstirnigkeit kann unmöglich simuliert werden. (Gerd W. Heyse)

  10. Folgender Benutzer sagt Danke zu Rainer Hönle für den nützlichen Beitrag:

    kiestumpe (17.01.2008)

Lesezeichen

Berechtigungen

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