LabVIEWForum.de

Irgendwo in meinem System ist ein Flaschenhals

Folgender Aufbau:
- Siemens Umrichter Sinamics S120
- Anbindung über CP5711 und Simatic NET OPC-Server
- zyklische Kommunikation (DPV0) und azyklische Kommunikation (DPV1)
- LabView steuert den Umrichter und liest Daten von ihm
- Datenbindung über DataSocket

und nun: ich bekomme exakt alle 100ms Werte vom Stromrichter. Wenn ich eine For-Schleife bastele, die den Uhrzeitstempel auf die X-Achse eines Diagrammes projeziert und den über DataSocket gelesenen Wert auf die Y-Achse, ändert sich der Wert exakt alle 100ms.
Als Diagrammtyp hab ich Linie mit punkten ausgewählt, und lineare Interpolation. Die Schleife hat eine 1ms-Bremse in Form der "bis zur nächsten Vielfachen von ms warten"-Funktion, mit 1ms vorbelegt.

trotzdem bekomme ich in dem Diagramm nur alle 10ms einen Datenpunkt auf die Linie, und nur alle 100ms ändert sich der Wert. Trotz linearer Interpolation ändert sich der Wert stufig, ohne Zeitverzögerung...

hat jemand ne Ahnung woran diese Zeitintervalle liegen könnten? Den OPC habe ich in der Hardwarekonfig auf eine Zykluszeit von 1ms eingestellt, der Sinamics sollte die Werte auf jeden Fall auch deutlich häufiger wie 10mal pro Sekunde zyklisch kommunizieren, ich erwarte hier eher eine Größenordnung von 1-20ms. Die physikalische Zykluszeit ist bei meinem Aufbau <1ms...

vielen Dank schonmal für eure Hilfe!

Gruß
Chris

Hallo Chris,

du liest einen Wert, welcher sich nur alle 100ms ändert, mit 100fachem Oversampling (=1ms Takt) ein und wunderst dich, dass sich der Wert so selten ändert???

' schrieb:Den OPC habe ich in der Hardwarekonfig auf eine Zykluszeit von 1ms eingestellt, der Sinamics sollte die Werte auf jeden Fall auch deutlich häufiger wie 10mal pro Sekunde zyklisch kommunizieren, ich erwarte hier eher eine Größenordnung von 1-20ms. Die physikalische Zykluszeit ist bei meinem Aufbau <1ms...

Und der PC-seitige Anteil an der OPC-Datenübertragung kann auch die eine Millisekunde machen? Da kenn ich von Siemens aber andere Zeiten, nämlich 100ms.

Nachtrag:

Zitat:Die Schleife hat eine 1ms-Bremse in Form der "bis zur nächsten Vielfachen von ms warten"-Funktion, mit 1ms vorbelegt.

Ob da tatsächlich eine (1) Millisekunde gewartet wird, kann auch von der Hardware und der Software des Rechners abhängen.

' schrieb:Hallo Chris,

du liest einen Wert, welcher sich nur alle 100ms ändert, mit 100fachem Oversampling (=1ms Takt) ein und wunderst dich, dass sich der Wert so selten ändert???

ich erwarte eigentlich eine schnellere Änderung des Wertes, deshalb das Oversampling.

Wenn der OPC natürlich nur 100ms kann, würde das einiges erklären. Ich kann in der Hardwarekonfig aber bis 1ms runterstellen. Da ist wohl eine Supportanfrage bei Siemens nötig


ich hab inzwischen den Wert der "ms warten"-Funktion auf 0 gestellt, dann sehe ich selten (zufällig?) auch mal Aktualisierungen im Bereich 70-80ms...
Nachwievor bleiben die Aufzeichnungspunkte aber im LabView bei 10ms. Und was mich hier auch wundert: im Diagramm gibt es Punkte, an denen 2 Werte zum gleichen Zeitpunkt abgebildet sind. (d.h. ein senkrechter Schritt). Wie ist das möglich? Ist es so, dass LabView pro Schleifendurchlauf mehrere Werte aufnimmt, aber nur einen Zeitpunkt?
Können die 10ms eine Begrenzung von LabView sein, weil es auf einem PC nicht sinnvoll ist mit kürzeren Zeitintervallen zu arbeiten?

Mein eigentliches Problem ist, dass ich eine möglichst kurze Zykluszeit erreichen, und diese mit LabView messen möchte... gibt es da noch eine andere Möglichkeit?

' schrieb:ich hab inzwischen den Wert der "ms warten"-Funktion auf 0 gestellt, dann sehe ich selten (zufällig?) auch mal Aktualisierungen im Bereich 70-80ms...
Nachwievor bleiben die Aufzeichnungspunkte aber im LabView bei 10ms. Und was mich hier auch wundert: im Diagramm gibt es Punkte, an denen 2 Werte zum gleichen Zeitpunkt abgebildet sind. (d.h. ein senkrechter Schritt). Wie ist das möglich?

Ja, das hat aber nicht unbedingt etwas mit LabVIEW, sondern eher mit Windows zu tun. Die Funktion "Get Date/Time in Seconds" hat (wenn ich mich richtig erinnere) je nach Windows und Hardware nur eine Auflösung von gut 15 ms.

Gruß, Jens

' schrieb:Datenbindung über DataSocket

Das Datasocket-Lesen-Element hat einen Eingang "Warten auf neuen Wert". Damit sollte es möglich sein, die Mindestzeit zwischen zwei Lesezugriffen zu bestimmen.

' schrieb:Das Datasocket-Lesen-Element hat einen Eingang "Warten auf neuen Wert". Damit sollte es möglich sein, die Mindestzeit zwischen zwei Lesezugriffen zu bestimmen.

danke für den Tip! das funktioniert prima und vereinfacht meine Schleife auf das wesentliche.
die OPC-Aktualisierungszeit ist und bleibt genau 100ms. Ich habe jetzt mal den Siemens-Support bemüht, mal gucken was die meinen...

so, nach Rücksprache mit dem Support liegt das Problem wohl doch auf LabView-Seite. Es muss irgendwo OPC-Client-Einstellungen geben, in den auch die Zykluszeit des Datenaustauschs zwischen LabView und dem OPC-Server erfolgt. Diese Zeit ist unabhängig vom eigentlichen Buszyklus, da der OPC ja mit eigenem Zyklus auf das Prozessabbild der Ein- und Ausgänge der CP zugreift. Im Simatic OPC-Scout kann ich diese Zeit einstellen, wenn ich den Scout als Client benutze. Bei LabView hab ich diese Einstellung bis jetzt noch nicht gefunden.

Weiß irgendjemand wo es in LabView OPC-Client Einstellungen gibt?


Und dann noch eine kleine Programmtechnische Frage: Über die For-Schleife schreibe ich ja Zeit und Wert in ein Array um es im Diagramm darzustellen. Wie kann ich die Differenz aus dem jeweils aktuellen Zeitwert und dem Zeitwert des Schleifendurchlaufs davor bilden, um sie anschließend in ein Array zu schreiben und den kleinsten Wert herauszufinden?

Danke nochmal für eure Hilfe!

' schrieb:so, nach Rücksprache mit dem Support liegt das Problem wohl doch auf LabView-Seite.

[*zensiert*]

Zitat:Es muss irgendwo OPC-Client-Einstellungen geben, in den auch die Zykluszeit des Datenaustauschs zwischen LabView und dem OPC-Server erfolgt.

LabVIEW greift mit den Elementen des Datasocket auf die OPC-Schnittstelle (quasi der OPC-Scout) zu, die von OPC-Lieferanten (hier also Siemens) zur Verfügung gestellt wird. Wenn diese Schnittstelle, ob das nun ein Server oder ein Client ist spielt keine Rolle, neue Daten nur langsam zur Verfügung stellt - ist doch LabVIEW nicht Schuld. Die Zugriffsgeschwindigkeit von LabVIEW auf den OPC-Server geschieht alleine dadurch, dass du z.B. alle 5ms einen expliziten Lesebefehl machst. Der Lesebefehl kann nun mit oder ohne "Warten auf neue Daten" geschehen (wobei "neue Daten" nur heißt "neues Datenpaket").

Nimm einen OPC-Server von B&R - der geht um einiges schneller als der von Siemens. Wie kann das wohl sein?

Zitat:Diese Zeit ist unabhängig vom eigentlichen Buszyklus, da der OPC ja mit eigenem Zyklus auf das Prozessabbild der Ein- und Ausgänge der CP zugreift. Im Simatic OPC-Scout kann ich diese Zeit einstellen, wenn ich den Scout als Client benutze.

Ich glaube mich zu erinnern, dass in der Beschreibung steht: "Minimum 100ms".

Zitat:Bei LabView hab ich diese Einstellung bis jetzt noch nicht gefunden.

Mir ist gerade nicht bewusst, dass es da was zum Einstellen gibt. Einfach so schnell wie's geht die Datasockets ausführen.

Wie überträgst du denn die Daten über den OPC? Einzeln oder im Block? Du kannst einen Block definieren, der aus einer beliebigen Anzahl von Einzelwerten bestehen kann.

Zitat:Weiß irgendjemand wo es in LabView OPC-Client Einstellungen gibt?

Wenn, dann beim Erstellen der OPC/Datasocket-Referenz.
[*grübel*]
Da geht glaub ich bloß der Zugriffsmode (rd, wr, rd/wr) und Timeout.

Zitat:Wie kann ich die Differenz aus dem jeweils aktuellen Zeitwert und dem Zeitwert des Schleifendurchlaufs davor bilden,

Einfach subtrahieren. Nimm dazu ein Schieberegister und leg da den aktuellen Zeitstempel rein.

Also: Ich habe gerade mal einen OPC-Trace durchgeführt (das geht über die SimaticNet Konfigurations-Konsole) und dabei folgendes Festgestellt:

- wenn ich den OPC Scout als Client nutze mit 4ms aktualisierungszeit erfolgt laut Trace alle 10-11ms ein Zugriff auf den Profibus
- wenn ich LabView als Client nutze erfolgt alle 100-101ms ein Zugriff.

ich habe mal ein wenig gesucht... und gefunden: im Server Explorer von LabView findet man den Simatic Net OPC. Den kann man nutzen wie den OPC Scout, und da kann man auch zeiten einstellen. Und siehe da, wenn ich dort die Item-Aktualisierungszeit auf 10ms stelle, erfolgt wieder alle 10ms ein Zugriff. Allerdings nur aus diesem Server Explorer, über das VI sinds wieder 100ms.

Der OPC scheint also mehr als 100ms zuzulassen, das wurde mir auch von Siemens-Seite aus so bestätigt.
Die einzige 100ms-Grenze die es dort gibt bezieht sich auf das Protokoll S7-Verbindung, das ist nicht so schnell. Ich arbeite aber mit DP-Protokoll.

Zitat:LabVIEW greift mit den Elementen des Datasocket auf die OPC-Schnittstelle (quasi der OPC-Scout) zu, die von OPC-Lieferanten (hier also Siemens) zur Verfügung gestellt wird. Wenn diese Schnittstelle, ob das nun ein Server oder ein Client ist spielt keine Rolle, neue Daten nur langsam zur Verfügung stellt - ist doch LabVIEW nicht Schuld. Die Zugriffsgeschwindigkeit von LabVIEW auf den OPC-Server geschieht alleine dadurch, dass du z.B. alle 5ms einen expliziten Lesebefehl machst. Der Lesebefehl kann nun mit oder ohne "Warten auf neue Daten" geschehen (wobei "neue Daten" nur heißt "neues Datenpaket").

Der OPC-Server läuft auf dem PC, bzw. dem Profibus-CP, und der wird über die Hardwarekonfiguration parametriert. In meinem Falle mit 4ms, er lässt also 4ms als kürzeste Zeit zu. Der OPC Client liest und schreibt die Daten, und zwar mit einer eigenen Geschwindigkeit, die ich irgendwo vorgeben können muss. Die Langsamere der beiden geschwindigkeiten bestimmt die endgültige Datenaktualsierung.
Der OPC-Scout ist nicht die OPC-Schnittstelle, sondern ein Client, die Daten aus dem OPC Server liest und schreiben kann. Praktisch genau das gleiche, was LabView in meinem Falle auch sein sollte.

die Datenübertragung zum OPC erfolgt in 16bit-Blöcken (das entspricht dem PZD des Stromrichters). Zur Zykluszeitmessung wird im Moment von LabView nur gelesen, über DataSocket: lesen, und zwar genau ein Eingangsword, d.h. die 16bit.

Das mit dem Schieberegister probier ich aus, danke für den Tip. Vor lauter Zykluszeiten komm ich gar nicht mehr zum Programmieren, und das wo ich doch als Energietechniker mit der Bitpopelerei eigentlich gar nix zu tun haben wollte