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 habe ja gesagt, wenn dus nicht so gemeint hast dann sollst du es bitte vergessen. ein smilie (auch wenns nur ein smilie ist) sagt oft schon sehr viel aus, wie es jemand gemeint hat. diesen :grrr:interpretierte ich vorher eher als negativ und das kann mir glaub ich niemand übel nehmen.
brauchst dich jetzt auch nicht zu rechtfertigen, denn jetzt weiß ich wie du's gemeint hast und es ist nun in ordnung
in zeiten wie diesen, muss man ja schon 3 x überlegen wer einen "dissen" möchte und wer nicht
das mit den html tags wär glaub ich gar nicht sooo eine schlechte idee
' schrieb:Also ich find deinen Humor ganz gut Lucki.
Ich bin mir auch fast sicher, dass ich ihn meistens bemerke
Danke, Kvasir, aber von Dir hätte ich mir auch nichts Anderes vorstellen können. Weiß zwar nicht, ob die LVF -Rubrik "Meine Freunde" außer den reinen Einträgen noch eine darüber hinaus gehende Funktionalität hat, aber ich habe Dich jetzt mal einfach bei mir eingetragen und hoffe, daß Du dich nicht als Testobjekt mißbraucht fühlst...
' schrieb:Ich hänge mich jetzt nicht in die Diskussion rein, sondern sage nur etwas zum Stichwort "Analog Output mit Schieberegler steuern". Wenn Du das willst, dann natürlich keine kontinuierliche Ausgabe, sondern bei jeder Wertänderung am Schieberegler eine neue Einzelwert-Ausgabe.
jut, das ist natürlich die simpelste Lösung und es ist auch gar nix schlecht dran (nicht dass mir wieder jemand nachsagt, ich würd hier nur rumkritisieren ...). Etwas komplizierter, aber dafür mit Dämpung geht es so: AO Rampe
' schrieb:Edit: Sehe gerade: man hat die Hierarchie im LVF ausgebaut. Da hast Du aber Glück gehabt, daß ich das nicht vorher gesehen habe, denn wie käme ich sonst als "LVF-Freak" dazu, mit Dir als "LVF-Grünschnabel" überhaupt zu reden?
... und ...
' schrieb:Ich nehme Dir das nicht übel. denn leider habe schon jeher das Problem, daß mein Humor außerhalb meines engen Freundeskreises oft nicht als solcher wahrgenommen wird.
ach nu hab dich nich so, dafür sind die noobs doch da <SCNR - G,D&R>*- also sogar ICH hab das sofort als Scheaz verstanden
PS: SCNR = Sorry, could not resist
PPS: G,D & R = GRINSEN, Ducken & Rennen
@i2dx
Dein VI Rampe ist ja ganz toll, Wertänderung mit begrenzter Slewing-Rate.
Ich habe zwar auch schon viel mit AO gemacht, aber bei der kontinuierlicher Ausgabe handelte es sich dabei immer um periodische Verläufe. Zu diesem VI bewegt mich ein Frage: Wie synchronisiert sich die Schleife? Oder anders gefragt: Die Puffergröße von DAQmx Write beträgt 200 Samples. Wie regelt sich die Schleifengeschwindigkeit, so daß der DAQ-Buffer weder mit Daten zugemüllt noch ganz leer wird? Ich vermute, daß das DAQmx in der Schleife, wenn dort neue Daten eingegeben werden, nicht sofort danach den Task- und den Fehler-Ausgang bedient, sondern damit so lange wartet, bis der Buffer wieder aufnahmefähig ist. Ist das so?
Und damit es nicht heißt, ich lobe nur und meckere nicht genügend, hier der Beitrag: Die Trauerränder um die Leitungsbezeichnungen würde ich wegfallen lassen:
' schrieb:Zu diesem VI bewegt mich ein Frage: Wie synchronisiert sich die Schleife? Oder anders gefragt: Die Puffergröße von DAQmx Write beträgt 200 Samples. Wie regelt sich die Schleifengeschwindigkeit, so daß der DAQ-Buffer weder mit Daten zugemüllt noch ganz leer wird? Ich vermute, daß das DAQmx in der Schleife, wenn dort neue Daten eingegeben werden, nicht sofort danach den Task- und den Fehler-Ausgang bedient, sondern damit so lange wartet, bis der Buffer wieder aufnahmefähig ist. Ist das so?
wie es GENAU funtioniert kann ich dir auch nicht sagen. DAQmx Write.vi ruft ja eine DLL auf. Ich vermute mal, dass die DLL entweder den Puffer pollt oder irgendn einen ausgefuchsten Timing-Mechanismus hat. Die Schleifendurchlaufzeit entspricht auf jeden Fall genau der Zeit, die die analoge Ausgabe benötigt um die die in den Puffer geschriebenen Daten bei der eingestellten Sample-Rate auszugeben.
Das funktioniert erst seit DAQmx 8.irgendwas (??) und ich bin über diesen Umstand sehr begeistert. Gerade bei trad. DAQ war das ja eines der schwierigsten Probleme überhaupt eine vernünftige Synchronisierung zu programmieren. Nun kann man hardware-getimetes AO programmieren, und das ist schon ne feine Sache.
Die Hilfe zu dem Thema gibt sich übrigens etwas nebulös: If the task uses on-demand timing, this VI returns only after the device generates all samples. On-demand is the default timing type if you do not use the DAQmx Timing VI. If the task uses any timing type other than on-demand, this VI returns immediately and does not wait for the device to generate all samples. Your application must determine if the task is done to ensure that the device generated all samples.
ich benutze aber das Timing VI, und da steht in der Hilfe: - nichts zu diesenm Thema -
interessant, gell? ich hab das durch try & error rausgefunden, im Speziellen hatte ich eine synchronisierte AI / AO Schleife, mit Hardware-Timing durch das AI. Irgendwann hatte ich das AI mal rausgenommen und mich dann gewundert, warum der AO Puffer nicht vollläuft ...
Farben der / Ränder um die Labels? hm ... egal, hauptsach die Drähte sind gerade
@i2dx
Danke erst mal für die ausführliche Information. Ich werde Dein VI nochmal genau unter die Lupe nehmen und melde mich dann noch mal. Was mich stutzig macht ist, dass die CPU-Belastung, währen das VI ausgeführt wird, 100% beträgt. Wahrscheinlich enthält das DAQmx Write ein eingebautes Polling für die Abfrage das Puffer-Füllstandes und hält sich daran fest, bis der Buffer leer ist. Und da das Polling vielleicht in einer Schleife ohne Wait läuft, kommt es zu dieser hohen CPU-Belastung. Habe mal kurz versucht, das mit dem Eigenschaftsknoten DAQmx Write/Wartemodus zu ändern, aber wenn man das macht, kommt die Fehlermeldung, das das nicht geht, weil es sich hier um eine "ungepufferte Ausgabe" handelt (???).
Edit: Kleines Zwischenergebnis. Es scheint sich wirklich um eine ungepufferte Ausgabe zu handeln, warum weiß ich aber auch nicht zu sagen. Da pro Schjleifendurchlauf 100 Samples erzeugt werden und die Rate 1kHz beträgt, müßte die Schleifen-Durchlaufzeit eigentlich 100ms betragen. Ist sie aber nicht, es ist nur 1ms. Weiß nicht, was das AO Write in dieser 1ms mit den 100 Samples macht, ob es nur den ersten oder letzten Wert nimmt. Der Waveform-Graf gibt natürlich alle Werst brav aus und ist überhaupt nicht repräsentativ für das was am Ausgang von Write herauskommt. Hat denn das VI schon einen Praxistest bestanden, will sagen, wurde der AO-Ausgang schon benutzt?
Mit der Einfügung eines echten Buffers funktioniert es hingegen so wie erwartet, Was ich aber überhaupt nicht verstehe, denn im VI Abtasttakt gibt ja im Modus "continuous" der Eingang "Anzahl Samples" die Buffergröße vor - also müßte ja auch ein Buffer existieren.
Hier die Zeitmessung an Deinem VI:
Und hier die Änderung von mir. Die Rampe ist natürlich 1oo mal langsamer, aber vielleicht entspricht sie gerade damit den Berechnungen.
01.02.2007, 19:34 (Dieser Beitrag wurde zuletzt bearbeitet: 01.02.2007 19:34 von Lucki.)
Habe mich mal in den Hilfe-Beispielen von LabVIEW umgeschaut, so läuft es jetzt besser. Das Entscheidende ist das Verbot der Buffer-Regeneration. Ich glaube mich zu entsinnen, dass es bei den traditionellen DAQs anders herum war, da war das Regenerations-Verbot Standard. Die Regeneration sondern musste extra aktiviert werden. Da tappt man eben bei DAQmx erst mal unweigerlich in der Falle.
Ludwig
' schrieb:@i2dx
Danke erst mal für die ausführliche Information. Ich werde Dein VI nochmal genau unter die Lupe nehmen und melde mich dann noch mal. Was mich stutzig macht ist, dass die CPU-Belastung, währen das VI ausgeführt wird, 100% beträgt.
sorry, dass ich mich erst jetzt dazu äußere, ich war auf Geschäftsreise und konnte mich nicht drum kümmern ...
die 100% Systemlast wundern mich etwas, ich hab's auf einem PXI getestet, da läuft es so wie von mir beschrieben. Ich hab leider grad keine PCI-M-Serie da, aber ich werde das ggf. nochmal nachprüfen.
Zum Thema Puffer, der beim Modul "timing" festgelegt wird: DAQmx bestimmt selbst, wie groß der Puffer ist. Auszug aus der Hilfe:
Output Tasks For generations, the amount of data you write before starting a generation determines the size of the buffer. The first call to a Multiple Samples version of the Write function/VI creates a buffer and determines its size.
You also can use the Output Buffer Config function/VI to create an output buffer. If you use this function/VI, you must use it before writing any data.
The samples per channel attribute/property on the Timing function/VI does not determine the buffer size for output. Instead it is the total number of samples to generate. If n is your buffer size, setting samples per channel to 3×n generates the data in the buffer exactly three times. To generate the data exactly once, set samples per channel to n.
NI-DAQmx does not create a buffer when the sample mode on the Timing function/VI is set to hardware-timed single point.
Soweit ich mein VI nun selbst verstehe mache ich folgendes: Da ich den Task starte ohne vorher einen Puffer zu füllen, wird kein Puffer erstellt. Wenn ich das Array "reinschreibe" muss der Treiber also jedes Array Element einzeln abklappern weil kein Puffer da ist, wo der ganze Block gespeichert werden könnte und dadurch entsteht das gefühlte Hardware-Timing ...
