Zykluszeit bei DAQmx messen

Hallo,

ich habe den halben Tag versucht, die Zykluszeit zu messen, die benötigt wird, um Daten über DAQmx zu lesen und in einem Graphen darzustellen.
Wenn ich eine Sequenzstruktur nehme, im 1. Segment einen Timer starte, im 2. die Daten auslese und anzeige und im 3. die Zeit stoppe, ist meine Zykluszeit (falls die das überhaupt ist) 0 ms.

Ich vermute, die Pufferung der Daten in der DAQ-Hardware macht hier Schwierigkeiten.

Wie kann ich denn mit LabVIEW die genaue Zykluszeit bestimmen (speziell in Verbindung mit DAQmx, um diese mit einer SPS vergleichen zu können)?
Egal ob mit DAQ Assistent oder auf klassischem Weg, es führte zum gleichen Ergebnis.

Es wäre schön, wenn das Vorgehen auch fürs Ausgeben von analogen/digitalen Daten funktioniert bzw. ganz allgemein.

Grüße, Matze

' schrieb:Wie kann ich denn mit LabVIEW die genaue Zykluszeit bestimmen

Welche Zykluszeit willst du denn messen, also wissen?

Die Hardware, die Messwerte sampled, kann eine Zykluszeit haben. Die entspricht dann aber der Abtastrate. Auch ein Programm kann eine Zykluszeit haben. Das wäre dann z.B. die Dauer eine While-Schleife.

Ein DAQmx an sich hat keine Zykluszeit. Ein DAQmx-Rd liest den Puffer leer (oder holt sich die geforderte Anzahl etc.). Und da dieses Lesen sehr schnell geht - und vom Samplen entkoppelt ist - dauert dieses Lesen halt nur sehr kurz (< 1ms).

Hallo,

ich möchte LabVIEW mit einer SPS vergleichen. Daher wird es die Zeit für einen Schleifendurchlauf sein.
Dann habe ich wohl die Zykluszeit von DAQmx gemessen, die nahezu Null beträgt, wie du selbst schreibst.

Wie kann ich denn die gesamte Zykluszeit ermitteln?

Theoretisch: Anzahl der Samples (die du pro Iteration liest) * dt
Praktisch: Mit einem Schieberegister den aktuellen Timerwert mit dem letzten Timerwert vergleichen.

Gruß dimitri

' schrieb:ich möchte LabVIEW mit einer SPS vergleichen. Daher wird es die Zeit für einen Schleifendurchlauf sein.

Genau genommen verstehe ich dein Ansinnen immer noch nicht. Ich gehe mal von folgendem aus: Du hast in der SPS einen zyklischen Ablauf in Form einer Schleife. In der SPS kannst du jetzt den Schleifendurchlauf = Zykluszeit mit dem OP-SchlagMichTot feststellen. Ähnliches willst du jetzt in LV machen: Also Messen der Dauer einer Schleife. Diese beiden Werte kannst du dann vergleichen. Willst du das so haben?

Zitat:Wie kann ich denn die gesamte Zykluszeit ermitteln?

So:

' schrieb:Mit einem Schieberegister den aktuellen Timerwert mit dem letzten Timerwert vergleichen.

Ob es sinnvoll ist, SPS mit LV zu vergleichen, kommt darauf an, was genau der Sourecode machen soll. Ein Beispiel:
In der SPS wird man einen (1) Wert samplen, berechnen und für Dokumenation speichern. Hieraus kann man eine Zykluszeit bestimmen. In LV geht das etwas anders: In LV werden x Werte gesamplet, x Werte berechnet und x Werte für Dokumentation gespeichert. Diese X Werte entsprechend dann einer Zykluszeit. Willst du die mit SPS vergleichen, musst du den LV-Wert also durch X teilen.

Willst du den Ablauf Samplen-Berechnen-Ausgeben (also eine Steuerung/Regelung) vergleichen - geht das mit LV unter Windows per se nicht.

' schrieb:Ähnliches willst du jetzt in LV machen: Also Messen der Dauer einer Schleife. Diese beiden Werte kannst du dann vergleichen. Willst du das so haben?

Ja, genau.

Ich lasse mir euren Vorschlag morgen durch den Kopf gehen und gucke, ob ich es verstanden habe. Danke vorab schonmal.

' schrieb:Willst du den Ablauf Samplen-Berechnen-Ausgeben (also eine Steuerung/Regelung) vergleichen - geht das mit LV unter Windows per se nicht.

Hm, wie meinst du das?

Dass ein normales Windows nicht echtzeitfähig ist, ist klar. Aber wieso lässt sich keine Regelung realisieren?

Grüße

' schrieb:Aber wieso lässt sich keine Regelung realisieren?

Eine Regelung als solche geht schon - aber eben nicht mehr, wenn die Zykluszeit kleiner 10ms sein soll (was eh schon viel ist). Da würden möglicherweise nicht wiederholbare "Unterbrechungen" im Regler auftreten. Regelungen ab 100ms, also z.B. für Temperaturen, kann man aber machen.

Hm ok.

Habe ich das mit der Zeitmessung richtig umgesetzt (Zuhause habe ich kein DAQ installiert, daher kann ich das nicht komplett zusammenstellen)?

   

In das 1. Sequenz-Frame würde ich dann den DAQ-Code schreiben (DAQ Assistent) oder beim klassischen Weg eben auslesen und schreiben (der Task wird vor der Schleife erzeugt und danach beendet).

Seltsam ist, dass beim gezeigten Blockdiagramm eine Zeit < 100 ms angezeigt wird, obwohl ich 100 ms pausieren lasse. Und bei Windows müsste das doch eher länger als 100 ms sein, da andere Prozesse in der Zwischenzeit auch abgearbeitet werden.

Grüße

' schrieb:Habe ich das mit der Zeitmessung richtig umgesetzt?

Erst mal ja.

Zitat:Seltsam ist, dass beim gezeigten Blockdiagramm eine Zeit < 100 ms angezeigt wird, obwohl ich 100 ms pausieren lasse.

Hilfe lesen!

Du lässt nicht pausieren, du warten bis zum nächsten Raster von 100ms. Du verwendest nämlich den Metronom. Der wartet "im Raster". Wenn du das Element Wait(ms) verwendest, geht's.

Wenn dein Programm startet zum Zeitpunkt 1295ms und der Metronom wartet bis zum nächsten Vielfachen von 100ms, also bis zum Zeitpunkt 1300ms, dann ist die Differenz 5ms => Anzeige kleiner als 100ms. Der Fehler tritt allerdings nur beim ersten Schleifendurchlauf auf. Interessant ist aber, dass sich der Fehler über mehrere Sekunden hinzieht. Das kommst dadurch weil die ersten 95ms halt ewig fehlen. Der prozentuale Anteil der 95ms an der Gesamtzeit wird aber kleiner, sodass nach Minuten doch wieder 100ms heraus kommt.

Du kannst auch folgendes machen: Nimm vor der While-Schleife nicht das Element "Timer auslesen", sondern den Metronom (hat den Ausgang "aktuelle Zeit in ms"). In der Schleife lässt du dann den Metronom und nimmst auch hier den Ausgang "Aktuelle Zeit". Jetzt kommt sofort und sehr oft genau 100,000 ms heraus.

' schrieb:Erst mal ja.

Was heißt das genau? Ganz scheint es ja dann doch nicht zu passen.

' schrieb:Hilfe lesen!

Stimmt, ich habe es verwechselt, Tatsache. Danke für die ausführliche Info.