Problem(e) mit Kurvengraphen

[MaSta]

Hallo!

Wir haben mit der grafischen Darstellung von Signalverläufen in unserer Software Probleme. Die an der X-Achse angezeigte Zeit läuft viel zu schnell ab.
Daher habe ich das angefügte VI einmal zum Testen des einzelnen Graphen erstellt.
Nun treten hier noch mehr Probleme auf:

a) die Zeit läuft auch hier zu schnell ab. Die Einstellung ist auf "relative Zeit" und die Minuten werden in etwa so schnell hochgezählt wie Sekunden
(während ich diese Mail schreibe, läuft das VI im Hintergrund und die Zeitanzeige ist, nachdem ich mal kurz auf das Fenster des VIs gewechselt habe, auf
15 Stunden nochwas gesprungen, die drei Graphen werden nur noch sehr langsam aktiviert und sobald sie den rechten Rand erreichen springt die
Zeitanzeige der X-Achse auf 17 Stunden - das wird z.B. auch gemacht, wenn man die Farbe einen Graphen zur Laufzeit ändert)
b) die Änderung des Aktualisierungsmodus zur Laufzeit wird nicht übernommen, auch nicht, wenn man "Diagramm löschen" nimmt oder das VI neu startet
(das scheint in Abhängigkeit von bestimmten Einstellungen zu stehen, aber welche? Denn manchmal wird die Änderung sofort übernommen)
c) "Neuinitialisierung auf Standardwert" funktioniert anscheinend überhaupt nicht
d) bei Neustart des VIs werden die Achsenbeschriftungen nicht zurückgesetzt, nur wenn man das VI neu lädt
e) wenn die X-Achse auf Zeitanzeige (relative Zeit) eingestellt ist und man die automatische Skalierung nicht nutzen will, wie soll man den Maximalwert
festlegen? In Sekunden? Es werden in den Einstellungen in dem dortigen Feld nur Integerzahlen akzeptiert.
f) Wieviele Werte sollte man maximal einstellen, die für den Graph gespeichert werden? In welchem Abstand werden die Werte aktualisiert? Finde dazu nirgends
eine Info.
g) warum funktionieren Zoom, Bereichsauswahl usw. während der Aktualisierung des Graphen nicht richtig, denn sie werden sofort zurückgesetzt?

Wäre nett, wenn Sie uns da helfen könnten. Wir möchten unsere Software gern fertigstellen.

[MaSta]

English version:

Hello!

We experienced some problems when using plot diagrams (or how they're called in the english version of LV). The time on the x-axis runs too fast. So I've made a stand-alone test with one of those plots and some more problems occured (see attachment at first post in thread):
a) the time display runs too fast here, too
(it is set to relative time HH:MM:SS and the minutes are counted like seconds, sometimes the time makes a big "jump" when you switch over to another application and back to the window of the plot again)
b) the display mode (german: Aktualisierungsmodus) is sometimes not applied, even if the plot has reached a full scale. Not even if I chose "reset to default value" or "clear diagram" (Diagramm loeschen).
c) you can set "automatic scale" for the x-axis or manual scale. But what is the maximum value for a time display when using manual scale and, since you can enter only integers, what are these integers related to? Milliseconds? The HELP does not tell.
d) Zoom, Selection and all the features of the three buttons of the plot legend don't work at runtime. What are they good for, if I can only use them while the graph isn't receiving input values?

Hope, someone of NI can help without us paying for it. These are, as I assume, errors or bugs of LabView itself.
But NI has decided to only provide payed support. So I have to post the problem here.

[GerdW]

Hallo Maik,

zu a)
Die Skalenwerte der X-Achse werden als relative Zeit angezeigt. Das hat nichts mit der aktuell ablaufenden Zeit zu tun... Es wird einfach der Skalenwert in eine Zeit umgerechnet. Da deine Schleife sehr schnell abläuft, werden auch sehr schnell Werte generiert/angezeigt. Damit wird der Skalenwert an der X-achse auch schnell hochgezählt... Ich hatte eben mal bis 0:56:06 laufen lassen, was einer Wert von 3366 entspricht, wenn du die Anzeige wieder auf floatingpoint-Format zurückstellst (korrekt: 3366s sind 56.1min sind 0h56min06s...). Lasse also deine Schleife im Sekundenabstand laufen und sie zeigt die richtige Zeit an. Oder verwende einen Graphen anstelle des Charts. Dann kannst du die Werte an der X-Achse vorgeben. Ein Chart zählt an der X-Achse nur einen Index hoch.

zu b)
Der Aktualisierungsmode lässt sich nur "effektiv" umschalten, wenn du autoscale-x ausschaltest. Macht auch nur dann Sinn.

zu f)
Du meinst die Historie? Das bleibt dir überlassen. Guck dir mal den dritten Aktualisierungsmode an.

zu g)
Auch hier greift die Autoskalierung sofort zu...

MfG
Gerd

P.S.: If you would use English language more people could help you.

[MaSta]

@Gerd:

Danke, das erklärt alles.
Aber daß die relative Zeit vom Schleifendurchlauf abhängig ist steht nirgends, oder? Denn somit ist diese Art der Anzeige ja sinnlos. Und die absolute Zeit läuft auch nicht besser. Ich müßte also einen Zeitstring vom System nehmen, ihn formatieren und über den Graphenhintergrund legen, damit ich eine echte Zeitanzeige bekomme. Na super!
Genauso logisch wie so vieles bei LV...

Zum Englisch: I have done so. ;O)

Hatte nur die originale Mail hier rein kopiert, die ich an NI geschickt hatte, nur um dann zu erfahren, daß man keinen Support bekommt, wenn man nicht für blecht. Als wenn man das nicht mit der Anschaffung der LabView-Lizenz mitbezahlt hätte....

Message Edited by Maik S. on 03-24-2005 03:40 AM

Message Edited by Maik S. on 03-24-2005 03:40 AM

[GerdW]

Hallo Maik,

für Fragen wie deine wurde dieses Forum geschaffen. Da muss man nicht bezahlen und erhält trotzdem gute Antworten von langjährigen Labviewnutzern oder auch NI-Mitarbeitern.
Außerdem sollte dir klar sein das NI auf eine Anfrage wie "Wäre nett, wenn Sie uns da helfen könnten. Wir möchten unsere Software gern fertigstellen." kaum kostenlosen Support geben kann. Dafür gibt es Firmen/Ingenieurbüros, die sowas als Dienstleistung anbieten. Und NI bietet ja auch Labview-Kurse an...

MfG
GerdW

[MaSta]

Hmmm, das kann man so oder so sehen.
Ich bin der Meinung, daß ich für ein so teures Produkt (weiß gar nicht, was eine Lizenz kostet, aber billig wird sie nicht sein) auch mal (wir fragen selten an) Support erwarten kann.
Klar, das Forum tut es auch und ich habe ja meine Antwort.
Danke nochmal!

Aber daß man extra einen Kurs besuchen soll um mit LabView arbeiten zu können, wo es doch einfach und intuitiv ist, sehe ich nicht ein. Manche Sachen sind halt einfach unlogisch. Wie z.B. daß man Schleifen takten muß, da sie sonst die ganze Rechnerkapazität fressen. Das tut eine main() Funktion im C-Programm auch nicht. Oder eine do()-while()-Schleife, deren Analogon die while-Schleife in LV ja ist.
Ein netter NI Ingenieur meinte zu mir mal, das stünde in den LabView Basics. Aber wo und welche meinte er? Im LabView Paket sind dicke Bücher, da steht nix von takten.

[GerdW]

Hallo Maik,

ich habe zwar mit C(++) (sehr) wenig Erfahrungen, aber in allen Programmiersprachen die ich vor Labview benutzte liefen Schleifen immer so schnell wie möglich. Bei Labview ist das genauso. Wenn ich in anderen Programmiersprachen eine Schleife takten will, muss ich eine Wartefunktion einbauen. In Labview geht das genauso. Und ich habe noch eine Auswahl verschiedener Wartefunktion, um auf bestimmte Anforderungen reagieren zu können...

Und ja, das steht im Manual. Ist eine der Grundregeln. LabView Development Guide, Chapter 6, Block diagram style, die ersten beiden Seiten.

MfG
GerdW

[MaSta]

Du hast mich vielleicht falsch verstanden.
In LV will ich auch, daß eine Schleife so schnell wie möglich läuft, denn LV ist schon lahm genug, weil die VIs nicht compiliert werden. Aber wenn ich sie nicht takte, dann nimmt diese Schleife sich 100% Rechnerkapazität, egal auf welchem Rechner. Damit lahmt das ganze System. Das ist für mich ein Fehler, ein Bug. Das habe ich vor einiger Zeit an NI geschrieben und eben zu lesen bekommen, daß man sie takten muß/soll.
Gut, wenn ich das mache, dann verbraucht auch eine leere Schleife fast keine CPU-Kapazität, aber sie wird dadurch langsamer. Und somit meine ganze Software, denn man hat nicht nur eine Schleife.

[GerdW]

Hallo Maik,

VI's werden kompiliert. Immer. Ständig. LabView ist kein Interpreter (wie BASIC).

Programmiere eine Schleife in einer anderen Programmiersprache, lasse sie laufen und sie nimmt 100% Prozessorkapazität. War bisher immer so. Wird immer so sein. Egal ob BASIC, Assembler, C, Pascal oder Labview. (Gilt für reine Berechnungen, bei Hardware-Zugriffen sind oft schon Wartefunktionen enthalten).
Es sei denn, ich (der Programmierer) sorge für das Gegenteil. Neben der Taktung gibt es bei Labview auch noch die Möglichkeit des Multithreadings, der Prioritätseinstellung (vi-properties->execution) und des preferred execution systems (ebenda).
Und bei Windows kann man über den Taskmanager auch noch mal eine Priorität vergeben. LabView läuft mit "Normal Priority" und nimmt damit allen Prozessen, die gleiche oder geringere Priorität haben, Prozessorkapazität weg. Liegt aber wohl nicht an Labview, sondern an Windows. Es gibt TaskManager, die für eine bessere Lastverteilung sorgen...

MfG
GerdW

[MaSta]

Hallo Gerd!

Ich glaube dir das, fast jedenfalls. Du hast sicherlich länger damit zu tun,
Aber ich komme von der VB und C Ecke her und da heißt kompilieren in Maschinencode überstzen und wenn LV das täte,
dann bräuchte es keine Runtime und wäre schneller.
Und wenn ein kompiliertes Programm mal stopt durch einen Fehler würde nicht die Menüleiste des Debugmodus kommen.
Also macht LV trotz der Klassenanbindung und Nähe zu C
kein richtiges Kompilieren, so wie Visual Basic.

Naja, auf jeden Fall wird es fummelig, an der X-Achse eine Echtzeitanzeige anzubringen, denn takten auf 1 Sekunde kann ja nicht die Lösung sein.

Gruß,
Maik