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!
Hat schonmal jemand die Feststellung gemacht, dass ein Call Libary Function Node in einer While bzw. For-Schleife bei entsprechender Aufruf-Frequenz die Prozessorlast hoch treibt?
Ist bei mir der Fall. Wenn ich den gleichen Code in C schreibe (d.h Schleife in C implementiert) sinkt sie extrem ab. Der CLF-Node wird dabei nur einmal aufgerufen.
Ich denk man wird nicht viel dagegen machen können, aber interessiert mich ob jemand schonmal solche Erfahrungen gemacht hat.
Wenn ich das richtig verstehe, dann ist dieser Effekt vollkommen unabhängig von deinem DLL-Aufruf.
Lass mich sehen, ob ich richtig verstehe:
1. Du hast eine Schleife (While oder FOR, ist egal).
2. In der Schleife hast du einen DLL-Aufruf, der aber recht kurz ist.
3. Du hast in der Schleife keine weiteren Verzögerungselemente (z.B. ein wait oder so).
LV lässt jetzt die Schleife so schnell wie möglich abarbeiten, somit geht natürlich automatisch die Prozessorlast hoch. Das ist aber unabhängig vom DLL-Aufruf. Mach mal z.B. eine leere While-Scheife, bei der du nur einen Stop-Button als Abbruchbedingung anschließt und schau dir dann die Prozessorlast an...
MfG, Jens
Wer die erhabene Weisheit der Mathematik tadelt, nährt sich von Verwirrung. (Leonardo da Vinci)
!! BITTE !! stellt mir keine Fragen über PM, dafür ist das Forum da - andere haben vielleicht auch Interesse an der Antwort!
Ja.
Das mit der leeren While-Schleife hab ich schon gemerkt.
Naja ich nutze ein VI mit ner blockierenden Funktion (UDP lesen). D.h. die Schleife kann nur so schnell ausgeführt werden wie Daten an den UDP gesendet werden. Das UDP VI stellt also schon sowas wie nen "Timer" dar.
Bin davon ausgegangen, dass der Aufruf der Library das Problem ist, da die While-Schleife nicht so schnell ausgeführt werden kann wie es möglich wäre. Da ich aber mit mehren kHz Daten über UDP erhalte, stoß ich bereits an die Grenzen der While-Schleife. Das die so "lahm" ist bzw. LV hätte ich jetzt nicht erwartet. Is also nen LV Problem.
' schrieb:Da ich aber mit mehren kHz Daten über UDP erhalte, stoß ich bereits an die Grenzen der While-Schleife. Das die so "lahm" ist bzw. LV hätte ich jetzt nicht erwartet. Is also nen LV Problem.
soso, ein LabVIEW Problem.
Was heisst den "mehrere kHz Daten" ?
Du möchtest mehrere tausend mal pro Sekund via UDP eine gewisse Datenmenge lesen, zusätzlich mittels einer DLL berechnen/auswerten?
.·´¯)--> Leben ist das, was dir passiert, wenn du eifrig dabei bist andere Pläne zu machen <--(¯`·.
' schrieb:Du möchtest mehrere tausend mal pro Sekund via UDP eine gewisse Datenmenge lesen, zusätzlich mittels einer DLL berechnen/auswerten?
Ja.
Berechnen auswerten muss erstmal garnich sein. Momentan hole ich die Daten nur ab und Speicher sie schnell weg um erstmal so wenig wie möglich Rechenzeit für andere Dinge zu verbrauchen. Ausgewertet wird nach der Messung.
Und, kannst du alle Daten speichern resp. lesen ?
Ich kann mich auch täuschen, aber ich denke das es nicht möglich ist 9000 mal pro sekunde ein UDP-Read mit Timeout 1ms erfolgreich zu machen.
Wenn du alle Daten lesen kannst, wo oder was ist eigentlich genau das Problem.
Gruss
Roland
.·´¯)--> Leben ist das, was dir passiert, wenn du eifrig dabei bist andere Pläne zu machen <--(¯`·.
Anzeige
06.02.2008, 14:09 (Dieser Beitrag wurde zuletzt bearbeitet: 06.02.2008 14:12 von dc6xs.)
ein paar Ideen, die mir beim Lesen dieses Threads kamen:
A) Muss für jeden einzelnenen Messwert ein UDP-Paket versendet werden?
Wenn nicht, warum dann nicht 10-100 Messungen lokal speichern und dann in einem Rutsch übertragen.
B) die Kommuniktaion komplett an die DLL übertragen, sprich Du startest die DLL aus LV heraus (mit allen benötigten Parametern)und die DLL speichert die Daten auf Platte oder in einen Speicherbreich, aus dem man per LV dann die Daten holt und weiter verarbeitet. (Oder ist die Datenmenge so groß das der Arbeitsspeicher des PC nicht ausreicht?) Eventuell ist auch ein FIFO-Buffer hier sinnvoll.
C) Bisherige Methode allerdings auf RT-Basis umsetzen.
Gruß, Robert
Bitte Beachten:
Die obenstehenden Texteile können unter Umständen Sarkasmus und Ironie enthalten, für nicht erkannten Sarkasmus oder nicht erkannte Ironie wird keine Haftung übernommen.
N.B.: "Multiple exclamation marks, " he went on, shaking his head, "are a sure sign of a deseased mind." - Terry Pratchett
' schrieb:Und, kannst du alle Daten speichern resp. lesen ?
Nur wenn ich das Lesen+Abspeichern in eine C-Funktion mit der Schleife auslagere.
' schrieb:Ich kann mich auch täuschen, aber ich denke das es nicht möglich ist 9000 mal pro sekunde ein UDP-Read mit Timeout 1ms erfolgreich zu machen.
Nur entweder Oder.
9000 mal UDP-lesen oder noch schneller ist in LV nicht möglich, da die While-Schleife alles ausbremst.
Man kann die Daten zwar in einem UDP-Buffer erstmal zwischenspeichern vor dem Abholen, allerdings bekomm ich den Buffer nicht groß genug, so dass er vorher überläuft.
' schrieb:Wenn du alle Daten lesen kannst, wo oder was ist eigentlich genau das Problem.
Das Daten verloren gehen, wenn man es nicht mit C/C++ macht.
Mir wurde vorgegeben es in LabVIEW zu machen um die Übersichtlichkeit zu waren, also nicht noch externen Code einzubinden. Es sollen auch Leute damit zurecht kommen die kein C können.
An der Stelle scheinen aber die Grenzen von LV, in Verbindung mit dem System, erreicht zu sein und man kommt nicht um C/C++ herum.
' schrieb:A) Muss für jeden einzelnenen Messwert ein UDP-Paket versendet werden?
Ja. Bzw. das muss man dann den hersteller der karte fragen, ob er das nicht anders macht. Aber ich glaube kaum, dass er seine Karte an LabVIEW anpasst.
' schrieb:B) die Kommuniktaion komplett an die DLL übertragen, sprich Du startest die DLL aus LV heraus (mit allen benötigten Parametern)und die DLL speichert die Daten auf Platte oder in einen Speicherbreich, aus dem man per LV dann die Daten holt und weiter verarbeitet. (Oder ist die Datenmenge so groß das der Arbeitsspeicher des PC nicht ausreicht?) Eventuell ist auch ein FIFO-Buffer hier sinnvoll.
Danke.
Genau so funktioniert es bisher schon.
13.02.2008, 09:42 (Dieser Beitrag wurde zuletzt bearbeitet: 13.02.2008 09:43 von rolfk.)
' schrieb:Ja. Bzw. das muss man dann den hersteller der karte fragen, ob er das nicht anders macht. Aber ich glaube kaum, dass er seine Karte an LabVIEW anpasst.
Danke.
Genau so funktioniert es bisher schon.
Also Mal grundsätzlich ein paar Dinge:
- Ja die CLN hat Overhead um zumindest ansatzweise zu versuchen das LabVIEW Environment von unschönen Dinge die eine DLL machen kann etwas zu schützen. Das kann man nicht ausschalten.
- Ist das UDP Protokoll bekannt? Dann mach das Ganze direkt in LabVIEW. Viel einfacher zu debuggen und wahrscheinlich auch noch schneller auch.
- Hast Du die CLN konfiguriert um reentrant zu sein? Ansonsten wird der DLL Aufruf im UI Thread getan und der macht noch ein paar andere Dinge in LabVIEW und ist dann voll blockiert während Deine DLL auf Daten wartet.
/
CLF-Node treibt Prozessorlast hoch.
