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!
Mein Pessimismus ist völlig unabhängig vom USB-Standard. Schaut euch bitte das genannte Beispiel der zukünftig notwendigen Messbereichsgrenze an (weswegen ich überhaupt so eine schnelle Karte gekauft habe).
1MS/s je Kanal, 100ms messen. Das heißt, es müssen je Kanal 1MS/s * 100ms = 100kS übertragen werden. Da ich jedes mal nur 4000 Samples in den Puffer schreiben kann, größer ist er nun mal nicht, sind das 100000/4000 = 25 Schreibzyklen in den 100ms. Das heißt, es müssen alle 4ms die kompletten Arrays für beide Kanäle in der Software bereit gestellt und der Schreiben-Befehl aufgerufen werden - alles noch vor und unabhängig vom USB. Der, der das auf einer Windows-Maschine hinbekommt (erstmal ganz abgesehen von allen nebenbei laufenden Überwachungsroutinen) möge sich bitte melden. Allein schon 10ms werden für Schleifendurchläufe auf Nicht-RT-Systemen sportlich...
Und nebenbei ist das unabhängig von der Messzeit, die 100ms sind nur ein Beispiel. Entscheidend ist nur die Rate.
Von daher fehlt in dem Ferrari-Vergleich noch der Zusatz, dass der Fahrer medizinisch verordnet nur 25km/h fahren darf. Dann stimmt er wieder.
Wisst ihr, was ich meine? Nur weil die Karte so schnell ist, muss ich schnelles USB nicht zwangsläufig brauchen. An den 3€ oder von mir aus auch 20€ liegt es freilich nicht.
(14.12.2013 16:00 )monoceros84 schrieb: 1MS/s je Kanal, 100ms messen. Das heißt, es müssen je Kanal 1MS/s * 100ms = 100kS übertragen werden. Da ich jedes mal nur 4000 Samples in den Puffer schreiben kann, größer ist er nun mal nicht, sind das 100000/4000 = 25 Schreibzyklen in den 100ms. Das heißt, es müssen alle 4ms die kompletten Arrays für beide Kanäle in der Software bereit gestellt und der Schreiben-Befehl aufgerufen werden - alles noch vor und unabhängig vom USB. Der, der das auf einer Windows-Maschine hinbekommt (erstmal ganz abgesehen von allen nebenbei laufenden Überwachungsroutinen) möge sich bitte melden. Allein schon 10ms werden für Schleifendurchläufe auf Nicht-RT-Systemen sportlich...
Du mußt keineswegs in 25 Schreibzyklen jedesmal den Kartenpuffer voll schreiben. Der Datentransport zur Karte funktioniert ganz anders als Du es beschreibst, und zwar schneller und intelligenter. Windows-Interrups werden den Transport nicht stören, und die Größe des Kartenpuffers muss Dich überhaupt nicht interessieren.
Und zwar so: Es wird ein zweiter Puffer auf dem PC angelegt. Der kann recht groß sein, so dass Du z.B die Samples für den gesamten Zyklus mit einem Mal reinschreiben könntest. Der Datentransport zur Karte findet über DMA statt, die "windowsinterrupt-gefährdete" CPU hat damit nichts mehr zu tun. Beim Datentransport zur Karte findet ein Handshaking derart statt, dass der interne Kartenpuffer immer möglichst gefüllt bleibt. Dieses Handshaking, sowie die Konvertierung der parallelen Daten zu USB-Seriell, werden von untergeordneten, in "Echtzeit" arbeitenden Intelligenzen erledigt, die CPU hat damit ebenfalls nichts zu tun.
Fazit: Wenn Die USB-Schnittstelle den Datendurchsatz schafft, dann müsste es funktionieren. Bedenken, dass es an irgendwelchen zu langsamen Schleifendurchläufen im Programm scheitert, oder daß Window-Interrupts alles verderben, muss man nicht haben.
@Jens:
Zitat:Das Teil an einem USB 1.1 Ausgang zu betreiben ist wie mit einem Ferrari auf einer Schotterpiste zu fahren. Big Grin
Wenn es nach mir ginge: Es ist strafwürdig. Zwar sehe ich ich, soweit ich blicken kann, bei allen Benutzern "Verwarnungslevel = 0". Aber hier könnte man doch endlich mal ein ordentliches Exempel statuieren.
(16.12.2013 08:54 )Lucki schrieb: Fazit: Wenn Die USB-Schnittstelle den Datendurchsatz schafft, dann müsste es funktionieren. Bedenken, dass es an irgendwelchen zu langsamen Schleifendurchläufen im Programm scheitert, oder daß Window-Interrupts alles verderben, muss man nicht haben.
Oh, na das kommt unerwartet. Danke für die tiefgründige Erklärung! Dann probiere ich das mal, das wäre wahnsinnig toll. Würde mir auch an anderen Stellen das Leben erleichtern.
Nur jetzt die große Frage: was passiert, wenn der Port doch mal nicht hinterher kommt? Stockt die Ausgabe kurz oder hört sie mit einem Fehler auf? Und: wenn ich das einmal mit einer bestimmten Samplerate und Sequenzlänge teste und es funktioniert, kann ich drauf vertrauen, dass es auch zukünftig immer funktionieren wird (eben so sicher wie wenn ich erst alle Daten in den Kartenpuffer lade und dann starte)? Oder kann da doch ab und zu mal was dazwischen kommen?
Versteht bitte, dass ich ganz sicher gehen muss, bevor ich das im großen Stil probiere, um Schäden am Prüfstand zu vermeiden...
(16.12.2013 08:54 )Lucki schrieb: Wenn es nach mir ginge: Es ist strafwürdig. Zwar sehe ich ich, soweit ich blicken kann, bei allen Benutzern "Verwarnungslevel = 0". Aber hier könnte man doch endlich mal ein ordentliches Exempel statuieren.
Ich zeige Reue und gelobe Besserung. Bestellung für eine USB-Karte ist raus Mit der bisherigen Datenübertragungs-Methode hatte ich ja keinen Anlass, das zu tun. Und andere Methoden kamen mehr (oder wie ich jetzt gelernt habe, vielleicht auch weniger) gerechtfertigt nicht in Frage...
Ein wenig Off-Topic:
Hat du die Feature-Wünsche an deine DAQ-Karte schon mit einem versierten NI-Vertreter besprochen? Der bzw. NI muss dafür gerade stehen.
Wenn da wirklich so viel "Hardware-Geld" (sprich der Prüfstand, der nicht kaputt gehen darf) dahinter steckt, dann ist das nach dem, was ich bisher herauslese, eine Aufgabe für eine RT-System mit FPGA, und nicht mehr für eine DAQ-Karte (schon gar nicht USB).
Gruß, 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!
(16.12.2013 10:27 )jg schrieb: Hat du die Feature-Wünsche an deine DAQ-Karte schon mit einem versierten NI-Vertreter besprochen? Der bzw. NI muss dafür gerade stehen.
Ich habe leider noch keine Antwort erhalten. Angefragt ist es. Natürlich werde ich das Ergebnis hier mitteilen.
(16.12.2013 10:27 )jg schrieb: Wenn da wirklich so viel "Hardware-Geld" (sprich der Prüfstand, der nicht kaputt gehen darf) dahinter steckt, dann ist das nach dem, was ich bisher herauslese, eine Aufgabe für eine RT-System mit FPGA, und nicht mehr für eine DAQ-Karte (schon gar nicht USB).
Naja, das ganz große Hardware-Geld steht nicht auf dem Spiel. Was passieren kann, ist das Abbrennen von Leitungen oder paar Leiterplatten, falls der Stromregler falsche Sollwerte vom PC bekommt. Das kostet dann nicht viel, macht aber Ärger, ist Zeitaufwand und bedeutet Prüfausfall.
Leider wird das dann an einer Uni nicht in Geld aufgewogen und berechtigt zum Kauf eines RT-Systems
Bis auf diese Null am Ende funktioniert auch alles super zuverlässig. Die Karte selbst ist ja ein kleines RT-System für sich und wenn die wie bisher die Daten vor dem Start komplett übermittelt bekommen hat, konnte auch wenig schief gehen.
Die Erklärung von Lucki motiviert mich jetzt bisschen, dann doch den PC in die Abhängigkeitskette mit einzubeziehen. Aber die Beantwortung der zwei Fragen würden ein paar Bedenken vor einem Test wegwischen
Ich habe jetzt das ganze mal am USB2.0 getestet. Erfolglos...
(16.12.2013 08:54 )Lucki schrieb: Und zwar so: Es wird ein zweiter Puffer auf dem PC angelegt. Der kann recht groß sein, so dass Du z.B die Samples für den gesamten Zyklus mit einem Mal reinschreiben könntest. Der Datentransport zur Karte findet über DMA statt, die "windowsinterrupt-gefährdete" CPU hat damit nichts mehr zu tun. Beim Datentransport zur Karte findet ein Handshaking derart statt, dass der interne Kartenpuffer immer möglichst gefüllt bleibt. Dieses Handshaking, sowie die Konvertierung der parallelen Daten zu USB-Seriell, werden von untergeordneten, in "Echtzeit" arbeitenden Intelligenzen erledigt, die CPU hat damit ebenfalls nichts zu tun.
Fazit: Wenn Die USB-Schnittstelle den Datendurchsatz schafft, dann müsste es funktionieren.
Wähle ich DMA aus, erscheint folgende Fehlermeldung:
Code:
Error -200077 occurred at Property Node DAQmx Channel (arg 2) in AO_rate.vi
Possible reason(s):
Requested value is not a supported value for this property.
Property: AO.DataXferMech
You Have Requested: DMA
You Can Select: USB Bulk, Programmed I/O
Channel Name: NI_USB_6351/ao0
Die Karte scheint also kein DMA zu können?
Mit USB Bulk erhalte ich folgendes:
Code:
Error -200621 occurred at DAQmx Wait Until Done.vi:2
Possible reason(s):
Onboard device memory underflow. Because of system and/or bus-bandwidth limitations, the driver could not write data to the device fast enough to keep up with the device output rate.
Reduce your sample rate, or reduce the number of programs your computer is executing concurrently.
Und schließlich mit Programmed I/O:
Code:
Error -201026 occurred at AO_rate.vi
Possible reason(s):
Data Transfer Mechanism is set to Programmed I/O which is not supported for hardware-timed operations for this device and Channel Type.
Change Data Transfer Mechanism, do not configure Sample Clock timing, or set Sample Timing Type to On Demand.
Also erstmal ganz unabhängig davon, wie sinnvoll diese Übertragungsvarianten für mich sein können, geht genau das, was ihr empfehlt, scheinbar nicht. Lade ich nicht erst alle Daten auf den Kartenspeicher, bevor ich die Ausgabe starte, funktioniert es ab gewissen Sampleraten einfach nicht mehr. Trotz USB 2.0.
Anbei der Vollständigkeit halber mein Test-VI.
Die Antwort des Supports...
Zitat:Die übliche Vorgehensweise zum Ausgeben eines Pegels von 0V nach der Ausgabe ist, wie schon von Ihnen verwendet, das Schreiben einer '0' in DAQmx-Write.
Bei bestimmten DSA-Karten von uns lässt sich der Standardwert der analogen Ausgabe als Eigenschaft festlegen - beim USB-6351 ist dies leider nicht möglich. Hier wird der letzte in den AD-Wandler geschriebene Wert als Gleichspannung beibehalten.
Was man noch überprüfen könnte:
Sie haben gesagt, dass Sie in der Software warten, bis die Ausgabe beendet ist - wie haben Sie diese Abfrage realisiert?
Wenn Sie die Funktion "DAQmx Is Task Done?" oder "Wait until Done" verwenden, müssen Sie beachten dass diese Statusabfrage mit einer Frequenz von 10Hz abläuft - es kann also im schlechtesten Fall 100ms dauern bis die Änderung registriert wird.
Zumindest erstmal die Aussage, dass ich nicht blind war und man einen Stadardwert tatsächlich nicht festlegen kann.
Der Vorschlag zur Abhilfe nützt mir nichts, weil es keine Rolle spielt, ob ich nun ein paar Millisekunden schneller bin oder nicht - ich muss die Null sofort haben. Selbst 1ms ist mir da schon zu lang. Deswegen ja eine Karte mit so hoher Samplerate, um tatsächlich im Bereich 100kS/s ausgeben zu können und den Regler im Prüfstand stabil zu halten.
Habt ihr noch Meinungen zu meinen Ausgabe-Tests? Mach ich noch was falsch?
Mir ist noch eine Idee gekommen, von der ich aber nicht weiß, (a) ob sie so umsetzbar ist und (b) wie ich das anstellen sollte...
Könnte man den AO statt mit dem OnBoard-Takt mit einem Counter takten und dann diesen (oder einen zweiten Counter) so konfigurieren, dass er beim Erreichen eines bestimmten Zählwertes einen digitalen Ausgang schaltet? Einzeln habe ich das schon gemacht (takten von AO mit Countern & Ausgabe von digitalen Flanken durch Counter). Aber lässt sich das auch kombinieren?
Dann könnte ich nämlich den Regler einfach hardwareseitig durch diese Flanke abschalten...
Ich finde Dein Vi viel zu kompliziert, ich würde mehr auf die natürliche Intelligenz von Labview vertrauen und nicht so viele Einstellungen vorgeben. Den Datentransport "großer PC-Puffer" --> "kleiner Kartenpuffer" --> DAC macht doch Labview auch ohne jede Programmierer-Einmischung auf ziemlich optimale Weise.
Mit meiner Billgkarte der M-Serie funktioniert das hier einwandfrei, warum sollte es nicht auch mit Deiner USB-2.0-Karte gehen?
(Amerkung: Beim Herunterkonvertiern zu kommt bei mir eine Warnung, daß es wegen anderer Parameter bei DAQmx-Timing zu einer Fehlermeldungs kommen könnte)
Danke für dein Testen!
Leider gibt das bei mir genau die gleichen Fehler wie mit meinem Test-VI. Ist auch ziemlich klar, weil ich in meinem (zugegebenermaßen komplizierteren) Test alle Eigenschaften auf die Standardwerte gesetzt hatte. Ich hatte nur vorher mit den Einstellungen gespielt und deswegen war das noch mit drin.
Funktioniert evtl. DMA nicht bei USB-Karten und demzufolge wird USB-Bulk verwendet, was wiederum zum Buffer Underflow führt?! Vielleicht ist genau das der Unterschied, weswegen deine PCI-Karte geht und meine USB-Karte nicht?!
Was meint ihr zu meiner letzten Idee?
Zitat:Könnte man den AO statt mit dem OnBoard-Takt mit einem Counter takten und dann diesen (oder einen zweiten Counter) so konfigurieren, dass er beim Erreichen eines bestimmten Zählwertes einen digitalen Ausgang schaltet? Einzeln habe ich das schon gemacht (takten von AO mit Countern & Ausgabe von digitalen Flanken durch Counter). Aber lässt sich das auch kombinieren?
Dann könnte ich nämlich den Regler einfach hardwareseitig durch diese Flanke abschalten...
/
Ausgabe mit letztem Sample auf Null
Mit der bisherigen Datenübertragungs-Methode hatte ich ja keinen Anlass, das zu tun. Und andere Methoden kamen mehr (oder wie ich jetzt gelernt habe, vielleicht auch weniger) gerechtfertigt nicht in Frage...
kommt bei mir eine Warnung, daß es wegen anderer Parameter bei DAQmx-Timing zu einer Fehlermeldungs kommen könnte)
