LabVIEWForum.de - an laufendem VI arbeiten

LabVIEWForum.de

Normale Version: an laufendem VI arbeiten
Du siehst gerade eine vereinfachte Darstellung unserer Inhalte. Normale Ansicht mit richtiger Formatierung.
Hallo,

ist es möglich an einem laufenden VI zu arbeiten? So könnte ich Messungen machen und nebenher ein paar Schönheitskorrekturen vornehmen. (Ich weiß, ich könnte das VI umbennenen und daran arbeiten. Das ist mir aber bei über 30 SubVIs zu stressig).

Gruß

Philipp
Nein!

LabVIEW arbeitet nicht wie z.B. VisualBasic im "Interpreter-Betrieb", wenn man das Programm in der Entwicklungsumgebung startet, sondern erstellt beim Drücken des Startknopfes schon kompilierten Code (= Maschinencode). Den kannst du aber nicht zur Laufzeit ändern...


Gruß
Achim
' schrieb:Hallo,

ist es möglich an einem laufenden VI zu arbeiten? So könnte ich Messungen machen und nebenher ein paar Schönheitskorrekturen vornehmen. (Ich weiß, ich könnte das VI umbennenen und daran arbeiten. Das ist mir aber bei über 30 SubVIs zu stressig).

Gruß

Philipp


Hi.

Nein, eine derartige Möglichkeit kenne ich nicht. Ich frage mich aber auch, wie das rein technisch gehen sollte!? Ein Programm, was sich in Ausführung befindet verändern zu wollen...

Normalerweise wird z.B. ein C Programm vor dessen Ausführung kompiliert und in Maschinenbefehle übersetzt, sodass die eigentliche Syntax nicht mehr betroffen ist. Innerhalb der Entwicklungsumgebung aber z.B. beim Debuggen werden Rückschlüsse auf den Sourcecode gezogen und es bleiben Abhängigkeiten bestehen. Bei LabVIEW dürfte das auch der Fall sein. Mich würden aber noch andere Meinungen dazu interessieren...

Ich sehe nur die Möglichkeit, dass du dein Projekt einmal kompilierst, um es nebenher laufen lassen zu können. Dir ein Backup von deinen VI's sicherst und deine VI's in der Entwicklungsumgebung verschönerst bzw. wartest.

Schöne Grüße,
Stefan
schade...

Danke.

Philipp
' schrieb:Ich frage mich aber auch, wie das rein technisch gehen sollte!? Ein Programm, was sich in Ausführung befindet verändern zu wollen...

In VB geht das so: Du machst einen Breakpoint in den Code an der Stelle, die du bearbeiten willst. Sobald die Ausführung hier hängen bleibt - das Programm also "temporär" steht - kannst du den Code bearbeiten und auch den "Ausführungspunkt" (die Stelle, wo das Programm weitermachen soll) vom Breakpoint nach vorne (nochmal...) oder hinten (etwas auslassen...) verschieben. Das ist so ne Art aktiver Debug-Modus *grins*

Gruß
Achim
Also in Delphi geht das. Die EXE läuft in der IDE unter dem Debugger. Währenddessen kann man den Source ändern.

Für Schönheitsoperationen ist das allemal geeignet. Das Problem ist dann natütlich der Debugger. Möglicherweise - aber eben nur möglicherweise - findet der dann manchen Sourcecode nicht mehr.

Ich hab mich auch schon des öfteren darüber geärgert, dass man in LV den Source nicht ändern kann, wenn die Applikation läuft. Soll die IDE den Debugger halt abschalten, wenn ich den Source ändern will.
Aber du kannst eine EXE erzeugen, starten und nebenbei an deinem VI arbeiten. So wie in anderen Programmiersprachen und IDEs.

Gruß, eg
' schrieb:Also in Delphi geht das. Die EXE läuft in der IDE unter dem Debugger. Währenddessen kann man den Source ändern.

Für Schönheitsoperationen ist das allemal geeignet. Das Problem ist dann natütlich der Debugger. Möglicherweise - aber eben nur möglicherweise - findet der dann manchen Sourcecode nicht mehr.

Ich hab mich auch schon des öfteren darüber geärgert, dass man in LV den Source nicht ändern kann, wenn die Applikation läuft. Soll die IDE den Debugger halt abschalten, wenn ich den Source ändern will.

Auch Visual C kennt das im Debugger Mode. Im Prinzip wird der ganze Code neu kompiliert und gelinkt und der Debugger versucht dann wieder dort einzusteigen wo er war.

Erstens ist das eine wirklich saugrosse Arbeit um das gut zu tun und ich denke mal dass es etwa 200 andere LabVIEW Features gibt die mir allemal wichtiger sind.

Und zweitens geht das auch bei Visual C regelmässig ein wenig falsch. Oder die Stackvariablen kommen ein bischen durcheinander, oder andere Abhängigkeiten sind plötzlich nicht mehr korrekt, oder die Veränderung benötigt ganz einfach umfangreiche Anpassungen in Variablenwerten und dergleichen um sinnvoll arbeiten zu können.

Alles in allem nicht unbedingt ein Feature wo ich NI gerne unzählige Mannmonate darin investieren sehe.

Rolf Kalbermatter
Gestern war wieder so ein Fall, da hätte ich gern eine Änderung bei laufender EXE gemacht: Text (im String-Anzeigeelement) ändern. Da sieht man plötzlich, dass ein Hinweistext missverständlich ist und möchte den gerne ändern. Geht aber leider nicht. Und bis der Prüfablauf einmal um ist und das Programm beendet werden kann, hab ich wieder vergessen, dass ich "nur" einen Text ändern wollte.Sad
' schrieb:Gestern war wieder so ein Fall, da hätte ich gern eine Änderung bei laufender EXE gemacht: Text (im String-Anzeigeelement) ändern. Da sieht man plötzlich, dass ein Hinweistext missverständlich ist und möchte den gerne ändern. Geht aber leider nicht. Und bis der Prüfablauf einmal um ist und das Programm beendet werden kann, hab ich wieder vergessen, dass ich "nur" einen Text ändern wollte.Sad

Also so etwas ist halt einfach etwas Management. Beim Testen habe ich immer ein Blatt Papier danaben wo alles was ich so sehe an solchen Dingen fein säuberlich aufgeschrieben wird. Ansonsten weiss ich nämlich sicher dass ich nach dem nächsten Rebuild und Start plötzlich denke "Oh shit, das wollte ich auch noch anpassen".

Was ich wichtiger finde ist die Möglichkeit um während der Ausführung einen Wert in einem Wire anzupassen. Wenn man beispielsweise eine Motion Application macht, hat man typischerweise eine ziemlich langwierige Aufstartphase des Systems (Homing, Grundstellung, eventuel eine ganze Leiste von Bewegungen bis man endlich am interessanten Punkt ist). Dann ist man am Debuggen und sieht dass ein Wert falsch ist und muss eine kitzekleine Änderung am Diagram machen und alles neu starten.

Wenn man jetzt den Wert im Wire doch noch auf einen gültigen Wert setzen kann dann kann man zumindest noch einen Schritt weiter debuggen, bis zum nächsten Fehler. Es gab da mal eine Diskussion um dieses Feature eine extra Möglichkeit von Conditional Probes zu machen aber ich glaube nicht das da schon mehr passiert ist.

Rolf Kalbermatter
Referenz-URLs