Lückenhafte Signaldarstellung

' schrieb:Das ist doch nicht nur kein Fehler, sondern sogar ein besonders schlaues Feature von LabVIEW: Wenn eine Schleife zu schnell ist für das, was alles pro Durchlauf zu erledigen wäre, dann entscheidet sich LabVIEW dafür, das, was am Unwichtigsten ist erst mal hintenanzustellen: Das genaue Ausmalen der Graphik. Sowie mal ein Pause kommt, wird das dann nachgeholt. Es ist kein permanenter Fehler!

Wie war das mit der Hose?

Anzeige

' schrieb:Das ist doch nicht nur kein Fehler, sondern sogar ein besonders schlaues Feature von LabVIEW: Wenn eine Schleife zu schnell ist für das, was alles pro Durchlauf zu erledigen wäre, dann entscheidet sich LabVIEW dafür, das, was am Unwichtigsten ist erst mal hintenanzustellen: Das genaue Ausmalen der Graphik. Sowie mal ein Pause kommt, wird das dann nachgeholt. Es ist kein permanenter Fehler!

1. "Wenn ein Schleife zu schnell ist..." -> Das Verhalten wurde mit einem VI nachgestellt, das nichts weiter enthält als das Darstellen einer Zahl. Mit einer Taktrate von 100ms.
2. Der Fehler tritt nicht auf, sobald man die Plotlegende 'rausnimmt. (so ein besonders schlaues Feature)
3. "Sobald eine Pause kommt..."?? -> Wenn man z.B. ein kleines Windows Fenster anfasst und es über das lückenhafte Diagramm 'drüberwischt, ist der Graph in Ordnung. (ist das nicht eine zusätzliche graphische "Belastung")
4. Nochmal : NI hat den Fehler bestätigt. CAR Nummer folgt.


Jetzt Du !

' schrieb:Jetzt Du ! [/font]

Ich will mich da nicht streiten. Wenn es schon bei so niedrigen Updatraten auftritt, und wenn es unabhängig von der Geschwindigkeit der verwendeten Graphikkarte auftritt, dann wird es schon ein Fehler sein, auch wenn man einigermaßen damit leben kann.

Was das mit der Fehlerbestätigung und "CAR-Nummer" bei NI auf sich hat, davon habe ich keine Ahnung, deshalb hatte ich dem Argument keine Beachtung geschenkt. Ist das eine Anerkennung des Fehlers oder nur die Zusage, dem gemeldeten Effekt nachzugehen? Und was ist die CAR Nummer?

kuckst Du :

http://wiki.lavag.org/CAR_Number

Svente

' schrieb:1. "Wenn ein Schleife zu schnell ist..." -> Das Verhalten wurde mit einem VI nachgestellt, das nichts weiter enthält als das Darstellen einer Zahl. Mit einer Taktrate von 100ms.
2. Der Fehler tritt nicht auf, sobald man die Plotlegende 'rausnimmt. (so ein besonders schlaues Feature)
3. "Sobald eine Pause kommt..."?? -> Wenn man z.B. ein kleines Windows Fenster anfasst und es über das lückenhafte Diagramm 'drüberwischt, ist der Graph in Ordnung. (ist das nicht eine zusätzliche graphische "Belastung")
4. Nochmal : NI hat den Fehler bestätigt. CAR Nummer folgt.
Jetzt Du !

Eine Bestätigung des Fehlers sagt grundsätzlich nichts. Da wird nähmlich nicht gesagt, ja das ist ein Fehler und wir werden es morgen fixen. Ein CAR besagt nichts anderes als dass da jemand ein wenig Zeit reingesteckt hat um es zu reproduzieren und der Effekt grundsätzlich als nicht nur der Fantasie eines überarbeiteten Programmiers entsprungen akzeptiert wurde und glaube mir ich habe im technischen Support gearbeitet und da kommen manchmal Bug Reports rein von sogenannten "professionelen" Programmieren wo man sich fragt ob so jemand überhaupt weiss wo bei einer Maus vorne und hinten ist.

Was danach mit dem CAR geschieht kann sehr verschieden sein.

[Ironie]

1) Ein Developer findet es Wert um etwas Zeit zu investieren und kann mit 99%-er Sicherheit garantieren dass es keine unschönen Nebeneffekte in anderen Teilen von LabVIEW gibt und der Fehler ist in der nächsten Version behoben.

2) Ein Developer untersucht es und kommt zum Schluss dass es etwas ist das behoben werden sollte hat aber keine Zeit und/oder kann nicht ausschliessen dass dies an anderen Orten in LabVIEW komische oder gar schlechte Einflüsse haben könnte. -> Der Bug wird als offen klassiert und in eine laaaaaaaaaaaaaaange Liste von anderen Bugs gesetzt die von Zeit zu Zeit von jemandem mit etwas freiere Zeit (gibts bei Programmieren grundsätzlich nicht also macht es ein Produktmanager) durchsucht wird und nach Prioritäten sortiert wird. Optische Fehler haben dabei nicht gerade gute Karten um in die Top 10 zu kommen.

3) Ein Developer findet das einen von der Hardware und/oder Mondfase, Laune des Programmieres etc. abhängiges Problem. Im besten Fall wird es dann deferred (auf die lange Bank geschoben) oder aber gleich als NMP (not my problem) abgeschlossen.

4) Ein Developer findet das ein Feature (zum Beispiel CPU Belastung sparen) und es wird als NAB (Not a Bug) abgeschlossen.
[/Ironie]

Ist das schlimm? Mag für Dich so aussehen da dieser Bug für Deine Applikation das Killerargument ist. Im Grossen und Ganzen werden aber eher wenige Leute damit Probleme haben, da man halt nicht Elemente übereinander legen sollte.

Rolf Kalbermatter

' schrieb:...
wo man sich fragt ob so jemand überhaupt weiss wo bei einer Maus vorne und hinten ist.
...

Ich merk mir das immer mit dem Schwanz der Maus. Kabellos ist deswegen bei mir tabu!

' schrieb:Ich merk mir das immer mit dem Schwanz der Maus. Kabellos ist deswegen bei mir tabu!

Auf Dich war diese Bemerkung garantiert nicht gemünzt.

Rolf

' schrieb:

Auf Dich war diese Bemerkung garantiert nicht gemünzt.

Rolf

Hatte das auch nicht auf mich bezogen, war nur der erste Gedanke der mir durch den Kopf ging beim lesen!

LG,
Torsten

Hallo Rolf,

vielen Dank für den Einblick.

Grundsätzlich ist es für mich auch weniger ein BUG als vielmehr eine Sache, an die man sich halten sollte. Ich für meinen Teil beachte das jetzt mehr und habe auch schon in allen laufenden Applikationen die Diagramme entsprechend modifiziert.
(das mit der Plotlegende habe ich aus diversen LV Beispielen und habe mir da nix weiter bei gedacht - Platz auf dem FP braucht man ja öfter mal...)
NI sagt mir halt das wäre ein Fehler...... okay....


Wollte das nur aus dem Grund publik machen, falls mal jemand ein ähnliches Verhalten bemerkt und sich keinen Rat weiß.

Gruß Svente