Wenn dein Problem oder deine Frage geklärt worden ist, markiere den Beitrag als "Lösung",
indem du auf den "Lösung" Button rechts unter dem entsprechenden Beitrag klickst. Vielen Dank!
ich habe ein VI indem eine Schleife läuft, die der Datenerfassung dient. Die Schleifenzeit beträgt 25ms. In der Schleife befindet sich das was im Anhang zusehen ist. Mein Problem, ich brauche mindestens alle 25ms einen Wert, kann daher die Schleifenzeit also nicht höher setzen. Bei 25ms Schleifenzeit bricht die VI-Performance aber zu stark ein, was nur an dem SubVI DAQmx-Lesen liegt.
Komischerweise läuft das Testpanel eines von mir verwendeten Kanals im M&A Explorer total flüssig ohne CPU-Last zu verursachen. Wie kann man den Leistungsverbrauch dämmen? ich hab alles ausprobiert, ohne Erfolg :-(
Vielleicht weigert sich LV den Schmarrn auszuführen, kann sich aber nicht so recht gegen den XP-Scheduler wehren:)Spaß beiseite. Machst du den Task in der Schleife auf und wieder zu? Und für was ist die Interpolation da?
Der Signalverlauf wird umgesetzt in ein Array das ein Element enthält (der Messwert). Ich benötige aber den Messwert als einzelnen Wert und nicht als Array. Die Interpolation erzeugt aus dem Array ein Einzelwert. Dies kostet auch keine Performance, es ist wirklich nur die Funktion DAQmx-lesen. Den Task schließe ich nicht, da ich permanent alle 25ms die Messwerte benötige.
Ok, am besten du lädst das VI hoch. Die Interpolation benötigst du aus zwei Gründen nicht.[list=1]
[*]Um ein Element aus einem Array zu holen gibt es die Funktion Array Indizieren. <>
[*]Wenn du Einzelwerte liest, dann lass dir von DAQmx auch Einzelwerte geben.<>
[st]
' schrieb:Mein Problem, ich brauche mindestens alle 25ms einen Wert, kann daher die Schleifenzeit also nicht höher setzen.
Das stimmt so nicht.
Wenn du alle 25ms einen Messwert (pro Kanal) haben willst, dann stell die AnalogTask so ein, dass die alle 25ms einen Messwert sampled. Lesen tust du von der AnalogTask dann - und zwar alle 500ms - ein 2DArray mit DBL-Messwerten. Das 2DArray liefert dann 20 Werte (= 500ms / 25ms) pro Kanal.
Außerdem: Keiner kann den 25ms-Refresh der einzelnen Werte am Bildschirm verfolgen.
Jeder, der zur wahren Erkenntnis hindurchdringen will, muss den Berg Schwierigkeit alleine erklimmen (Helen Keller).
17.09.2009, 14:59 (Dieser Beitrag wurde zuletzt bearbeitet: 18.09.2009 10:23 von jg.)
@Ichselbst
Ja die Methode mit dem Sammeln der Samples und dem 500ms Refreshzyklus kann man machen. Es scheint dass das Verwenden der Lesefunktion so Leistungszehrend ist. Komischerweise ist das bei der Schreibfunktion nicht so. Naja...
' schrieb:Es scheint dass das Verwenden der Lesefunktion so Leistungszehrend ist.
Die ist an ein Raster gebunden. Möglicherweise wartet sie, bis mindestens ein Sample im Puffer ist. Dann liest das RdVI die Daten und gibt sie zurück. Und dann dauert das Lesen ganau 25ms.
Zitat:Komischerweise ist das bei der Schreibfunktion nicht so.
Weil: Nicht an ein Raster gebunden. Respektive werden die Daten lediglich an einen Treiber gegeben und der gibt dann im Raster von z.B. 25ms aus. Daher Dauert der Aufruf des WrVI eben nur ganz kurz.
Hinweis:
Es ist natürlich alles eine Sache der Konfiguration der Tasks.
Jeder, der zur wahren Erkenntnis hindurchdringen will, muss den Berg Schwierigkeit alleine erklimmen (Helen Keller).
Es gibt ja nur 2 Varianten den Task zu konfigurieren. Entweder ein Sampel oder mehrere Sampels. Ursprünglich wollte ich 1 Sample alle 25ms abrufen. Hätte ein schönes, fürs Auge kontinuierliches, Signal im Diagramm ergeben. Nun nehm ich 40Samples und rufe diese jede Sekunde ab. So kommt es eben nur einmal die Sekunde zu diesem kurzen Stocken beim Aufruf, statt alle 25ms. Komischerweise hatte ich dieses Problem bei der alten Lesefunktion (Anhang) nicht...
Muss man einen task eigentlich wieder schließen, so wie man eine Referenz schließen muss?
' schrieb:So kommt es eben nur einmal die Sekunde zu diesem kurzen Stocken beim Aufruf, statt alle 25ms.
Mir fällt noch was ein.
Frage, bevor du liest, ab, wieviele Daten im Puffer stehen. Die Schleife lässt du mit 12ms anstelle 25ms laufen. Wenn nichts drinsteht, lässt du per True/False-Case alles das weg, was mit der Task zusammenhängt. Steht was im Puffer, liest du genau ein Zeichen aus.
Zitat:Komischerweise hatte ich dieses Problem bei der alten Lesefunktion (Anhang) nicht...
Das kann daran liegen, dass früher alles etwas langsamer ging. Möglicherweise war der Puffer wieder schneller voll, als er auszulesen ging.
Zitat:Muss man einen task eigentlich wieder schließen, so wie man eine Referenz schließen muss?
Ja, natürlich.
Zu jedem Element "Create" - ob Task, Queue etc - muss es immer ein Element "Close" geben. Das gehört sich so. In ganz ungünstigen Fällen kann dir nämlich sonst der Speicher überlaufen.
Jeder, der zur wahren Erkenntnis hindurchdringen will, muss den Berg Schwierigkeit alleine erklimmen (Helen Keller).
