Problem(e) mit Kurvengraphen

[GerdW]

Hallo Maik,

LabView kompiliert schon. Nur hast du trotzdem deine Bibliotheken mit diversen Funktionen (Stichwort: Hardwarezugriff, Design der Benutzeroberfäche!, etc). Und die stecken nun mal in der runtimelib. Wie bei C auch: dort rufst du diverse Funktionen (Betriebssystemzugriffe, etc.) ja auch aus anderen libraries auf, ob die nun runtimelib heißen oder *.dll. In einem VI steckt außerdem noch mehr als das reine Kompilat, da ist immer noch die Beschreibung von Userpanel und Blockdiagramm, Debug-Code, die Einräge in den VI-Properties etc. drin. Und den Debugcode kannst du rausnehmen (Vi-properties->execution->allow debugging). Geschwindigkeit ist nur teilweise ein Kriterium, bei "guter" 🙂 Programmierung ist auch Labview sehr schnell, z.B. bei Verzicht auf ständige Speicherallokationen (Development guide, Chapter 6: Stichwort arrays, Schleifen, Autoindexing).

Und die Lösung deines Problems läßt sich mit einem XY-Graph anstelle eines Waveform-Chart sicher einfach bewerkstelligen. Wie ich oben schon sagte: bei einem Graphen kann man die Werte an der X-Achse vorgeben. Ein Chart stellt nur Y-Werte dar, ein Graph kann XY-Paare darstellen. Also x- und y-Werte zu Paaren zusammenfügen und zum XY-Graphen leiten. Wie die Werte anzuschließen sind, steht in der Kontexthilfe zum XY-Graph.

MfG
GerdW

[Jochen]

Hallo Maik,

kurzer Kommentar zu "Compiler oder nicht Compiler":
Auch VC und VB benutzen eine RunTime (z. B. die Datei msvcrt.dll = Microsoft Visual C RunTime, VB benötigt eine ganze Armada an OCXen usw. auf dem Zielsystem). Die kommt nur freundlicherweise bei MS gleich mit dem Betriebssystem und fällt daher nicht auf. Die RunTimes sowohl von VC und LV enthalten Komponenten, die zur Ausführung von Programmen, die mit dem jeweiligen Compiler erstellt wurden, auf den Zielsystemen benötigt werden.

Natürlich könnte man diese Komponenten auch direkt in die Exe kompilieren nur wäre das wohl eine ziemliche Platzverschwendung.

Die Menü- und Werkzeugleisten, die bei einer gestoppten und nicht geschlossenen LV-EXE angezeigt werden, sind natürlich Teil der LV Run-Time. Der Rückschluss, dass LabVIEW deshalb kein echter Compiler sei ist aber definitiv falsch.

Dass LV evtl. in manchen Benchmarks hinter VC oder VB zurückfällt mag durchaus sein. Komfort und Intuitivität benötigen natürlich einen gewissen Overhead und vergrößern damit den Code und ggfs. die Laufzeit. Solange aber die benötigte Performance erreicht wird und die Aufgabe mit existierender PC-Hardware gelöst werden kann, ist diese Diskussion vielleicht akademisch interessant, letztendlich aber nicht relevant.

Mit freundlichen Grüßen,

Jochen Klier
National Instruments Germany

[MaSta]

Hallo Gerd,

danke für die Erklärungen. Mir ist das klar, mach das schon ein paar Jahre. ;O)
Nur mit LabView hab ich erst im Januar angefangen und optimiere die VIs meines Kollegen, wenn ich Zeit habe.
Das mit der Echtzeitanzeige hab ich gelöst. Wird halt die Systemzeit ausgelesen und festgehalten und dann ständig von der aktuellen subtrahiert und als HH:MM:SS dargestellt unter dem Graph. Siehe Attachment.
Alles andere funktioniert schlicht und einfach nicht so, wie man es erwartet. Und man muß sich bei LV ja ordentlich verbiegen um sowas zu lösen. Die einfachsten Dinge sind damit manchmal unheimlich kompliziert.

Aber wenn ich noch mehr Phänomene entdecke, dann melde ich mich wieder hier.

Gruß,
Maik

[MaSta]

---

@Jochen wrote:
Dass LV evtl. in manchen Benchmarks hinter VC oder VB zurückfällt mag durchaus sein. Komfort und Intuitivität benötigen natürlich einen gewissen Overhead und vergrößern damit den Code und ggfs. die Laufzeit. Solange aber die benötigte Performance erreicht wird und die Aufgabe mit existierender PC-Hardware gelöst werden kann, ist diese Diskussion vielleicht akademisch interessant, letztendlich aber nicht relevant

Für mich schon, sonst würde ich sie nicht anfangen. Daß für euch die Performance eurer Kunden deren Problem ist,
hab ich schon bemerkt. Man kriegt bei Hinweisen auf bestimmte Mängel oder Ungereimtheiten oft eine lakonische Antwort deren Kontext heißt "RTFM" oder "was können wir dafür, wenn ihr keine Ahnung von LV habt". Klar, wenn man wie ihr jeden Tag damit zu tun hat, kennt man die Schwächen ganz genau.

Die Software, die mein Kollege als Teil unseres Hardwareentwicklungsprojektes geschrieben hat, hat eine lausige Performance. Gut, er wußte nicht (ich auch nicht, bin noch Anfänger mit LV), daß man Schleifen takten sollte.
Nachdem er das getan hatte änderte dies aber nichts daran, daß das Programm nach wie vor 100% CPU-Kapazität verbraucht, egal auf welchem Rechner. Und es werden keine rechenintensiven Schleifen ausgeführt. Es werden nur kontinuierlich Befehle an eine externe Hardware über USB sendet und deren Antworten verarbeitet. Also nichts, was groß Leistung braucht.

Naja, egal. Eine andere Anwendung, die wir gegenwärtig entwickeln, läuft (weil viel Programmieraufwand) noch wesentlich schlechter. Viel optimieren kann man da nicht mehr. Müssen wir wohl doch auf VB oder VC umsteigen.

Trotzdem danke für eure Hilfebemühungen! 🙂