Zeitachse beim Signalverlaufs-Diagramm

Hallo Herby,

Zitat:nach ca. 1 Stunde Betrieb ... um ca. 65 min

Dann ist doch alles in Ordnung! 65min = ca. 1h

Anzeige

Okay Gerd,
hier habe ich mich nicht richtig ausgedrückt: während die Anzeige oben rechts die richtige aktuelle Uhrzeit anzeigt (z.B. 11:10 Uhr) , ist meine Achsenbeschriftung schon 65 min weiter, also bei 12:15 Uhr (obwohl beiden Zeiten beim Start des VIs gleich waren!!)
Das ist mein Problem !!

Herby

Hallo Herby,

- lass das ständige Neusetzen des Offsets weg
- zähle die wirklich geschriebenen Werte! Der Chart zeigt als Zeit an: Offset+(Anzahl Werte)*(Faktor)...

Hallo Herby,

probier doch mal das hier:
   
(Die PropertyNode bezieht sich natürlich auf den Chart...)

P.S.:
@Admin: Mea culpa, ich habe einen neuen Beitrag erstellt statt den alten zu editieren...

Hallo Gerd,
den ersten Punkt habe ich erledigt,
den zweiten verstehe ich nicht ganz:
ich zähl doch im VI selber eine U8 Variable hoch und gebe das aktuelle Zählergebnis sowohl auf eine Anzeige als auch auf das Signalverlaufsdiagramm.
Wenn also bis 10 gezählt worden ist, sind doch auch 10 Werte in das Diagramm eingespeist worden und die Achsberechnung müßte dann doch korrekt sein ??

Hallo Herby,

- du änderst dauernd (und unnötig) den Offset
- deine Zeitmessung kann inkorrekt sein - wer sagt dir, das nach x Iterationen wirklich genau x*Intervall Zeit vergangen ist? Meinst du wirklich, Windows arbeitet dermaßen akkurat?
- berechne selbst mal unter Zuhilfenahme des Schleifeniterators "i" und der obigen Formel den anzuzeigenden "Timestamp"

Zitat:Wenn also bis 10 gezählt worden ist, sind doch auch 10 Werte in das Diagramm eingespeist worden und die Achsberechnung müßte dann doch korrekt sein ??

Und wer garantiert, dass nach 10 Werten (bei einem Delay von 0.1s) wirklich und ganz genau 1.0s vergangen sind?

Anzeige

Hallo Gerd,
vielen Dank erst einmal für die Mühe, die Du Dir mit meinem Problem gibts.

Zunächst erst mal finde ich es generell seltsam, wie LV die Zeit berechnet.
Für solche Anwendungen, wie ich sie schreibe, reicht es doch völlig aus, wenn LV die ganz normale Uhrzeit vom Uhren-Chip aus dem PC nehmen würde und diese als Basis nimmt.
Gut, diese Uhr geht auch nicht ganz genau, aber dann würde das ganze Umrechnen und einstellen doch entfallen und man hätte eine vernünftige Zeitachse (oder gibt es so etwas unter LV und ich habe es nur noch nicht gefunden ?)

Weiterhin habe ich den Eindruck, daß LV mit kleinen Verzögerungszeiten (in meinem Fall <= 100 ms) nicht "so gut zurecht kommt".

Und letzendlich: da ich aus der Mikrocontroller-Welt kommen, bin ich eigentlich davon ausgegangen, wenn ich unter LV eine Zeitverzögerung von 100 ms einstelle, das das dann wirklich auch 100 ms (ev +- 1µs) sind.
Das sich u.U bestimmte Abweichungen aufsummieren ist klar, aber in dieser Höhe ?

Und dann natürlich die "kritischt Frage": wie schreibt man denn dann ein VI, das folgendes erfüllt:
- ich lese alle 500 ms einen Messwert über die serielle Schnittstelle ein (klappt schon)
- stelle die Messwerte in einem Diagramm mit x-Zeitachse dar
- und möcht dann z.B. wissen bzw. ablesen, wie groß der Meßwert um 12:03:10 Uhr war ??


PS: Deine letzte Lösung läuft jetzt bei mir ca. 8 min und ich habe bisher einen Zeitversatz von ca. 3 s, allerdings bei einer Wartezeit von 100 ms (wie gesagt: vielleicht liegen dort die Grenzen von LV. Ich werde das ganze jetzt noch einmal mit 1 s und mit 10 s Verzögerungzeit versuchen)

Vielen Dank,
Herby

Hallo Herby,

du kannst einen µC mit einem begrenzten Softwareumfang (bzw. RTOS) nicht mit Windows vergleichen. Du gibst in LV nur den Wunsch eines bestimmten Delays vor. Ob das OS diesen Wunsch korrekt umsetzt, ist nirgendwo garantiert... Außerdem summieren sich diese Fehler ja auf: wenn du jedesmal 99.9ms statt genau 100ms wartest, hast du nach 10 Iteration (=~1s) schon einen Versatz von 1ms. Und: du nimmst nirgends eine echte Zeitermittlung vor: der Chart berechnet nur die Zeitanzeige, Formel siehe oben. Merke: Windows ist kein RTOS! Außerdem sind die üblichen PC-Uhren alles andere als genau...

Zitat:Zunächst erst mal finde ich es generell seltsam, wie LV die Zeit berechnet.

Wieso? Du sagst dem Chart, er möge die X-Achse aus Offset+Counter*Faktor berechnen - und das Ergebnis bitte als Zeit formatiert darstellen. Genau das wird auch gemacht! Wenn du die Werte nicht mit einem zeitlichen Abstand, der dem Faktor entspricht, bereitstellst, kann das Ergenbis der Rechnung natürlich nicht korrekt sein...

Zitat:Und dann natürlich die "kritischt Frage": wie schreibt man denn dann ein VI, das folgendes erfüllt:
- ich lese alle 500 ms einen Messwert über die serielle Schnittstelle ein (klappt schon)
- stelle die Messwerte in einem Diagramm mit x-Zeitachse dar
- und möcht dann z.B. wissen bzw. ablesen, wie groß der Meßwert um 12:03:10 Uhr war ??

Dann musst du:
- die Zeit auch wirklich messen (GetDateTime ist bis WinVista (?) auf eine Auflösung von 15ms beschränkt...)
- die Zeitwerte mit speichern
- einen XY-Graph verwenden, dem du die Zeitwerte als X-Achse vorgibst

Hallo Gerd,
schönen Dank noch einmal für die Antworten.
Mit dem angehängten VI habe ich gerade 3 Meßreihen gemacht und folgendes festgestellt:

Wartezeit // Laufzeit des VIs // Zeitversatz ("X-Achse zeigt zu wenig an")
10 ms // 3 min // (schon) 8 s
100 ms // 15 min // 2 s
1000 ms // 1:00 Stunde // KEIN Versatz feststellbar
500 ms läuft gerade noch

Die Sache mit den "sich aufsummierenden Ungenauigkeiten" hatte ich zunächst auch vermutet, aber dann paßt das Ergebnis von 1 s-Wartezeit nicht in dieses Schema, denn hier ist nach einer Stunde keinerlei Abweichung feststellbar.
Ich nehme an, daß die Aufbereitung des Meßwertes im Daigramm ja auch Zeit benötigt, sicherlich im ms-Bereich (werde ich auch noch einmal nachmessen) und durch die parallele Verarbeitung im VI-Block kommt LV bei den kleinern Zeiten "etwas durcheinander".
Eine andere Erklärung fällt mir (mit meinem bescheidenen LV-Wissen) zur Zeit nicht ein.
Du kannst Dir ja vielleicht noch einmal mein VI ansehen, ob da etwas falsch ist.

Vielen Dank und viele Grüße
Herby

Hallo Herby,

Zitat:aber dann paßt das Ergebnis von 1 s-Wartezeit nicht in dieses Schema, denn hier ist nach einer Stunde keinerlei Abweichung feststellbar.

Passt doch wunderbar: je größer das Warteintervall, desto weniger können sich kleine Ungenauigkeiten aufsummieren... Bei ganz kurzen Wartezeiten (10ms) hast du dagegen ruckzuck Ungenauigkeiten im %-Bereich!

Wie schon mehrfach gesagt: das Problem liegt beim verwendeten OS...