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!
bei unserem Projekt benutzen wir zwei NI-PXI 6514 Digital I/O-Karten.
Wir fragen so ca 50 Ein/Ausgänge ab.
Unser Problem ist das sich die CPU-Auslastung langsam aufschaukelt.
Da sich die CPU-Auslastung merklich verringert wenn ich diese Abfrage manuell beende denke ich das das auch mein Problem ist.
Ich habe die Schleife mit den Eingängen mal hochgeladen. Vielleicht kann mir jemand verraten wie ich diese Abfrage besser gestalten kann.
Was mir auch aufgefallen ist:
das wenn die CPU auf ca 60% gestiegen ist und ich dann die beiden Schleifen mir den Ein/Ausgängen stoppe fällt die CPU auf ca 10%.
Nehme ich die Schleifen wieder rein springt die CPU wieder auf 60% und steigt langsam an...
Erst mit dem stoppen des Programms kriege ich die CPU wieder runter.
Die Eingänge werden in Queues geschrieben und an anderer Stelle im Programm abgefragt.
Developer Suite Core -> LabVIEW 2015 Prof.
2006
EN
71083
Deutschland
CPU-Auslastung steigt auf 95%
Irgendwie steige ich bei Deinem Programm nicht durch. Was machen die ganzen Queues denn dort?
Und "Index Array" sehe ich auch viel zu oft. Du weißt, dass man das nach unten aufziehen kann?!
Gruß Markus
-------------------------------------------------------------------------- Bitte stellt mir keine Fragen über PM, dafür ist das Forum da - andere haben vielleicht auch Interesse an der Antwort !!
--------------------------------------------------------------------------
12.05.2010, 18:20 (Dieser Beitrag wurde zuletzt bearbeitet: 12.05.2010 18:32 von IchSelbst.)
Ich wage mich mal wieder vor und sage folgendes: Das wird so garnix.
' schrieb:Unser Problem ist das sich die CPU-Auslastung langsam aufschaukelt.
Kann ich mir gut vorstellen.
Es ist zwar, wie es sich gehört, zu jedem Queue anfordern ein Queue löschen vorhanden. Aber: Bei so vielen Queues und ständig neue Queues anfordern, weigert sich LabVIEW bestimmt, die Queues sofort freizugeben. Das kann dazu führen, dass die Prozessorauslastung langsam ansteigt. Werden denn die Queues ausgelesen?
Was aber viel schlimmer ist: Das BD ist viel zu unübersichtlich. Ich bin der Meinung, dass der Algorithmus durch geschicktes Datenmanagement und SubVIs um Potenzen vereinfacht werden kann. Warum jedes Bit einzeln verschicken? Warum per Queue und nicht per Melder? Einfach das komplette Array per Melder verschicken. Wer ein bestimmtes Bit haben will, soll es sich aus dem Array holen.
Zitat:Da sich die CPU-Auslastung merklich verringert wenn ich diese Abfrage manuell beende denke ich das das auch mein Problem ist.
... was mich in meiner Meinung zu den Queues bestärkt ...
Zitat:Vielleicht kann mir jemand verraten wie ich diese Abfrage besser gestalten kann.
Siehe oben.
Zitat:Die Eingänge werden in Queues geschrieben und an anderer Stelle im Programm abgefragt.
Eine Queue wird nur dann verwendet, wenn einmalig ein Datum verschickt werden soll, das nicht verloren gehen darf. Queues müssen zwangsweise ausgelesen werden. Melder werden verwendet, wenn ein aktueller Zustand veröffentlicht werden soll. Melder müssen nicht zwangsweise ausgelesen werden. Letzteres ersehe ich - bisher - aus deinem Algorithmus.
Nachtrag 1:
Wo sind denn die Anzeigeelemente auf dem FP?
Jeder, der zur wahren Erkenntnis hindurchdringen will, muss den Berg Schwierigkeit alleine erklimmen (Helen Keller).
Lies aus dem DAQmx die 32bit-Zahl aus, wandel die in ein Array of Boolean - also so wie bisher. Jetzt macht du noch einen Cluster mit lauter Booleans, die genau die Namen tragen, denen das entsprechende Bit entspricht. Der Name ist also mit dem (bisherigen) Anzeigeelement-Name und mit dem Queuenamen identisch. Das Array of Boolean wandelst du jetzt (dafür gibt es ein entsprechendes Element, beachte: Clustergröße im Eigenschaftsmenü auf 32 stellen) in einen Cluster um. Jetzt hast du 32 Bits kompakt, wo du früher 32 Bit jedes einzeln gehabt hast.
Das mit der Datenweiterleitung machst du wie folgt: Vor der While-Schleife erstellst du einen Melder, in der While-Schleife schreibst du den Cluster in den Melder, nach der While-Schleife löscht du den Melder wieder. Da du die Queue sowieso auf ein Element beschränkt hast, wird das letzte sowieso überschrieben - dafür reicht aber auch ein Melder.
Diese ganze Sache kannst su zwei Mal machen.
Frage:
Funktioniert die Weitergabe der Daten überhaupt? Spricht: kommen die Bits am verbraucher überhaupt an? Ich behaupte, so wie du das gemacht hast, kommen am Verbraucher meistens keine Daten an.
Jeder, der zur wahren Erkenntnis hindurchdringen will, muss den Berg Schwierigkeit alleine erklimmen (Helen Keller).
Mal eine Grundregel, die nicht nur für LabVIEW gültig ist:
Referenzen auf Objekte, die man öfter/länger benötigt, öffnet man einmal vor Beginn des eigentlichen Programmablauf und schließt sie einmal nach Beendigung desselben!
Und das Öffnen einer Queue bedeutet nun mal das Erstellen einer Referenz... Also: Queues anlegen außerhalb/vor der While-Loop und Schließen nach der Loop! Dann sollte sich das Problem mit der CPU-Auslastung schon fast erledigt haben...
Dann noch das BD aufräumen, Bits wie schon beschrieben zusammenfassen, dein FP wieder herstellen (auch bei mir sind diese ganzen Booleans nicht sichtbar - das führt über kurz oder lang zu "Insane FP objects"!). Dieses ganze Bit-Shuffle erinnert doch sehr an C-Code, den du 1zu1 umgesetzt hast...
Werde mich jetzt an die Arbeit machen und den Vorschlag von IchSelbst umsetzen.
Melde mich dann später.
P.s.
Die Weitergabe der Bits funktioniert, das Programm läuft wie es soll,
nur wenn ich einen Langzeitversuch laufen lasst (über Nacht) habe ich die Probleme mit der CPU.
Ich denke FP-Elemente sind verschütt gegangen als ich die Schleife in das VI kopiert habe welches ich euch hochgeladen habe.
In meinem orginalen Programm sind sie noch da:-)
MfG
Anzeige
20.05.2010, 08:27 (Dieser Beitrag wurde zuletzt bearbeitet: 20.05.2010 09:38 von jg.)
Guten Morgen,
habe endlich wieder Zeit für mein Projekt gefunden,
habe auch den Vorschlag von IchSelbst umgesetzt.
Sieht soweit ganz gut aus.
Jetzt habe ich folgendes Problem:
Ich habe immer zwei Schleifen, eine wo die Signale in ein Queues geschrieben werden
und eine wo die Signale ausgelesen und in die Ausgangskarte geschrieben werden.
Sobald ich aber die Schleife zum Einlesen deaktiviere funktioniert auch die Schleife zum Auslesen auch nicht mehr.
Ich verstehe nicht warum.
Vielleicht muss man ja mit den Queues anders umgehen.
Bin um jeden Tip dankbar
MfG
Christian
20.05.2010, 09:32 (Dieser Beitrag wurde zuletzt bearbeitet: 20.05.2010 09:47 von GerdW.)
hatten wir dir nicht schon einmal (oder gar mehrfach) gesagt, dass man Referenzen vor einer Schleife öffnet, in der Schleife benutzt und nach Beendigung einer Schleife wieder schließt??? (Zitat IchSelbst: "Vor der While-Schleife erstellst du einen Melder, in der While-Schleife schreibst du den Cluster in den Melder, nach der While-Schleife löscht du den Melder wieder.")
Jetzt gucke ich in dein VI und sehe in jeder Schleife "Queue anlegen, Wert lesen/schreiben, Queue schließen". Und das in jeder Iteration jeder Schleife?
Also klare Antwort: Ja, mit Queues muss man anders umgehen...
Edit:
- Welchen Zweck haben die OR-Funktionen in der einen Schleife? x OR x = x... (Sowas nennt man Rube-Goldberg...)
- Wieso verwendest du zum Lesen der Queue ein "Preview Queue Element"? Meinst du nicht auch, das man eine Queue auch mal wieder leeren sollte, d.h. Elemente nicht nur "previewen", sondern auch richtig "dequeuen"??? (S. o.: man sollte mit Queues anders umgehen...)
Edit2:
Im LabVIEW-Examplefinder findest du unter dem Stichwort "Queues" ein "Queues Basic.vi" - das zeigt dir genau das, nämlich die Basics der Queue-Verwendung!
habe jetzt die Queues in Melder gewandelt, und auch die Struktur.
ich hoff diesmal ist nicht so viel Mist dabei.
Die ODER Funktion war nur zum testen.
Mit den Queues bzw Meldern schicke ich die Signale in die Sequenzstruktur (36 Schritte), welche den Antrieb steuert.
Ich komme dieses Jahr noch auf´n LabVIEW-Kurs, dann wird sich hoffendlich mein Grundwissen von LabVIEW verbessern.
MfG
LV Version 9
20.05.2010, 17:38 (Dieser Beitrag wurde zuletzt bearbeitet: 20.05.2010 17:41 von GerdW.)
Noch'n paar Tipps:
- Wenn du deine Clusterdefinition "Eingang Slot 4" so gemacht hättest, wie die Signale angeschlossen sind, könntest du dir das (fehlerträchtige) Umsortieren der Bits ersparen... (Kann man einfach per "Reorder Cluster Elements" erreichen!)
- wenn sich alles in einem VI abspielt, reicht es aus den Notifier einmal anzulegen und die "Referenz" an beide Schleifen zu verdrahten. Dann reicht es natürlich auch aus, den Notifier nur einmal zu löschen...
- Jetzt noch einen weiteren Notifier anlegen, mit dem du einen (einzigen) Stopp-Button an alle Schleifen weitermeldest. Wird sonst unübersichtlich, wenn man mehrere "Stopps" quittieren muss, bevor ein Programm beendet wird...
P.S.: "in die Sequenzstruktur (36 Schritte)" - Was soll das denn bitte heißen? Du hast da eine Sequenz mit 36 Frames??? Womöglich noch stacked, um BD-Platz zu sparen??? Schon mal was von State-Machine gehört?
