Hallo Jens,
danke erstmal für deine ausführliche Antwort. Da sind schon mal einige Sachen für mich verständlicher.
' schrieb:Erster Kritikpunkt: Mach die Labels bei den Terminals im BD sichtbar, das erhöht die Lesbarkeit des Codes. Das Label eines Controls ist ja sozusagen der Variablenname, und ein sinnvoller und "selbsterklärender" Variablennamen ist immer gut. Wenn dieses Label dann nicht als Beschriftung im FP taugt, dann kann man ja immer noch im FP auf die "Caption" eines Controls zurückgreifen.
Hatte ich anfangs und hab auch überlegt das zu lassen, hab die Labels dann aber zugunsten des Platzes rausgesschmissen. Für Nachfolger ist es aber sicher besser, da hast du recht. Ist geändert.
Zitat:Dann: Zur vollständigen Analyse fehlt die Info, wie du dein Task "Messung" genau konfiguriert hast. Am besten hier mal LV-Code erstellen und noch mal hochladen.
Ich habe im MAX zunbächst vier virtuelle Kanäle erstellt und diese dann in einen Task gepackt. Hab jetzt im VI mal den Code generiert (siehe unten), wodurch allerdings die Vorgabe von einem Bildschirm fürs BD nicht mehr erfüllt ist.
Zitat:Eine Schleife läuft in LV immer so schnell, wie es der Code innerhalb der Schleife zulässt. Wenn dort also nichts zur "Zeitverzögerung" drin ist, wird schnell 100% CPU Belegung erzeugt. Eingaben sind dann kaum noch möglich.
Deswegen packt man gerne solche Wait-VI's in Schleifen ein. Das sind übrigens dann Software-Taktungen, man sollte sich da nicht allzu genau auf das Timing verlassen.
Ich hab jetzt ein bisschen nachgedacht und mit dem Timing rumgespielt und es glaub ich mittlerweile besser verstanden. Auch dann den Zusammenhang mit der Abtastrate und den aus diesen beiden Größen letzlich resultierenden Datenmengen
Zitat:Zum Thema kontinuierliche Datenerfassung mit Hardware-Taktung habe ich übrigens kürzlich erst hier so einige Beispiele hochgeladen:
http://www.LabVIEWforum.de/index.php?showtopic=8099&hl=. Schau dir das mal an.
Die Beispiele die du an anderer Stelle hochgeladen hast, habe ich mir schon angeschaut (ich weiß gar nicht wieviele Stunden ich schon in diesem Forum gelesen habe...), nur sehe ich nicht genau den Vorteil in meinem Fall. Außerdem habe ich nicht ganz verstanden wie du den Graph-Cluster aufbaust. Vielleicht könntest du das kurz erklären. Ansonten denke ich, dass meine Schleife nicht lange genug läuft um den Buffer zu füllen, zumindest ergibt das die Rechnung und ich hatte auch schon lange keine solche Fehlermeldung mehr. Ganz am Anfang hab ich das nicht geblickt mit dem buffer, aber mittlerweile geht es hoffentlich einigermaßen.
Zitat:Zum Punkt Aufsplitten der Messwaveform, das hast du etwas umständlich gemacht. Einfacher so:
Du hast beim Aufteilen des Arrays nur eine 0 als Index verwendet. Ich habe doch theoretisch 4 Signalverläufe, die ich aufsplitten muss, d.h. jeder müsste einen einzelnen Index haben oder? Diesen Teil habe ich im VI auch noch überarbeitet. Die GRaphen bzw. Diagramm der Temperatur laufen jetzt langsamer. Dazu habe ich "dezimieren" benutzt. Das müsste doch im Prinzip dann so sein, wie wenn ich weniger oft messen würde, weil nur ein Teil der Messwerte benutzt werden oder versteh ich das falsch? Ich habe es in meinem VI mal in dem von dir dargestellten Sinne geändert und die Indizes so angepasst wie ich denke.
Dazu direkt wieder eine Verständnis Frage:
Wie werden solche Mess-Arrays aufgebaut? Als Zeilen- oder Spaltenmatrix? Also wenn ich einen Kanal habe mit einem Signalverlauf, kommt dann eine Zeile raus oder eine Spalte?
Zitat:Kommt darauf an. Was man z.B. machen könnte und was wahrscheinlich auch keine schlechte Idee wäre, ist eine parallele Schleife, in der du per Event-Struktur auf das Betätigen deiner verschieden Buttons reagierst. Hier könntest du die Eigenschaftsknoten von Punkt 4 deiner Frage dann reinstecken, dann werden diese Sachen nicht bei jedem Schleifendurchlauf gesetzt.
Ja, an sowas in der ARt hatte ich auch schon nachgedacht, weil ich es nicht so doll finde, wenn die immer aufgerufen werden.
Zitat:Auch das mit der Auswahl des Speicherfiles läuft aus meiner Sicht noch nicht so, wie du es willst. In jedem Schleifendurchlauf wird ja immer wieder der Datenpfad auf deinen Default-Pfad gesetzt (Timeout-Case der Event-Struktur). Und die Case-Struktur um den File-Dialog kannst du dir sparen, denn der File-Dialog wird wegen der Event-Structure nur dann aufgerufen, wenn du den Pfad-wählen Button drückst.
Das habe ich mittlerweile selbst schon behoben. Es läuft jetzt so wie ich mir das vorstelle, d.h. bei jedem neuen Aufnehmen von Daten wird ein neues File generiert. vorher wars bei jedem SChleifen Durchlauf, da hast du recht.
die Case Struktur in der Event Struktur habe ich mit einem bestimmten Grund gemacht bzw. mangels genauem Verständnis der Ereignis-Strukturen. Und zwar hatte ich so etwas in der Hilfe gelesen, dass der Button, auf den sich die WErtänderung bezieht immer verbunden sein sollte. Zumindest habe ich das so verstanden. Daher die Case Struktur, um wuasi den Status von "Speichern" abzufragen. Kann natürlich sein, dass ich das einfach komplett falsch verstanden habe. Ansonsten ist die Case-Struktur natürlich quatsch. Daher also die Frage:
Müssen die Schalter o.ä. auf die sich die Events beziehen, an irgendwas angeschlossen sein oder kann ich die einfach ohne irgendwas anderes reinpacken? Das würde einiges vereinfachen.
Zitat:Ob dein AO-Task mit einem unterschiedlichem Timing zum AI-Task laufen soll, das musst du selber wissen.
Das macht nichts. ich brauch nur eine konstante Spannung während der Messung und das müsste gegeben sein oder?
In meinem jetztigen VI sind einige Buttons enthalten die noch keine Funktion haben(unten im BD), bitte die nicht so beachten. Damit will ich die Tischsteuerung dann basteln, sobald der da ist. Hab das nur reingepackt, damit ich das FP soweit fertig gestaltet habe.
Ich hab die LV Version in meinem Profil geschrieben und oben in meinem Thread nochmal. Aber hast recht, der Einfachheit halber ist es direkt beim VI wesentlich sinnvoller. WErd mich dran halten.
Viele GRüße
Wolfgang
LV Version 8.5
Messoberfl_che.vi (Größe: 353,17 KB / Downloads: 217)
