LabVIEWForum.de - kontinuierlich erzeugte & geregelte Signale ausgeben

LabVIEWForum.de

Normale Version: kontinuierlich erzeugte & geregelte Signale ausgeben
Du siehst gerade eine vereinfachte Darstellung unserer Inhalte. Normale Ansicht mit richtiger Formatierung.
Seiten: 1 2
Hallo Experten,

ich möchte ein Spannungssignal (-10V...+10V) mit einer bestimmten Frequenz, Amplitude und Form (Sinus, Sägezahn,...) erzeugen und ausgeben lassen. Die Frequenz soll dabei veränderlich sein und die anfänglich eingestellte Amplitude soll durch das Programm geregelt werden können (ein Beschleunigungsaufnehmer auf dem Prüfstand misst dann die tatsächlich vorhandene Schwingung).
Mein Problem besteht darin, dass die Karte (AT-MIO-16E-10) bei DAQmx nicht mehr erkannt wird (ist noch eine ISA-Karte) und somit bin ich auf die DAQ-Traditionell-VIs angewiesen.
Dabei gibt es die Möglichkeit, dass erzeugte (zB Sinus-) Signal direkt über "A0-Signalverlauf erzeugen" (*) auf die Karte auszugeben. Leider schreibt das Programm dabei 1000 Samples in den Puffer der Karte, läßt diese diesen auslesen und nach einer Sekunde beschreibt das Programm den Puffer dann erneut... das wäre eigentlich kein Problem, wenn es nicht zwischen Puffer auslesen und Puffer neu beschreiben eine Latenzzeit von wenigen Millisekunden geben würde! Dabei bleibt der Wert der Schwingung konstant und die Schwingung ist eben "abgehackt". (selbst eine Sampleanzahlerhöhung würde nichts bringen...)
Eine andere Möglichkeit besteht darin den Puffer einmal zu beschreiben und der Karte dann zu sagen, dass sie immer wieder den Puffer auslesen soll. Somit ist der Signalverlauf kontinuierlich, lässt sich aber nicht mehr regeln... ich könnte noch den Puffer wieder neu beschreiben, aber dies wäre ja erst wieder nach einer Sekunde möglich (und wahrscheinlich würde dann auch wieder die Latenz auftreten), was die Regelung bei einer Frequenz von bis zu 4 kHz sinnlos macht.
Ich habe schon über das VI "AO 1-Update schreiben" versucht, jeden Wert selbst über y=sin x zu erzeugen und dann auf die Karte zu übertragen. Dabei war die timed-loop sehr hilfreich, aber die Windowsbegrenzung von min 1ms (1000 Samples/s) ist zB für eine Frequenz von 1 kHz einfach zu wenig (entspricht 1 Wert für einen Schwinungsdurchlauf).
Die timed-loop 100.000 mal pro Sekunde durchlaufen zu lassen scheiterte eben an Windows...O(

Wie geht man an so eine Sache heran? Irgendwie muss es doch möglich sein ein kontinuierliches Spannungssignal zu erzeugen und das regelbar machen zu machen!?


Vielen Dank für eure Ratschläge im Voraus.

MfG Tilo

(*) "AO-Signalverlauf erzeugen" ist ein VI, welches die 5 Unter-VIs "Config","Write","Start","Wait" und "Clear" enthält (ähnlich den DAQmx-Tasks)
Leider kenne ich mich mit den alten Karten und dem Traditional DAQ nicht aus. Vielleicht ging das damals noch nicht so, wie Du Dir das vorstellst. Wieso kaufst Du nicht 'ne aktuelle Karte? Dann bist Du 'ne Zeit lang gerüstet.

Gruß Markus
Hallo,

leider habe ich die Vorgabe "Junge, mach es mit der alten!" 2hands (Karte). Das bisherige Uralt-System auf einem anderen Rechner, welches noch unter DOS läuft, kann die Steuerung und Regelung ja auch schon (allerdings mit mir unbekannten Hardwarekomponenten).
Laut Spezifikation kann die AT-MIO-16E-10 auch 100 kS/s verarbeiten, somit müsste es theoretisch funktionieren...

MfG Tilo
Hi,

solche alten Regelsysteme kenne ich zu Genüge. Bei uns wurde das RT-Problem ähnlich gelöst. Ein DOS-Rechner mit einem PID-Regler auf Pascal-Basis und ein Rechner auf welchem LV als Vorgabe, Messwerterfassung und Bedienung lief.
Teilweise laufen diese Systeme hier immer noch und das SEHR stabil.

Von der Grundstuktur ist das nichs anderes als die aktuellen cRIOS oder PXI-Systeme. Eine zeitunkritische Schleife bedient ein
RT_System das die Regelaufgaben übernimmt. Wenn du mit 1kHz Refreshrate an die Sache ran willst geht das nur so. Die Regelaufgabe kannst du auf einem FPGA sehr zügig rennen lassen.

Sag deinem "Chef" das das mit den alten Karten nichts wird und das er ein paar kEuro in die Hand nehmen muss. VOm Programmieraufwand ganz abgesehen.

Keep on rockin´, RMR
Hi,

vielen Dank erst einmal für eure Antworten. Nach einigem hin und her habe ich das etwas versteckt abgelegte "Continuous Generation.vi" im Exampelfinder gefunden... das spielt mit dem Puffer der Karte rum! Ich werde berichten, wenn ich damit Erfolg hatte. ;o)

MfG Tilo
' schrieb:Nach einigem hin und her habe ich das etwas versteckt abgelegte "Continuous Generation.vi" im Exampelfinder gefunden... das spielt mit dem Puffer der Karte rum!
Die Bezeichnung des Beispiels sollte außer "Continuous Generation" noch die Worte "Non Regeneration" enthalten. Dann ist es genau das was Du suchst.
das ist auch mit Traditional DAQ kein Problem.

Im Prinzip erstellst du wie bei DAQmx auch zunächst mal eine gepufferte kontinuierliche Ausgabe. Damit das am Anfang einfacher wird gibst du halt erst mal nur konstant 1 Volt aus einem Array aus.

Wenn das klappt programmierst du PARALLEL zur Ausgabe die Erzeugung deines Signals. Der Gedanken-Knoten, den es dabei zu lösen gilt ist, dass du einen Block Daten gerade ausgibst während du den nächsten Block gerade erzeugst, den du sofort im Anschluss in den Ausgabe-Puffer schiebst. Du musst dabei quasi um Blockgröße / Samplerate Sekunden in die Zukunft denkenWink

Das ganze wird ja vermutlich in einer While-Schleife laufen und die "Kunst" dabei ist einfach den Puffer nicht leer laufen zu lassen ... und da macht es keinen Sinn erst den Puffer leer zu schreiben, dann den nächsten Block zu generieren und dann erst in den Puffer zu schreiben ...
Es geht zwar alles genau so wie i2dx sagt und ist auch nicht übermäßig kompliziert, aber trotzdem: Ohne enge Anlehnung an das Originalbeispiel - und es gibt davon genau eines in der Beispielsammlung - stehen die Chancen schlecht, daß es problemlos funktioniert. Für DAQmx heißt das Beispiel: "Cont Gen Voltage Wfm-Int Clk-Non Regeneration.vi". Ein entsprechendes Beispiel gab es auch für Trad. DAQ - nur habe ich das nicht mehr installiert.
So sieht das Beispiel aus - Beschreibung siehe i2dx:
[attachment=26962]
Hallo Leute,

vielen Dank noch einmal für eure Hilfen. Leider muss ich erstmal weiterhin mit der alten Karte arbeiten, die Aussicht auf eine neue wurde mir aber zumindest einmal schon gestellt. Cool
Ansonsten habe ich das "Continuous Generation.vi" so angepasst, dass es relativ zur Zufriedenheit läuft.
Einzigstes Manko bis jetzt: nur sekundenweise Frequenz/Amplituden-Anpassung. Dies ist aber zur Zeit erstmal nich so schlimm...

laienhafte Lösung siehe Bild Rolleyes

MfG Tilo

[attachment=27225]
Hallo,

nach langem hin und her bin ich nun an einem Punkt angekommen, an dem es einfach nicht weiter geht... Huh
Das Programm läuft einigermaßen, aber ab und zu steigt es einfach mit der Fehlermeldung aus, dass der Rechner mit dem Gerätedurchsatz nicht mithalten konnte... keine Ahnung, manchmal kann er es aber trotzdem und stürzt nicht ab?!? Wie kann man das verhindern? (s. Bild)
Ansonsten ist der Rechner auch zu sehr ausgelastet. Wenn ich aber Warte-ms in die Schleifen implementiere, dann haut es mit der Queue nicht mehr hin. Gibt es da Optimierungspotential?
Des Weiteren steigt Labview auch bei einer höheren Abtastfrequenz für die Signalerfassung aus. Leider sind 1000 Scans/s zu wenig für Frequenzen bis 3kHz! Kennt da jemand eine gute Lösung?

"Wenn das klappt programmierst du PARALLEL zur Ausgabe die Erzeugung deines Signals. Der Gedanken-Knoten, den es dabei zu lösen gilt ist, dass du einen Block Daten gerade ausgibst während du den nächsten Block gerade erzeugst, den du sofort im Anschluss in den Ausgabe-Puffer schiebst. Du musst dabei quasi um Blockgröße / Samplerate Sekunden in die Zukunft denken"

=> Danke für die Anregung i2dx, aber ich schätze meine jetzige Lösung ist nicht ganz, was du mir damals sagen wolltest oder?

Gibt es überhaupt eine vernünftige Möglichkeit die Sache ordentlich zu lösen? Eine neue Karte wurde, wie oben schon erwähnt, zwar angeboten, bis diese aber einmal hier vor mir liegt, ist wahrscheinlich längst Weihnachten... Dry

Vielen Dank für eure Hilfe.

Gruß Tilo

Im Anhang: die mal laufende und mal nicht laufende Lösung...
Seiten: 1 2
Referenz-URLs