Automatisches Wechseln vom Blockdiagramm zum Frontpanel

Ich kämpfe seit einiger Zeit damit, dass nach der Arbeit im Blockdiagramm nach gewisser Zeit nach dem Bearbeiten von Verbindungen, LV sich einfach in das Frontpanel umschaltet. Bis es sich dann zum Schluss sobald ich mich wieder ins Blockdiagramm schalte gleich wieder ins Frontpanel umschaltet. Dann heißt es nur noch speichern, warten bis das Programm wieder reagiert (nach 3 min), beenden, LV neu starten.
Und abgesehen davon dauert es mittlerweile schon ca. 15 s bis eine Verbindung zwischen zwei Knoten hergestellt wird.

Ich verwende LV2013 (32-bit) mit Win7 (64-bit) und einem i5 mit 2x 3,2Ghz und 12Gb Arbeitsspeicher.

Es ist halt schon sehr lähmend wenn man programmieren möchte und das läuft alles wie auf einer alten Gurke.

Hat jemand ähnliche Probleme?

Anzeige

Hallo klausinger,

kannst du mal dein VI hier anhängen?

Idee/"educated guess":
Langsames Editieren kann mit großen Datenmengen im VI zusammenhängen (Arraykonstanten, Charts/Graphs mit als Default hinterlegten Plots, Bilder etc.). Bei einer Änderung läuft der Compiler im Hintergrund und brauchst dann seine Zeit...

Ja das Vi ist schon recht Groß, ich kann es auch dazugeben es wird nur nicht recht viel bringen wegen meiner Verwendeten Hardware. Aber es geht ja nur um die Programmierung und nicht ums Ausführen, das funktioniert noch einigermaßen.
Ich verarbeite immerhin 32 Analogkanäle welche skaliert, berechnet, konditioniert und angezeigt werden müssen. Das ist noch nicht alles, da fehlen noch einige Funktionen.
Ach ja und so einige SubVIs laufen auch noch mit.

Ich hoffe es ist alles dabei, ansonsten kurz melden.

Hallo klausinger,

ich gucke es mir vllt. heute abend an, habe gerade kein LV2013 zur Verfügung. Oder du hängst es in LV2011 an…

Zitat:Ich verarbeite immerhin 32 Analogkanäle welche skaliert, berechnet, konditioniert und angezeigt werden müssen.

Ohne in dein VI zu schauen: das sind alles Operationen, die mit einem Array (und nicht etwa 32 Arrays) ausgeführt werden…

(04.02.2014 13:23 )GerdW schrieb:  Ohne in dein VI zu schauen: das sind alles Operationen, die mit einem Array (und nicht etwa 32 Arrays) ausgeführt werden…

Nein, alles 32x parallel programmiert.
Gruß, Jens

Naja, wie soll ich den es anders machen als parallel programmieren? Ich bin gerne offen für Neues.
In welchen Kurs lernt man so etwas?
Bis jetzt habe ich nur die Kindergarten-Kurse gesehen, welche ein bis 2 Kanäle verarbeiten. Wie es auch in unzähligen Übungsskripten erklärt wird.
Ich brauche einfach soviel, weil sonst muss ich wieder ins DasyLab und das mag ich nicht besonders, also sollte es LV schon schaffen.
Also bitte nur her mit den Vorschlägen.

lg Klausinger

Hallo Klausinger,

alles, was mehrfach ausgeführt werden muss, sollte man mit Arrays und (autoindizierenden) FOR-Loops erledigen…

Also ich hab alles in While-Schleifen, weil es ja um eine kontinuierliche Messung geht, wobei man ja eh mit einer For-Schleife halt immer den Counter neu hochstellen könnte. Ja weil bei der For-Schleife glaubt der PC zu wissen wie viel Speicher er noch benötigt. Dh. ich könnte bei jedem Durchlauf sagen, dass sich der Counter nicht verändern soll, aber funktioniert dann die Indizierung noch korrekt? Ich werde da mal ein paar Versuch machen.

Normal verwende ich ja die dynamischen Daten aus dem DAQ-Assistent und wenn es nicht anders geht dann wird natürlich ein Signalverlaufs-Array erstellt, damit dieses synchron mit den dynamischen Daten läuft.

Aber ich habe ja derzeit noch weniger das Problem beim Ablaufen sondern beim Programmieren.

Hallo,

ich habe erst jetzt verstanden was mit autoindizierter For-Schleife gemeind ist. Derzeit wird die Archetektur umgearbeitet. Producer-Consumer für die Messdatenerfassung und die Verarbeitung und ein paar State-Machines für verschiedene Auswertemöglichkeiten. Jede Menge richtig programmierte SubVi's und somit wird der im Hintergrund laufende Code weniger. Jetzt macht es wieder richtig Spaß zu programmieren.

Danke für Eure Hinweise!

Schön zu hören und danke für die Rückmeldung.

Viel Spaß beim Programmieren!

Gruß, Jens