Wenn dein Problem oder deine Frage geklärt worden ist, markiere den Beitrag als "Lösung",
indem du auf den "Lösung" Button rechts unter dem entsprechenden Beitrag klickst. Vielen Dank!
ich muss während der Messungen die anfallenden Daten auf einem Diagramm ausgeben. Auf der x-Achse soll die Zeit in Sekunden angegeben werden. Außerdem soll man möglichst den kompletten Versuchsverlauf auf einen Blick sehen. Die Diagramm-Breite soll optimal ausgenutzt werden. Die Messwerte werden ohne die Erzeugung von Zeitdaten an das Diagramm weiter gereicht.
Vor der Messung in einer While-Schleife werden folgende Werte festgelegt:
- Abtastrate [Hz]
- Messdauer [s]
Ich habe einen Eigenschaftsknoten zum Diagramm erzeugt und belege folgende Werte vor der Messung:
- XAchse.RingStart = 0
- XAchse.Minimum = 0
- XAchse.Maximum = Messdauer [s]
- XAchse.FeinInk = Messdauer [s] / 100
- XAchse.Faktor = 1 / Abtastrate [Hz] = delta t [s]
So weit, so gut. Funktioniert eigentlich auch ganz prima, wenn ich die Messdauer verändere. Variiere ich jedoch die Abtastrate, sieht das Diagramm erst im zweiten Durchlauf so aus wie gewünscht. Die Ausnutzung der Diagramm-Breite funktioniert nicht sondern behält die Soll-Breite des Vorgänger-Versuchs bei. Klingt irgendwie nach einem Wert, den ich versehentlich nicht voreingestellt habe und der sich automatisch anpasst. Kann mir jemand weiterhelfen?
Ach ja, momentan arbeiten wir hier noch mit Version 7.1.
Offensichtlich läuft es auf ein Signalverlaufsdiagramm hinaus, wobei Du das Diagramm während der Messung bei jedem neuen Wert updatest. Ansonsten schließe ich mich dem Statement von Achim an, daß hier noch zu viele Frage offen sind, um qualifiziert darauf zu antworten. Z.B:[list]
[*]Sind die Messungen äquidistant oder braucht jeder Wert seinen eigenen Zeitstempel?<>
[*]Wenn die Rate geändert wird, soll dann die Darstellung im gleichen Diagramm weiterlaufen oder ist das mit Diagramm-Neustart verbunden?<>
[*]In welcher Größenordnung bewegt sich denn die Rate und welcher Zeitrahmen soll denn abgebildet werden?<>
[st]Wenn Du das VI hochlädtst, dann möglichst in lauffähiger Form. Also abspecken und z.B. die Messwerterfassung durch den Zufallszahlen-Generator ersetzten.
' schrieb:Offensichtlich läuft es auf ein Signalverlaufsdiagramm hinaus, wobei Du das Diagramm während der Messung bei jedem neuen Wert updatest. Ansonsten schließe ich mich dem Statement von Achim an, daß hier noch zu viele Frage offen sind, um qualifiziert darauf zu antworten. Z.B:[list]
[*]Sind die Messungen äquidistant oder braucht jeder Wert seinen eigenen Zeitstempel?<>
[*]Wenn die Rate geändert wird, soll dann die Darstellung im gleichen Diagramm weiterlaufen oder ist das mit Diagramm-Neustart verbunden?<>
[*]In welcher Größenordnung bewegt sich denn die Rate und welcher Zeitrahmen soll denn abgebildet werden?<>
[st]Wenn Du das VI hochlädtst, dann möglichst in lauffähiger Form. Also abspecken und z.B. die Messwerterfassung durch den Zufallszahlen-Generator ersetzten.
Hi Lucki,
sorry, ich bin jetzt zu Hause und leider nicht in der Lage, ein VI hochzuladen, da ich hier kein LabVIEW installiert habe. Vielleicht kann ich trotzdem deine Fragen beantworten und jemand hat einen Geistesblitz. Da ich Montag Morgen um 7 Uhr wieder vor dem Schaltbild brüten werde, wäre ich für jeden wochenendlichen Hinweis dankbar.
Also:
1. Ja klar, die Werte sind äquidistant, sonst hätte ich mir ein entsprechendes Feld erzeugt. Zur Zeit taste ich einen einzigen Kanal ab. Was ich sehen will, ist ein Bild auf einem Diagramm von 0 bis x Sekunden, wobei x die Messdauer ist, und die Breite des Diagramms optimal genutzt wird, also die Kurve nicht mehr gestaucht wird als notwendig. Ich könnte natürlich auch hinter der While-Schleife einen Graphen platzieren, aber unsere Ingenieure benötigen eine optische Überwachung der Versuche zur Laufzeit.
2. Nein, bei jedem Neustart wird das Diagramm gelöscht. Das habe ich in den VI-Eigenschaften eingetragen.
3. Das ist die Crux. Die Versuche fallen sehr unterschiedlich aus. von 1 bis 400 KHz und von 1 bis 140 Sekunden ist so ziemlich alles vertreten.
Wissenwert ist vielleicht noch, dass die Messwerte blockweise mit einstellbarer Blockgröße eingelesen werden. Wenn man mal von der Behandlung der speziellen Messkarte (DAP 840) absieht, ist es eigentlich ein ganz normales Diagramm: Vor der While-Schleife erfolgen die Initialisierungen der Karte, des Diagramms usw., dann folgt die While-Schleife, die blockweise Daten einliest und an das Diagramm übergibt, bis die gewünschte Anzahl Messwerte eingelesen wurde. dahinter werden dann die Messwerte gespeichert (zu diesem Zweck erzeuge ich dann passende Zeitwerte) und die Pipes der Messkarte wieder geschlossen. Dass die Reihenfolge der Abarbeitung ok ist, habe ich mit dem Debugger verifiziert.
Komisch, ich dachte, ich hätte ein Allerweltsproblem, und alle sagen sofort: Natürlich, du hast das und das vergessen. Ist wohl doch nicht so. Aber mir fehlt halt noch die LabVIEW-Erfahrung, sorry.
Bärbel
31.08.2007, 19:35 (Dieser Beitrag wurde zuletzt bearbeitet: 31.08.2007 19:36 von jg.)
ich glaube, ich kann dein Problem nachvollziehen und hab auch 2 Lösungen für dich.
Kleines Vorwort erstmal: Die Properties RingStart und FeinInkrement kannst du dir eigentlich sparen.
Jetzt zu deinem VI: Gehe auf Grund deiner Beschreibung davon aus, dass dein Programm im Prinzip folgendermaßen aussieht:
Bei diesem Aufbau kann ich das von dir beschriebene Problem (also bei Änderung Frequenz haut es nicht hin) auch bei mir nachvollziehen.
So, jetzt zu den Lösungen. Hintergrund hierzu: Innerhalb einer Property-Node werden die verschiedenen Properties von oben nach unten abgearbeitet. Ich hab jetzt einfach mal die Property Multiplier an den Anfang gestellt. Funktioniert. Wieso, da bin ich mir auch nicht ganz sicher. s. Screenshot:
2. Lösung, die auf jeden Fall immer funktioniert, sieht so aus:
Dann noch zum Schluss ein Hinweis: Der in meinen Bsp. dargestellte dauernde Update des Graphen ist natürlich Gift für die Prozessorauslastung. Hierzu gab es mal einen guten Thread, wie man das reduzieren kann, denn im Prinzip langt es, einige Male pro Sekunde den Graphen neu zu zeichnen. Also, schau mal hier: http://www.LabVIEWforum.de/index.php?showtopic=4260
MfG, Jens
Wer die erhabene Weisheit der Mathematik tadelt, nährt sich von Verwirrung. (Leonardo da Vinci)
!! BITTE !! stellt mir keine Fragen über PM, dafür ist das Forum da - andere haben vielleicht auch Interesse an der Antwort!
ich glaube, ich kann dein Problem nachvollziehen und hab auch 2 Lösungen für dich.
Kleines Vorwort erstmal: Die Properties RingStart und FeinInkrement kannst du dir eigentlich sparen.
Hallelujah, da sitzt doch tatsächlich noch jemand freitags abends am Rechner! Danke erst einmal!
Bei RingStart habe ich mir fast gedacht, dass das niemand wirklich benötigt, aber ohne die Einstellung von FeinInkrement werden die Gitter (ja, die Ing's wollen unbedingt grüne Gitter im Diagramm) manchmal seeeehr eng nebeneinander gezeichnet.
' schrieb:Jetzt zu deinem VI: Gehe auf Grund deiner Beschreibung davon aus, dass dein Programm im Prinzip folgendermaßen aussieht:
(Image01.png)
Bei diesem Aufbau kann ich das von dir beschriebene Problem (also bei Änderung Frequenz haut es nicht hin) auch bei mir nachvollziehen.
So, jetzt zu den Lösungen. Hintergrund hierzu: Innerhalb einer Property-Node werden die verschiedenen Properties von oben nach unten abgearbeitet. Ich hab jetzt einfach mal die Property Multiplier an den Anfang gestellt. Funktioniert. Wieso, da bin ich mir auch nicht ganz sicher. s. Screenshot:
(Image02.png)
2. Lösung, die auf jeden Fall immer funktioniert, sieht so aus:
(Image03.png)
Interessante Information! Habe ich bestimmt überlesen. Meine Kenntnisse stammen aus den beiden Büchern
- LabVIEW. Das Grundlagenbuch (von Rahman Jamal und Andre Hagestedt)
- LabVIEW Graphical Programming (von Gary W. Johnson und Richard Jennings)
Bis ich die Dinge, die ich benötige, nicht mehr stundenlang suchen muss, wird vermutlich noch einige (Programmier-)Zeit ins Land gehen. Toll, wenn man jemanden (oder gleich viele erfahrene Forumsmitglieder) fragen kann. Auf die Abarbeitungsreihenfolge bei Property-Nodes wäre ich vermutlich nie gekommen.
' schrieb:Dann noch zum Schluss ein Hinweis: Der in meinen Bsp. dargestellte dauernde Update des Graphen ist natürlich Gift für die Prozessorauslastung. Hierzu gab es mal einen guten Thread, wie man das reduzieren kann, denn im Prinzip langt es, einige Male pro Sekunde den Graphen neu zu zeichnen. Also, schau mal hier: http://www.LabVIEWforum.de/index.php?showtopic=4260
MfG, Jens
Ja, danke für den Hinweis. Die Prozessorlast ist nicht soooo kritisch, da hier nix geregelt werden soll, auch nicht manuell. Wenn die Werte nicht zeitgenau angezeigt werden sondern etwas hinterher hinken, ist das nicht so schlimm. Es muss nur verfolgt werden können, ob der Prozess einigermaßen in den erwarteten Messwertgrenzen verläuft. Sonst wird der Versuch abgebrochen. Damit der Stop-Schalter auch registriert wird, habe ich eine kurze Wartezeit in die While-Schleife eingebaut. Die Messwerte (prozessorlastfrei mit der DAQ-Karte eingelesen) werden blockweise in einen vorher angelegten "temporären" Puffer kopiert, von dort ans Diagramm geschickt und an die richtige Stelle eines vorher angelegten Zielpuffers gepatcht. Klingt umständlich, ist es vermutlich auch, aber irgendwo habe ich einen Absatz über Speichermanagment gelesen, der so etwas in der Art vorschlug, damit nicht in jedem Schleifendurchlauf Speicher angefordert werden muss. Allerdings muss ich zugeben, dass ich mit der Speicherverwaltung noch nicht so ganz warm geworden bin.
Bis hierhin jedenfalls erst einmal herzlichen Dank, ich werde im Laufe des Montags vom Ergebnis berichten.
' schrieb:Bei RingStart habe ich mir fast gedacht, dass das niemand wirklich benötigt, [...]
Die Löschung bzw. das Nichtsetzen dieser Eigenschaft hat wirklich nichts verändert.
' schrieb:Bis hierhin jedenfalls erst einmal herzlichen Dank, ich werde im Laufe des Montags vom Ergebnis berichten.
Yep, das war's! Ich habe den "Multiplier" nach oben gezogen (d.h. bei mir heißt das "Faktor"), und schon lief alles wie gewünscht. Natürlich nur im Rahmen der Historienlänge. Für die Monstermessungen von 2 Minuten mit über 100 kHz muss ich die Diagramm-Auflösung noch etwas herunter schrauben. Das bekomme ich aber vermutlich selber hin.
Vielen, vielen Dank, vor allem an Jens, aber auch an alle anderen, die sich gemeldet haben,
Bärbel
03.09.2007, 14:22 (Dieser Beitrag wurde zuletzt bearbeitet: 22.12.2007 22:12 von jg.)
Schön, wenn Du es geschafft hast. Inzwischen ist mir etwas eingefallen und ich kann Dir auch diese Frage präzise beantworten:
Zitat:Variiere ich jedoch die Abtastrate, sieht das Diagramm erst im zweiten Durchlauf so aus wie gewünscht. Die Ausnutzung der Diagramm-Breite funktioniert nicht sondern behält die Soll-Breite des Vorgänger-Versuchs bei. Klingt irgendwie nach einem Wert, den ich versehentlich nicht voreingestellt habe und der sich automatisch anpasst. Kann mir jemand weiterhelfen?
Damit habe ich mich auch zu Zeiten von LV7.1 massiv herumgeärgert und habe alles versucht, ohne Erfolg. Es muß sich um einen Bug handeln. Mein persönliches Work-arround war, den Eigenschaftsknoten, wenn er so funktionierte, einfach zweimal hintereinander aufzurufen. Das funktionierte dann in jedem Falle.
Mit dem VI will ich auch zeigen, daß man die Aufgabe auch durchaus mit einem Signalverlaufsdiagramm statt -graphen lösen kann. Man brauch dann überhaupt keinen Puffer mehr, da dieser im Digramm eingebaut ist und kann außerdem Stapelpots verwenden. (Der Puffer in meinem VI simuliert nur die blockweise Datenerfassung und fällt in der Realität weg)
(VI LV 7.1)
' schrieb:@Lucki:
Du brauchst den Knoten nicht 2x aufrufen, s. mein Post weiter oben.
Entschuldige , Jens, daß ich das übersehen habe. Und Du hast recht, einfache Änderung der Reihenfolge löst das Problem:
Ich wußte auch nicht, daß das Problem bei > V7 immer noch besteht. Vielleicht ist es kein Bug, sondern hat einen ganz plausiblen Grund.
Ich verwende auch lieber die 2. Methode mit Clustern. Dieses Format passt aber nicht zum hier von mir verwendeten Signalverlaufsdiagramm, und mit Waveforms loszulegen war mir zu umständlich.
