CLF-Node treibt Prozessorlast hoch.

Hallo.

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.

Anzeige

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

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?

' schrieb:Was heisst den "mehrere kHz Daten" ?

> 9kHZ

' 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

Anzeige

Hallo,


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

' 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.

' 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.

Rolf Kalbermatter